Pages Assembled From Definitions

Traditional software has a sharp line between structure and content. The structure — page layouts, navigation, data shapes — is baked into the application. Content flows into the structure at runtime. Changing the structure means changing the application, which means a new deployment.

Swifty blurs that line deliberately.

Structure as Configuration

In Swifty, pages are not baked into the application. They're assembled at runtime from definitions — configuration records that describe what should appear, where it should appear, and how it should behave.

A page definition says: this page has a header with a title and a save button, a main content area with a form component, and a sidebar with a related records panel. The application reads that definition and assembles the page. Change the definition, and the next page load reflects the change.

No code change. No deployment. No waiting.

Why This Matters

The practical implications are significant.

Iteration speed. When structure is configuration, adjusting a page layout takes seconds. Add a component, remove a section, reorder elements — the change is immediate. Feedback loops shrink from days to minutes.

User-specific customization. Because pages are assembled from definitions rather than hard-coded, different configurations can produce different pages for different user roles, different tenants, or different contexts. The same application logic produces a different page structure based on what the definitions say.

Safe experimentation. Changes to definitions can be staged, previewed, and reverted. If a new layout doesn't work for your team, you're one click away from the previous one. There's no risk in trying something.

Definitions All the Way Down

It's not just pages. Navigation, data objects, fields, workflows, user interfaces, automation rules — all of these live as definitions in the same system. The platform is a definition reader and assembler; the definitions are your app.

This creates a consistent mental model: if you want to change something about your app, you change a definition. You don't patch code, you don't modify templates, you don't ask a developer to make the change on your behalf. You configure.

Cascade and Inheritance

Definitions support layering. Platform-level definitions provide defaults. Tenant-level definitions extend or override the platform defaults. User-level definitions can further personalize the experience.

The application assembles the final page by reading the full cascade, applying each layer in order. The result is a system that is strongly consistent by default and deeply customizable when needed — without any of those customizations affecting the underlying platform.

Pages assembled from definitions are what makes Swifty adaptable in a way that hard-coded applications simply cannot be.