Most teams shopping for business software face the same uncomfortable choice. On one side sits the off-the-shelf tool that handles maybe sixty percent of the workflow and asks you to bend the rest of your organization around it. On the other sits a bespoke build — months of development, a dedicated team, and the quiet dread of who will maintain it two years from now. Both paths have their place. Neither is the one we take.
Our platform offers a third option: a blank canvas where each customer designs their own data model, and a full set of supporting infrastructure — permissions, views, forms, search, API, automations — that comes along for the ride the moment a type is defined. The object model is where that begins.
The model rests on four simple primitives. A module is a top-level section of the application, roughly equivalent to a screen or an area. Modules appear in the main navigation and group related content. A type is the definition of an entity — Customer, Invoice, Task — and it describes the shape of the records it holds. A property is a field on that type, carrying a data type, validation rules, display settings, permissions, and an editor widget. And an object is a single record: one real instance of a type.
Imagine a small consultancy setting up a lightweight CRM. They create a Clients module. Inside it, they define a Customer type with properties for name, email, address, and relationship status. A week later they add an Engagement type — tied to Customer through a reference property — to track each piece of work. Every time they save a change, the platform updates forms, lists, search, and the API behind the scenes. No deployment, no code, no data-migration script.
The same machinery runs the platform itself. Users, roles, queries, and views are all objects too, defined by system types that look and behave like the implementation types a customer creates. That consistency is quietly powerful: when you learn to work with your own data model, you're also learning to work with the platform's administrative layer, and the two never feel like separate products stitched together.
Once a type exists, you get a remarkable amount for free. A form to create and edit records. A table view with sorting and filtering. Full-text search over its text properties. Role-based permissions down to the individual field. A REST endpoint. A webhook you can subscribe to. A trigger the automation builder can hook into. None of that has to be wired up by hand, which is the point. The platform's value proposition depends on this compounding: every new type quietly inherits decades' worth of features that would, in a conventional build, be someone's backlog.
None of this replaces traditional development for every scenario. Systems with unusual performance profiles, highly specialized user interfaces, or deep integrations into legacy infrastructure sometimes still warrant a custom build. But for the very large category of business applications that amount to "track these things, let these people work with them, and connect to those systems" — the object model is where that work stops being a project and starts being an afternoon.
From here, it's worth getting to know the property library, since choosing the right property types is where a good model becomes a great one.