Software engineering · Product and platform engineering
Systems that someone else can safely change
We build multi-tenant platforms, internal business systems and customer-facing applications. We build them so that whoever takes over the code can deploy it, extend it and explain it without the original developer being there.
Where this starts
Working on the day of handover is not the same as finished
Software built at speed usually works on the day it is handed over. What is often missing is everything that keeps it working over time. That includes a deployment process anyone can run, logs that explain a failure, access controls that can be audited, and a structure that allows the next feature to be added safely. These gaps stay hidden until usage grows or the team changes, which is exactly when they are most expensive to fix.
What we usually find
- A system that works, but that nobody is willing to change
- Releases that depend on one person remembering a series of steps
- Business rules built into individual screens rather than into the core of the system
- Permissions added as an afterthought, which cannot be explained to an auditor
- A prototype about to handle real customers and real money
- No way to tell what changed, when, and who changed it
Our position
We consider a system finished when someone other than the person who built it can deploy it, extend it and explain how it works.
What the work covers
What we build, and the standards we insist on
The type of system varies, but the foundations do not. They decide whether a system is still usable in three years or has to be replaced.
Multi-tenant platforms
One codebase serving many customers, with each customer’s data kept separate, role-based access, subscription billing and self-service sign-up. There is no need for a separate version for each customer.
Internal business systems
Inventory, orders, invoicing, scheduling and approvals in one place the business trusts. These replace the separate files and workarounds that currently hold both the real process and the real risk.
Customer-facing applications
Portals and data-heavy interfaces that people can use without training. We test them on the devices and internet connections your customers actually use, not just the ones on our desks.
Modelling the business rules
Each business rule is defined once, in the core of the system. It is not repeated across screens and scheduled jobs, where the copies slowly drift apart and nobody knows which one is correct.
Access and audit
Single sign-on, detailed permissions, and the ability to remove someone’s access without losing the record of what they did.
A proper handover
We write documentation for the next engineer, brief the team taking over, and stay available for a period while they run the system themselves.
How it stays cheap to own
Built so the next change is inexpensive
Most of what makes a system expensive to own is decided in its first few weeks. These are the decisions we make at the start rather than leaving for later.
Database changes
Every change to the database structure is versioned from the first release. A change becomes a routine deployment, rather than an evening of planned downtime.
Tests
Automated tests cover the rules the business depends on. They are fast enough to run on every change, which is the only way tests continue to be used.
Audit
The system automatically keeps a complete record of who changed what. It is there from the start, not added the first time someone asks for it.
Configuration
Differences between environments are kept in configuration, so the same build runs everywhere. Problems that only appear in one environment become far less common.
Monitoring
Logging and tracing are in place from the first release. Adding them in the middle of an incident is too late.
What you are left with
- A live production system, running in your own accounts
- Infrastructure defined as code, owned by you
- Automated tests covering the rules the business depends on
- Documentation and a handover briefing, so your team can take it on
- An audit trail that the system keeps automatically
Tell us what you need the system to do
We will tell you what it would take to build, what it would cost to run, and whether you should build it at all.