Data is the cornerstone

Data-driven products only stay honest when the data itself is honest - explored, shared, shaped, and formalised from the ground up, not reverse-engineered from a UI, or whatever AI generated research gives you.

At Pendulum we treat the schema as the cornerstone - the same discipline behind our data-driven systems work. Everything else follows: APIs, generated types, screens, reports - this is all masonry that rests on that stone. Get the foundation wrong and the stack still goes up, it just leans or well ... collapses.

We start by understanding the domain: entities, relationships, invariants, and the awkward edge cases that only show up when real users hit real volumes. Through workshops, spike tests and user research we build a shared understanding of this domain. 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 new feature.

Definitions are cheap unless they are tested against real world data. We back our data designs with tooling and tests that assert defined shapes, logical constraints, and migrations against as real representative data as we can get our hands on.

When those tests pass, the structure is definitive enough to generate from. When they fail, we fix the stone, not the wallpaper.

From this solid data foundation we generate types across the stack, creating predictable APIs, clients receive generated structures to build against, leaving no guesswork, no parallel hand-written DTOs and 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.

One development pain point we often see is type mismatches between API and UI. These are usually a symptom of separation without a shared source of truth. Multi-language generation from the same definitive model closes that gap and makes scaling complex data-driven systems practical.

None of this replaces good judgement. Naming conventions, normalisation boundaries, what must stay strict for compliance, that still needs an experienced eye and 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.

Regardless of the tools you use, or the AI harness you employ, the key is to start with a shared understanding of the domain, and build from there.