Software engineering · Product and platform engineering
Systems someone else can safely change
Multi-tenant platforms, internal operational systems and customer-facing applications, built so that the person who inherits the codebase can deploy it, extend it and explain it without its author in the room.
Where this starts
Working at handover is not the same as finished
Software built at pace usually works on the day it is handed over. What tends to be missing is everything that makes it survivable: a deployment anyone can run, logs that explain a failure, an access model that can be audited, and a shape that lets the next feature be added without fear. The gap stays invisible until volume rises or the team changes, which is precisely when it is most expensive to close.
What we usually find
- A system that works and that nobody is willing to change
- Releases that depend on one person and a remembered sequence of steps
- Business rules living in a screen rather than in the model
- Permissions added after the fact and impossible to explain to an auditor
- A prototype about to take real customers and real money
- No way to answer what changed, when, and by whom
Our position
We treat a system as finished when someone other than its author can deploy it, extend it and explain it.
What the work covers
What we build, and what we insist on
The kind of system varies. The foundations do not, because they are what decides whether the thing is still serviceable in three years or quietly replaced.
Multi-tenant platforms
Workspace isolation, role-based access, subscription billing and self-service onboarding, serving many customers from one codebase without a branch per customer.
Internal operational systems
Inventory, orders, invoicing, scheduling and approvals in one place the business trusts, replacing the side files and workarounds that currently hold the real process and the real risk.
Customer-facing applications
Portals and data-heavy interfaces that can be used without training, tested on the devices and connections your customers actually have rather than the ones on our desks.
Domain modelling
The business rules expressed once, in the model, rather than repeated across screens and scheduled jobs where copies diverge quietly and nobody can say which is authoritative.
Access and audit
Federated identity, granular permissions, and revocation that removes access without destroying the history of what that account did.
Handover as a deliverable
Documentation written for the next engineer, a briefing for the team taking it on, and a period where they operate it while we are still available to answer.
How it stays cheap to own
Built so the next change is inexpensive
Most of what makes a system costly to own is decided in its first few weeks. These are the decisions we do not leave until later.
Schema
Versioned migrations from the first release, so a schema change is a routine deployment rather than an evening of arranged downtime.
Tests
A suite covering the rules the business actually depends on, fast enough to run on every change, which is the only condition under which it stays used.
Audit
A complete record of who changed what, written by the system as a matter of course rather than added the first time somebody asks for it.
Configuration
Environment differences held in configuration, so one artefact runs everywhere and "it worked on staging" stops being a category of defect.
Observability
Logging and tracing present from the first release, because instrumenting a service during an incident is not a plan.
What you are left holding
- A production system, deployed and running in your own accounts
- Infrastructure defined as code, owned by you
- A test suite covering the rules the business depends on
- Documentation and a briefing, so your team can take it on
- An audit trail the system writes for itself
Tell us what the business cannot do yet
We will come back with what it would take to build, what it would cost to run, and whether you should build it at all.