Can you fix a data model already in production?

Usually, and usually incrementally. The approach is to introduce the correct shape alongside the existing one, migrate consumers a piece at a time, then remove the old path — rather than a single cutover nobody can roll back.

How do you handle integrations with unreliable third parties?

By assuming they will fail and change shape without notice. Normalise at the boundary, keep the raw payload, and make retries idempotent so a partial failure is not a corrupt record.

Whichever your team can maintain. GraphQL earns its complexity when many clients need different shapes of the same data. For a single frontend, it is usually cost without benefit.

Make your data work together.

All services

Give your team consistent data across the tools and workflows that depend on it.

When two systems disagree about the same record, someone ends up reconciling them by hand. I connect your data sources around a shared model, so your team can build features and run workflows without repeating that work in every tool.

Book a call

What is getting in the way

The model does not match the domain

The shape was inferred from the first screen anyone designed. Every feature since has been a workaround, and the workarounds are now the system.

Integrations that disagree

Several sources describing the same thing differently, and no canonical version. Every consumer downstream re-implements the reconciliation slightly differently.

Contracts that drift

The API returns something the client did not expect. Nobody noticed until a user did, because nothing enforced the agreement.

What you gain

Data that fits your business

A schema that accounts for real workflows and awkward cases reduces the workarounds each new feature needs.

Catch mismatches before release

A shared definition of API requests and responses makes contract drift a build error your team can act on.

One view across sources

Third-party data is normalised as it enters the system, so every downstream feature uses the same records.

Keep working during changes

Reversible migrations are tested against production-shaped data before existing workflows move to the new model.

Knowledge your team keeps

API and data-model documentation lets the next engineer add an integration without reconstructing the original decisions.

Typical stack

API

tRPC
REST
GraphQL
Zod

Data

PostgreSQL
Prisma
Redis
Event streams

Runtime

Node
TypeScript
Background workers

Quality

Contract tests
Migration testing
Observability

Work like this

FASTLAPCompare laps with other drivers, across GPS devices.

Jobs CopilotFind relevant roles and apply without filling every form by hand.

From first call to a working result

Know what needs to change

We spend thirty minutes on the result you need and what is blocking it. You leave knowing whether I can help and what the next step is.

Agree on success and cost

Before work starts, you get the outcome, the approach, the price, and the limits in writing. You know what you are paying for and how we will judge the result.

See progress as it happens

Try the work in demos, read the code, and follow a written update every day. You can check that we are solving the right problem while there is still time to adjust.

Keep moving after handover

Your team gets the code, documentation, tests, and a walkthrough so they can run and extend the product themselves.

Questions

Let’s work out your next step.

Bring the problem and the result you need. In thirty minutes, we’ll discuss what is blocking progress and whether this work is the right way forward.

Book a call