Model-driven development

Your software should work like your business does.

Most systems fail not because of bad code, but because nobody mapped the business before they started building. We fix that — then we prove it against your codebase.

The problem

The spreadsheet next to the system.

You spent six figures on software. Your team still runs workarounds in Excel.

Reports get assembled by hand because the dashboard doesn’t quite capture the real picture. Someone manually copies data between two systems because the integration assumed a process that nobody actually follows. Your operations team has a folder of “how we really do it” notes that contradict what the system expects.

This isn’t a technology problem. It’s a sequencing problem. Your system was designed around pages and buttons — what the interface should look like — before anyone properly understood the operation it was supposed to serve.

The result: software that reflects a designer’s assumption, not your business reality. That gap costs you every single day. And it widens every time your business evolves.

is this you?

Four problems, one root cause.

01

Your build is off the rails

You’re three to six months into a project that’s drifting. The spec doesn’t match reality. Rework is eating your budget. Your dev team isn’t slow — they’re building against six different interpretations of what the business needs.

02

Your data doesn’t add up

Two dashboards, two numbers, zero confidence. Your data team keeps patching SQL but the real problem is upstream — the organisation never agreed on what “active,” “enrolled,” or “revenue” actually mean

03

Your AI initiative is stalling

The demos looked great. Production is a mess. Your AI doesn’t understand your business because nobody gave it a model of your business to understand. It hallucinates rules because the rules were never encoded.

04

You’re about to start building

You haven’t committed to an architecture yet. You want to get it right the first time — spend a week modelling before you spend six months building.

How we work

Three phases, one continuous relationship.

01

Domain Clarity Workshop

We work with your people to map the real business — not what’s in the requirements doc, but what actually happens. Using Event Storming, we surface the disagreements and assumptions that have been silently causing problems, then model them into a precise, validated specification.
Who’s in the room: Business owners, operators, domain experts, and your technical leads.

Remote-ready: We run these across time zones on digital whiteboards. Your artefacts are born digital from day one.

Duration: 2–3 days.

02

Domain Alignment Audit

Once the model is validated, we hold your codebase up against it. Not a code review — we’re asking a different question: does your code accurately reflect what the business just agreed on? Every divergence is a finding tied to business impact, not developer opinion.

Deliverable: A prioritised remediation roadmap. Your team knows exactly what to fix, in what order, and why it matters.

Duration: 1–2 weeks, depending on codebase size.

03

Refine & Extend

Your business didn’t stop evolving when we shipped V1. We maintain the specification as your single source of truth. When the business moves, the spec moves first, and the system follows — precisely, without guesswork.

Options: Build to spec, data architecture, AI readiness, or methodology transfer. Details below.

The differentiator

Most consultants stop at the model. We prove it against your code.

A domain model is valuable. A domain model compared to your actual codebase is transformative. We trace every concept, state, boundary, and rule through your implementation. Every divergence is a finding — a naming mismatch, a missing state, a boundary drawn in the wrong place, a business rule that was never encoded.

Each finding is tied to a business impact. Not “you should refactor this” — but “this divergence is causing this business problem and here’s the path to fix it.”

Naming mismatch

The code calls it a “user.” The business calls it a “participant.” They mean different things — and the system treats them as one.

State mismatch

The code has three order statuses. The business has seven. Four real-world states are invisible to the system.

Boundary mismatch

The code treats billing and enrolment as one module. The business sees them as separate concerns with different rules.

Beyond the audit

The domain model is infrastructure, not a one-off.

Depending on what the audit reveals and where your organisation is headed, the model becomes the foundation for everything that follows.

Build to spec

Every requirement traceable. Every business rule testable. Nothing left to developer interpretation. Working software and the evidence that it matches what was specified.

Domain-to-data bridge

Flow the domain model into your data architecture — warehouse design, transformation layer, reporting. One number, one meaning, across the whole organisation.

AI readiness

Your AI agents reason within the constraints of your actual domain. They don’t hallucinate policies because the policies are encoded in the model.

The promise

We get you, and we get it right.

We are senior business analysts and engineers who care more about understanding your operation than shipping features. We ask hard questions early so you don’t discover the answers in production.

The audit has teeth

We don’t just model — we prove the model against your code and give you a concrete, prioritised list of what’s wrong and what to fix.

Independent by design

The workshop and audit produce artefacts any competent dev team can execute against — including yours. We build capability, not dependency.

Remote-first

We run workshops and audits across time zones with distributed teams. Digital whiteboards mean artefacts are born shareable.

If the spec says it, the system does it • If the system does it, the spec says why

How many spreadsheets sit alongside your systems?

That number is the size of the gap between your software and your business. Let’s close it.