Components All the Way Down
The phrase "it's components all the way down" is something we say internally when someone asks why a particular thing in the platform is built the way it is. It's only half joking.
We've made an architectural commitment to full composability that goes further than most platforms. Not just UI components, but data sources, navigation structures, field definitions, action chains, permission rules, and workflow behaviors — all expressed as composable units with defined interfaces. Every piece is an instance of a pattern, not a one-off feature.
This is worth explaining, because the consequences of this decision shape everything.
The Difference Between Features and Components
A feature is a capability. An invoice feature creates, displays, and manages invoices. It's self-contained and purposeful.
A component is a building block. A form component takes a data definition and renders an editable form. A table component takes a data source and column configuration and renders a sortable, filterable list. Neither knows what domain it's serving. They don't need to.
Features are built for specific use cases. Components are built for combinability. The distinction matters enormously when requirements diverge from what the feature designers anticipated — which, in real business software, they always do.
The Composability Ceiling
Every platform built on features hits a composability ceiling. You can use the features as designed. You can configure them within their options. But combining them in ways they weren't designed for, or using them in contexts they weren't built for, requires customization — which typically means code.
A component platform has a different ceiling. The combinable space is the product of all component combinations, which grows much faster than the number of components themselves. Adding a new component adds it to every existing composition space. The ceiling rises with each addition.
The Cost of Going All the Way
Full componentization has costs. Building components is harder than building features. A feature can make assumptions about its context; a component cannot. A feature can hardcode its data model; a component must accept it as configuration. The upfront investment is real.
The payoff comes later — and it compounds. Every component we build extends the capabilities of every component that already exists. Every new data source type works with every existing component. Every new component type works with every existing data source. The multiplication is the point.
Why This Matters to You
For users of Swifty, the composability commitment means that what you can build is not limited to what we anticipated. Combine a monitoring data source with a chart component and a metrics card on a single page — that works, even if we didn't build a "monitoring dashboard feature." Mix your own data with external API data in a single view — that works, because both are data sources speaking the same language.
The platform grows in capability as we add components, and the space of what's possible grows faster than the components themselves. That's the bet we made, and we believe it's the right one.
Components all the way down — it's a design philosophy that shapes every decision about what to build and how to build it. The applications it enables are our evidence that it's working.