Home / Framework
The framework reads a metadata definition and runs the application from it — interface, backend and APIs, on web, mobile and desktop. No code is generated and nothing is deployed. This is what that means in practice.
What the definition holds
There is no gap between the document that describes the application and the application itself, because there is nothing in between them. The framework reads this definition and runs the system from it.
Define once, run everywhere
The usual cost of "we also need it on mobile" is a second team, a second codebase and a permanent synchronisation problem. Here the same definition renders natively for each context.
Dense grids, multi-pane detail views, bulk actions — the interface a dispatcher or clerk lives in all day.
The definition renders to a layout suited to a phone, for people who are moving rather than sitting at a desk.
For workflows that need local integration or long-running sessions, without maintaining a separate product.
The same definition also drives the backend and the public API. Nothing is described three times, so nothing can disagree.
This one is worth stating plainly, because it is where "also runs on mobile" usually turns out to be less than it sounded. Our mobile client reads the same definition the web application reads. It is not a separate build of a separate app, so changing a rule does not mean a new binary, a submission, and a wait in Apple's review queue while your operation carries on doing it the old way. Change the definition; the next refresh has it.
Ask us to prove this in the demo rather than taking it on trust. We will change a rule while you watch and you can pull-to-refresh on your own phone. It takes about ten seconds, and what matters is everything that doesn't happen in between.
How it actually works
This is the part people most often get wrong about us, so we'll be blunt about it. The framework does not read your metadata and write out an application for someone to build and deploy. It reads the definition and runs the application, directly, every time.
There is no build step, no generated source tree, and nothing to review, fork or merge. The definition isn't a blueprint that becomes the system. It is the system, being read.
Base, organization, role and user
Every application starts with a shared base definition. Our configuration team can then adapt that definition for an organization and refine it again for a role — without changing the common foundation. At runtime, the framework resolves those layers into the experience that person is allowed to use.
Users can personalize selected parts of that experience for themselves. For example, they can choose which permitted fields appear in Quick Search or in a results grid, and the order in which those fields appear. They are personalizing their workspace — not changing organization rules, role permissions or the underlying business model.
The shared business model: objects, fields, relationships, validations, workflows and standard behavior that form the common application foundation.
Terminology, additional fields, rules, workflow variations and other organization-specific requirements are applied as a separate layer over the base.
The configuration team defines what each role can see and do, including which information and actions are available to that role inside the organization.
Within the fields and functions already permitted for the organization and role, each user can shape frequently used search fields and the information shown in result grids.
What the user controls
Two users doing different jobs may need very different information at hand. The framework lets each person organize the fields that matter most to them while staying inside the organization and role boundaries configured for them.
A user chooses from the fields available to that role and organization, then arranges the selected fields in the order that best fits the way they search.
An LTL user may prioritize pieces, weight and volume, while a TL user may care more about equipment and routing information. Each can organize the grid without changing the shared screen for everyone else.
The same application can therefore be standardized at the foundation, tailored for an organization, governed by role, and still feel personal to the individual using it.
Where a variation is larger than an override can carry, new business objects and new roles are configured rather than the base being bent to accommodate one organization. What only we extend is the metamodel itself — the kinds of thing a definition can express. See what you configure and what we do below.
Where the framework came from
Two questions get asked about any framework, and they pull in opposite directions. Is it proven? And is it current? A platform usually gives you one or the other — long-running and creaking, or freshly built and untested on anything that matters.
Ours has been running production operations since 2014, when we rebuilt our own transportation product on it after first building that product the conventional way. Twelve years of real operational load tells you precisely where a framework holds up and where it fights you. This year we shipped the current generation, rebuilt around exactly that.
We have been running applications from a definition since 2014, across multiple live SaaS products and millions of shipments. This is not a direction we changed to recently; the design decisions in the current generation come from a decade of watching the earlier one under load.
The current generation shipped in 2026. Where the previous one made something harder than it should have been, that is what the rebuild addressed — informed by production experience rather than by guessing at requirements up front.
We did to our own framework what we tell customers a good system should let them do: change it in response to what the work actually turned out to need.
Worth checking on any platform you evaluate
On the surface this whole category sounds the same, so it is worth knowing where the differences actually are. Every serious platform here runs its screens from a definition — that part is genuinely solved, and solved well. Then real business logic arrives, and almost all of them hand you a programming language.
The form varies. A compiled plug-in module. A proprietary language of the vendor's own. Server-side scripting. A compiled extension in Java or C#. The vocabulary differs and the marketing differs, but the shape is the same: past a certain point, someone writes code, and from that moment you own a codebase — with its build, its test cycle, its release process, and the developer who understands it.
Screens, forms and simple rules come from a definition. Anything beyond that is written by hand in a real language, compiled, and deployed. The no-code promise holds right up until the logic gets interesting — which is exactly when it mattered.
That seam is where the maintenance burden starts, and it is usually invisible during a demo, because a demo never gets that far.
The screens run from the definition and so does the logic behind them. There is no point in the stack where the model runs out and a developer takes over, which is why there is no build step and no deployment step anywhere in the system.
Nothing is compiled, so there is no artefact sitting between the definition and the running application for the two to disagree about.
The question to put to anyone you evaluate, including us: at what point does this stop being configuration and start being code? Every vendor has an answer. It is worth hearing all of them before you choose.
One point of precision, because a good architect will raise it: definitions are resolved and cached, so you are not paying resolution cost on every request. We are not claiming nothing is ever optimised. We are claiming nothing is ever compiled, and nothing is ever deployed.
AI and governed execution
As models move from answering questions to proposing and taking actions, the important architecture question becomes permissioned execution. What objects exist? Which actions are valid? Which roles may invoke them? Which rules, approvals and integration contracts apply?
Those concerns already live in the SIT definition: entities, fields, rules, roles, permissions and external interfaces are explicit, structured and enforced by the runtime. That makes the framework a natural governed surface for AI-assisted and agentic workflows without moving the source of truth into a prompt.
Requirements can be turned into draft definitions, partner mappings, test cases and documentation faster, with a human reviewing the result before it becomes operational.
Objects, permissions, validations, workflows and integration contracts remain explicit rather than being inferred anew from a prompt on every request.
Approved business rules and permissions are enforced by the framework. AI can assist the work without becoming the only authority for what the application is allowed to do.
AI understands intent. Your business model defines the boundaries. The framework executes them.
This is an architectural position, not a claim that every workflow is autonomous today. We name specific AI features only when they are implemented and measurable.
Included from day one
Defined alongside the data it protects, so permissions can't drift away from the model.
Google Firebase handles sign-in. We store no passwords. MFA available per tenant.
Every query is scoped to the tenant by the framework, not by each developer remembering to.
Who changed what, when — captured as a property of the framework rather than a feature request.
Most day-to-day analysis happens in the grid, without exporting anything anywhere.
Pie, bar and line views of any grouping, straight from the screen the user is already on.
Complex AND / OR criteria on any entity — no report request, no waiting on a developer.
When the analysis does belong in a spreadsheet, it's one action away.
Talking to the outside world
Trading partners each want their own format. Because the mapping between your data and theirs is defined rather than coded, adding a partner is configuration work rather than a new custom integration project.
In production today across our customers: EDI, XML, JSON APIs, FTP/SFTP and AS2, plus direct links to load boards, rating engines, mileage engines, carrier vetting services and accounting systems.
How an engagement runs
We don't start with a twelve-week requirements document you have to imagine your way through. We start by defining enough to show you something real.
We learn how your operation actually runs — including the parts held together by spreadsheets and habit.
Entities, screens, roles and interfaces are defined. You see working screens early, because the moment something is defined the engine can run it.
We configure, develop, host and manage the system on Google Cloud Platform, with your data isolated and encrypted.
New requirement, new field, new partner interface. We change the definition and every layer follows — with no rebuild and no release to wait for.
Screens from a definition
Representative screens from a system running on the framework — a transportation operation, in this case. None of this was hand-built and none of it was generated as code: the grid, the grouping, the charts, the search builder and the multi-panel detail screen are all the engine reading a definition and drawing what it describes.
No second codebase and no separate mobile team, because there is no codebase to duplicate. The same definition that drives the operational grid also drives the layout.
Representative screens shown with sample data.
Ownership
This question comes up in every contract, so we answer it before it's asked — including the part most vendors leave vague.
Bring the workflow your current software makes awkward. We'll walk through what its definition would look like.