Data-driven products only stay honest when the data itself is honest - explored, shaped, and formalised from the ground up, not reverse-engineered from whatever a UI or an AI scaffold happened to invent.
At Pendulum we treat the schema as the cornerstone - the same discipline behind Pots and our data-driven systems work. Everything else - APIs, generated types, screens, reports - is masonry that rests on that stone. Get the foundation wrong and the stack still goes up, it just leans or well ... collapses.
Explore, then formalise
We start by understanding the domain: entities, relationships, invariants, and the awkward edge cases that only show up when real users hit real volumes. That exploration feeds a definitive data structure in the backend - tables, constraints, and contracts that say what the system is allowed to mean.
Solid database design is not ceremony. It is the difference between a product that can grow reporting, permissions, and integrations later, and one that needs a painful rewrite the first time someone asks for a trustworthy aggregate.
Validate against real data
Definitions are cheap until they meet production-shaped rows. We back the model with tooling and tests that assert shapes, constraints, and migrations against representative data - so the schema is not a slide, it is an executable agreement.
When those tests pass, the structure is definitive enough to generate from. When they fail, we fix the stone, not the wallpaper.
One source, many languages
From that foundation we generate types across the stack. Backend contracts become predictable APIs. Clients receive generated structures to build against - no guesswork, no parallel hand-written DTOs that drift, no loose docs pretending to bind unrelated layers together. The same idea shows up in industry practice: keep a single source of truth for the contract, then generate; Google's API design guide is the long-running example of treating the API surface as an owned schema, not a by-product of screens.
Type mismatches between API and UI are usually a symptom of separation without a shared source of truth. Multi-language generation from the same definitive model closes that gap.
Care, and a keen eye
None of this replaces judgement. Naming, normalisation boundaries, what stays denormalised for read paths, what must stay strict for compliance - that still needs an experienced eye. Taking care is the key. A solid data foundation is what makes the rest of the stack clear for design and engineering teams to build on with confidence.