Tests before the rewrite
We do not replace a system we cannot characterise. Behaviour gets covered first, including the behaviour nobody documented, and then the replacement happens in slices.
How we work
Complex software deserves a better process.
We don’t jump from a sales call straight into development. First we understand the business, define the problem, shape the solution and set the architecture. Then a senior engineering team builds it, and you can check every stage against what is written here.
The process
Six stages, each ending in something you can read.
Every stage produces a document or a working system rather than a status update. If a stage produces nothing you can read, it didn’t happen.
01
Understand · Within 1 business day
We learn the business before we talk about software.
A senior engineer who could work on your project reads what you send and replies with questions, an initial view, or a straight answer that we are not the right firm. Then a 45 minute call about the problem, not a sales pitch. Bring whoever knows why the current system is the way it is, because that person has the information that decides the estimate.
What we learn
- What your business does
- The problem you’re solving
- Who uses the system
- What isn’t working today
- What success looks like
- Existing technology
- Constraints and integrations
- Security requirements
02
Shape · Within a week
We turn the problem into a plan you can check.
You get a written approach: how we would build it, in what order, with a cost and time range and the assumptions behind them. It is written plainly enough to forward to a board. When you are ready, a fixed proposal follows, with scope, price and milestones in writing and a like-for-like comparison against conventional delivery. If we cannot beat that meaningfully, we say so and decline.
What the plan covers
- Product requirements
- User flows
- Technical architecture
- Data architecture
- Where AI helps, and where it doesn’t
- Integrations
- Security and scalability
- Delivery roadmap
- Risks and dependencies
03
Build · Throughout the build
Senior engineers build it in the open.
Experienced engineers turn the plan into production software in short iterations. You get repository access from day one, a running environment as soon as there is something to run, and a written note every week covering what shipped, what didn’t, and what changed in the estimate.
How the work is done
- Agile iterations
- AI-assisted engineering
- Code review on every change
- Automated tests
- Documentation kept current
- Infrastructure as code
04
Validate · Before handover
Software isn’t finished because it compiles.
An engineer who did not build the system spends a week trying to break it: load, authentication, data handling and failure modes. You get every finding, including the ones we did not fix and why.
What we check
- Functional correctness
- User experience
- Performance
- Security
- Reliability
- Integrations
- Edge cases
- Production readiness
05
Launch · At release
We move to production responsibly.
Every release can be rolled back, and the rollback is rehearsed before launch rather than assumed to work. Deployment is a human action with a name against it. The runbook is written for someone who has never met us, so your team can deploy without calling.
What launch covers
- Infrastructure
- Deployment
- Monitoring
- Security
- Data migration, where needed
- Handover to your team
- Launch support
06
Evolve · After launch
Good software gets better as the business changes.
The engineers who built your system are the ones who keep improving it, with no handover to a support tier that has never seen the code. Retained work has no minimum term: thirty days’ notice, and we help you move.
What continues
- Improvements
- New features
- Optimisation
- New AI capabilities
- Security updates
- Performance work
- Infrastructure scaling
The standard
What is true of every engagement, without being asked.
Reversible deployment
Every release can be rolled back, and the rollback has been executed at least once as a drill rather than assumed to work.
Decisions recorded
An architecture decision record for every significant choice, including the options we rejected. In three years that document is worth more than the code it explains.
Security from the design stage
Threat modelling happens at design, dependencies are watched continuously, and secrets never reach the repository. There is no security sprint at the end.
Documented for a stranger
The runbook is written for someone who has never met us. If your team cannot deploy it without calling, the handover is not finished.
The 2am rule
If we would not be willing to be woken up for it, we do not ship it. It is a blunt test and it removes a surprising amount of argument.
AI-first engineering
AI speeds up the engineering. Engineers stay accountable for it.
We use AI through the whole lifecycle, from discovery and requirements to architecture, testing, documentation, code review, debugging and maintenance. It removes repetitive work and shortens each iteration, so our engineers spend more of their time on the problems that need expertise.
It does this
- Reads a legacy system faster than any of us can, and produces the map we then verify.
- Writes the first draft of tests, migrations and boilerplate that a person then owns.
- Reviews every change before a human does, catching the ordinary mistakes so review time goes on the interesting ones.
- Turns a specification into an evaluation harness, which is how we know a thing is done.
It never does this
- Merges its own work. Every change is approved by a named engineer who is accountable for it.
- Touches production. Deployment is a human action with a name and a timestamp against it.
- Sees client data it does not need. Boundaries are set at the start of the engagement, in writing.
- Excuses a defect. If it shipped broken, that is ours, and how it was written is not a mitigation.
What you own
All of it, on the day we finish.
The code outright
Full intellectual property, in your repository, with its commit history intact.
No lock-in
Mainstream technology throughout. Nothing in the stack requires us specifically.
The documentation
Runbook, decision records and infrastructure as code, written for someone new.
The right to leave
No minimum term on retained work. Thirty days’ notice, and we help you move.
Next step
Have a complex project in mind?
Tell us what you’re trying to build. We’ll help you understand what it will take to build it properly.
