Why We Build Everything as Components
Every significant architectural decision in a platform comes with compounding consequences. A choice made early — about how features are structured, how they relate to each other, how they can be combined — shapes everything that can be built on top of it.
The decision to build everything as components was made early at Swifty. Understanding why we made it helps explain why the platform works the way it does.
The Problem with Monolithic Features
Traditional business software is built as features, not components. An invoicing feature, a CRM feature, an inventory feature. Each feature is a self-contained piece of functionality that was designed, built, and ships as a unit.
The problem with feature-based architecture becomes apparent when requirements diverge from what the feature's designers imagined. A customer wants the CRM's contact management with the invoicing system's document generation on a page that doesn't look like either. In a monolithic feature system, that's a custom project. The features weren't designed to be composed — they were designed to be used as-is.
Components Are Composable by Definition
A component is a capability with a defined interface. A data table component takes a data source and a column configuration and renders a table. A metrics card component takes a query and renders a number with a label. A form component takes an object definition and renders an editable form.
These components don't know about each other. They don't need to. Each does one thing well and exposes a clean interface. The composition happens at the page level, in the builder, when someone decides that this page should have a metrics row, followed by a two-column layout, with a data table on the left and a form on the right.
That composition is the application. The components are the vocabulary; the composition is the expression.
Growth by Addition
A component-based platform grows by adding new components, not by modifying existing ones. When we want to add a kanban board view, we build a kanban component. When we want to add a calendar view, we build a calendar component. The existing components are unchanged.
This is an important property. Each new component is additive — it makes new things possible without breaking anything that exists. The platform grows in capability without growing in complexity from any individual user's perspective.
Extensions as Component Packages
The extension system is built on the same principle. An extension is a package of components, definitions, and behaviors that add a domain capability to the platform. A shipping extension adds shipping-specific components. A financial documents extension adds document components.
Extensions are composable with the core platform and with each other. Enable two extensions and their components are available side by side in the builder — because components are designed to be composed, not to be standalone.
The Long-Term Bet
Building everything as components is a bet on long-term composability over short-term speed. Individual features can be faster to build than general-purpose components — you make more assumptions, cut more corners, don't bother with the configuration interface that no one needs for this specific use case.
But the accumulated capability of a component library — where every new component is immediately combinable with everything that exists — grows faster than the accumulated capability of features, which remain siloed.
We made the long-term bet. The component architecture is why the platform can produce a page structure that's genuinely unlike any feature the platform was built to support. The composition space is larger than any feature set could be.