A common language between backend, React and Flutter (and the AI says thanks)

Anyone who has ever integrated a frontend with a backend knows how it ends.

On paper it's a straightforward task: the backend exposes endpoints, the frontend consumes them. In practice it's where a lot of development time gets lost. You end up debating whether a field is called userId or user_id, figuring out what exactly that 400 the backend just returned means, hand-rewriting the frontend types because someone added a property to the DTO and nobody noticed. You start from a three-day estimate and end up at two weeks, not because the problem was complex, but because every little inconsistency requires a call, a manual mapping, a fix.

The problem multiplies when there are two frontends, one web and one mobile, because every convention has to be re-established in different languages, by different teams, with the very real risk that web and mobile end up handling the same error in two different ways. And it multiplies again when AI comes into play: modern coding assistants are lightning-fast when the code has clear patterns, but they become a source of bugs when they have to guess implicit conventions. If every project speaks a different dialect, the AI makes things up, and what it produces looks correct but isn't.

These are the contexts where time is poorly invested: instead of spending time and resources on important tasks, you waste time patching that backend because no standard was ever defined across all types of frontend.

So we decided to define a single specification that runs across every layer — backend, web, mobile — and to implement it in a way that's readable both by the developers and by the AIs that work alongside us.

One specification, three consistent implementations

We defined a single specification that lives across three layers:

The two packages don't share the same code: one is written in TypeScript, the other in Dart, but they share the design. Every decision is made once and applied to both.

Models generated, not written

A central part of the work concerns the data models. If the backend has a well-built OpenAPI specification, hand-rewriting the client-side types is self-harm: it's code that ages in silence, that drifts out of alignment with every change.

We built a generator that, from a single openapi.json, produces:

• On React: TypeScript types with matching Zod schemas, ready for runtime validation
• On Flutter: Dart classes with Freezed annotations, immutable and serializable

The clever part is targeted selection with automatic resolution of transitive dependencies: you tell it which types you need and it pulls in everything those types reference. No more bloated output with hundreds of entities the frontend will never use. No more silent mismatches when the backend changes.

One command and the data model is synchronized.

Why this also speeds up the work with AI

This is the part we find most interesting, and one we couldn't have told with the same force a few years ago.

The AI assistants we use are extremely powerful when the code has clear patterns. They're much less so when they have to guess implicit conventions. If each of our projects named errors differently, the AI would have to learn our local dialect in every file. It would often get it wrong.

With a formal, uniform specification, something different happens. When we ask the AI to write a new endpoint or to consume an existing one, it finds:

• Explicit, typed TypeScript/Dart types, generated from OpenAPI
• Zod schemas that describe what's valid and what's not
• Query and mutation helpers with clear signatures
• Errors in a standard IETF format the AI already knows

Result: the code it produces is correct on the first try far more often. Not because the AI is “better”, but because our codebase gives it the right handholds to understand it. It's the same reason a new developer learns our stack faster: the difference is that this speed-up now applies to pair programming with an assistant too.

In practice: the investment in consistency, made for humans, pays an extra dividend on the AI. And in 2026 that dividend is not marginal.

What changes, concretely

Let's leave the numbers aside, because every team would measure them differently, but the pattern is clear to see: