Domain modelling
We turn a process that lives in habit into named entities, state transitions, and the rules that decide them. Departments disagree here, months before that disagreement becomes a bug.
Domain model diagramsSoftware
Software that fits how your business actually runs
For teams whose core process is the advantage, not the overhead, and no product on the market can represent it. We make the tacit rules explicit and hand over the codebase.
- Fixed scope
- Demo in 14 days
- Full IP transfer
- 30-day warranty
What bespoke actually buys you
Most software problems should be bought, not built. Payroll, helpdesk, accounting — someone has already solved those better and cheaper than a bespoke build ever will. Custom earns its cost in exactly one place: the process that is the reason customers choose you over the alternative. Force that process into a generic product and you sand off the edges that make the money, then pay a subscription for the privilege.
The hard part is rarely the code. It is that the requirements do not exist in writing: they live in a spreadsheet with fourteen tabs, an email thread, and the head of the person who has done the job for nine years and knows which cases to escalate. Getting those rules out and making them explicit is most of the work and all of the risk — and the reason we write for the engineer who inherits the codebase, not for ourselves.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Requirements live in people, not documents | Scope is discovered, not received | Paid teardown of real cases first |
| Systems of record stay authoritative | Two-way sync, not a rewrite | Idempotent writes and daily reconciliation |
| Legacy data contradicts the new model | The model must accept invalid history | Dry runs and a reconciliation report |
| The old process cannot stop | Both systems run at once | Parallel run with rollback until cutover |
| Your engineers inherit the codebase | One obvious way to do things | Boring stack, tests on exceptions |
In scope
- Domain model and workflow state machine
- Operator back office and audit trail
- Integrations with your systems of record
- Data migration, cutover, and runbook
Not in scope
- Rebuilding a SaaS product that already fits
- Ongoing on-call cover past the warranty
- Rewriting the legacy system we integrate with
Handled by
- Maintenance & SupportRetainer cover, SLAs, and change work once the warranty ends
- Legacy Application ModernizationReplacing or restructuring the old system itself, not just integrating with it
What we build
Workflow and exceptions
Approvals, rejections, partial completions, reversals, and the case that skips two steps because a director said so. The happy path is a week; the exception paths are the system.
Annotated workflow mapIntegrations with systems of record
Two-way sync with the ERP, CRM, or billing system that stays authoritative. Retries, idempotency keys, and a daily drift report, because the integration that fails quietly is the one that hurts.
Reconciliation job and alertsMigration and backfill
Years of records move out of the old spreadsheet or database, including rows that break your new constraints. We migrate in dry runs and publish a reconciliation report finance can check.
Dry-run migration reportPermissions and audit trail
Role and record-level access, plus an append-only history of who changed what, when, and on whose authority. Retrofitting that later means rewriting every write path, so it ships in slice one.
Append-only audit logOperator and support tooling
The back office where your team fixes what the workflow could not handle: reassign, reopen, re-run, override with a reason. Systems get abandoned when correcting them requires a developer.
Operator back officeHow the work runs
- 01Week 1
Workflow teardown
We sit with the people who do the job and walk real cases end to end, including the ones that went wrong last month. Every rule living in someone’s judgement gets written down and challenged.
You getAnnotated workflow map and domain model
- 02Week 2
Scope cut and slice
We decide what the system owns, what stays manual, and what a bought product handles better, then price it. By day fourteen one real case runs end to end on production infrastructure — no mock screens.
You getFixed scope and a working demo
- 03Weeks 3 onward
Build and parallel run
Slices ship behind flags every week or two while the old process keeps running alongside. We compare both outputs daily and treat every mismatch as a defect in the model until proven otherwise.
You getWeekly releases and mismatch log
- 04Final two weeks
Cutover and handover
We pick a cutover date with a rollback plan, migrate the remaining data, and retire the old process. We then walk your engineers through the codebase on camera and hand over the runbook.
You getLive system, runbook, recorded handover
What you are handed
- Annotated workflow map with exception cases
- Domain model and state diagrams
- Fixed scope with a priced change list
- Production system in your cloud account
- Migration scripts and reconciliation reports
- Test suite covering the exception paths
- Runbook with named failure modes
- Full source, git history, and IP transfer
- Recorded codebase walkthrough for your engineers
Typical stack
Application
TypeScriptPythonDjango + DRFNext.jsGo
Data and state
PostgreSQLRedisCeleryTemporalDebezium
Delivery
DockerTerraformGitHub ActionsAWS / GCPPlaywright
Operations
OpenTelemetryGrafanaSentrypgBackRestKeycloak / Auth0
The calls we make, and why
Should we build this at all, or configure something we can buy?
Buy it, unless the workflow is why customers choose you
We spend the first days looking for a product that covers the job, and if one gets close we say so and bill you for the discovery, not the build. Bespoke earns its cost when the gap sits in the differentiating step.
We’d choose otherwise whenthe vendor data model cannot represent your core object, or licensing outgrows ownership
Microservices from the start, or one application?
One deployable application with hard module boundaries
We hold that line longer than most teams expect. Splitting early converts compile-time errors into pager duty at 3am and stretches every cross-boundary investigation into a distributed tracing exercise. Module boundaries give you the same discipline without the network in between.
We’d choose otherwise whena component has a different scaling profile, compliance boundary, or its own release cadence
Should the AI-assisted step be in version one?
Usually not — the deterministic workflow ships first
We say that as a studio that builds AI systems. A model-driven step needs labelled outcomes and a fallback for when it is wrong, and neither exists until the deterministic workflow has run in production long enough to produce them.
We’d choose otherwise whenthe input is unstructured language or documents no rules engine can classify
Do we write the full specification up front or work it out as we go?
Neither — fix the model and first slices, rank the rest
We specify the domain model and the first two slices in enough detail to fix scope and price on them, and keep the rest as a ranked list re-priced at each milestone. Full up-front specs are wrong by the third slice; open-ended discovery has no ceiling.
We’d choose otherwise whena regulator or a procurement process demands the whole document before work starts
This fits if
- Your core process runs on spreadsheets and one person who knows
- No off-the-shelf product can represent your core business object
- You need audit history regulators or customers will ask to see
- You have in-house engineers who will own the codebase afterwards
- The tool you built years ago breaks at today’s volume
Look elsewhere if
- You want a cheaper rebuild of a SaaS product that fits
- Nobody on your side can give four hours a week
- You are buying on lowest bid; someone always quotes half
EngagementFixed-scope build
Typical length8–16 weeks
How it startsA paid two-week discovery: workflow teardown, domain model, fixed scope and price, one working slice.
Questions we get asked
Who owns the code and the IP?
You do, in full, including anything produced with AI assistance. The repository sits in your organisation from the first commit, the system deploys into your cloud account, and there is no runtime licence, no per-seat fee, and no component of ours you must keep paying for. Open-source libraries carry the same rights anyone else gets.
What happens if we want to move to another team, or you disappear?
You keep working, because nothing depends on us being reachable. Everything runs in infrastructure you control, defined in code you hold, with a runbook written for the on-call engineer and the recorded walkthrough your engineers received at handover. If you move to another team we run a paid transition and answer their questions during it.
Can our own engineers maintain it, or are we locked into your choices?
They can, and that constraint shapes the stack rather than the other way round. We build on widely used, boring technology chosen for the hiring pool in your market, not for what interests us. Where we use something less common — a workflow engine, say — we write down why, and what the migration path looks like.
You use AI to write code. How do we know it is maintainable?
The standard does not change based on who typed it. AI-written code fails differently from human code — plausible calls to functions that do not exist, error handling inconsistent between two files written an hour apart — so review targets those patterns specifically, and exception paths carry tests regardless of how the code was produced.
What if it ships and people keep using the old spreadsheet?
That is the failure mode we design against, which is why the old process runs in parallel instead of being switched off on launch day. Every mismatch between the two is investigated before cutover, so the people doing the work see their edge cases handled before they are asked to trust it. The thirty-day warranty covers the rest.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.