Systems that survivetheir second year.
Web applications, APIs and platforms designed around your domain rather than around a framework. The architecture is as much of a deliverable as the screens are, because the cost of a system is set by how easily its fifth change can be made — not its first.
- X
- StructureModules, contracts, tests, boundaries.
- Y
- JudgementWhat to build, what to leave out, what to retire.
The shape of the system is the decision that lasts.
Frameworks are replaceable. Boundaries are not — a contract in the wrong place costs for years. So the first thing we produce is this drawing, in your language, with the parts that already exist marked as they are.
One record on the right, one contract in the middle, and surfaces that can be added without reaching around the back.
- 01
Architecture
the shape of the system
- 02
Modules
one responsibility each
- 03
Systems
what already exists
- 04
APIs
the contract between them
- 05
Platforms
what people use
Four ways a codebase tells you it needs work.
None of these are unusual. All of them are cheaper to fix deliberately than to work around for another year.
It works, but nobody dares change it
No tests, no seams, and one person who understands it. Every small request becomes a negotiation. The first work is usually to make change safe, not to add features.
Four tools, four versions of the same record
Spreadsheets and SaaS that each hold part of the truth, reconciled by hand. One data model with one owner per fact removes a whole category of work.
The build finished and the knowledge left
A working system with no documented decisions is a system you rent from whoever wrote it. Structure, naming and written architecture are part of the handover.
It cannot carry the next order of magnitude
Not imaginary scale — the growth you are actually planning. Usually the fix is a boundary, a queue or an index, identified before it becomes an incident.
- D1
Product platforms
A product other people depend on: accounts, permissions, records, workflow, reporting, and an admin surface the team running it can actually use.
- Multi-role access
- Workflow and approvals
- Reporting surface
- Audit trail
- D2
Internal systems
Operations tooling that replaces the spreadsheet everything currently depends on, with the process encoded once instead of remembered by five people.
- Single source of record
- Document generation
- Integrations
- Bulk operations
- D3
APIs and integration layers
Typed, documented, versioned interfaces between systems that were never designed to meet — including the unglamorous part, where the other side is inconsistent.
- Typed contracts
- Versioning
- Idempotent writes
- Rate limits
- D4
Modernisation
Replacing a system that has to keep running while it is replaced. Seams first, migration second, retirement last.
- Seams and adapters
- Incremental migration
- Data backfill
- Retirement plan
- L1Product surface
- TypeScriptReactNext.jsDesign systemsAccessibility
- L2Services
- Node.NETPythonRESTQueues and jobs
- L3Data layer
- PostgreSQLSQL ServerMigrationsCaching
- L4Quality
- Automated testsCode reviewType safetyCI gates
- 01
Read the system as it is
Including the parts that exist only in one person's head. The written account of today comes before any proposal.
- 02
Draw the boundaries
Modules, contracts and ownership. Most architecture arguments are really arguments about where a boundary belongs.
- 03
Build in thin slices
End-to-end increments against a running environment, so progress is something you can open rather than something you are told about.
- 04
Leave it maintainable
Tests that describe intent, decisions written down, and a repository a second team can pick up without an introduction.
Send us the system you are nervous about.
A codebase you have inherited, a platform that has outgrown its first design, or a product that still only exists as a document. We will come back with the structure we see, and what we would build against it.