Software engineering
How we build, and why it is done this way
Engineering practice is the part of a supplier that is hardest to judge before you have hired them, so here is ours in plain terms. Nothing below is a guarantee of outcome — it is how we work.
Principles
Six things we hold to
The domain model comes before the framework
We start by writing down the nouns and rules of your business and checking them with the people who live with them daily. Framework choice is a consequence of that model, not a starting position — which is why we do not have a single stack we apply to everything.
Contracts between components are explicit
Every boundary — between services, between the front end and the API, between your system and ours — has a written, versioned contract. It is the difference between a system that can be changed in parts and one that has to be changed all at once.
Tests are written with the code, not after it
Characterisation tests before touching legacy behaviour; unit and integration tests alongside new work. The point is not a coverage number — it is that a future change can be made by someone who was not in the room when it was written.
The deployment path is part of the deliverable
A build that only runs on a developer machine is not finished. Pipelines, environment definitions and rollback procedure are delivered with the application and documented.
We write down what we rejected
Architecture decisions are recorded with their alternatives and trade-offs. Two years later, the question is always "why is it like this?" — and the answer should not depend on whether the original engineer is still reachable.
Handover is the goal, not the exit
We would rather your team could maintain the system without us. Source, infrastructure code, credentials and documentation are transferred as a matter of course, not negotiated at the end.
Lifecycle
The phases of an engagement
- 01
Discovery
Domain modelling, constraint mapping, review of what already exists. Output is a written understanding you correct before anything is built.
- 02
Architecture
Target design, integration boundaries, data ownership, non-functional requirements. Trade-offs and rejected options recorded.
- 03
Delivery
Iterative increments, each reviewable and deployable, with tests and pipeline included. Scope changes re-costed openly.
- 04
Hardening
Load and failure behaviour, security review, observability, runbooks. The unglamorous phase that decides whether launch week is calm.
- 05
Handover
Source, infrastructure definitions, documentation and a working knowledge transfer to your own engineers.
- 06
Aftercare
Optional, bounded and written down — a support arrangement with a stated scope, never an open-ended dependency.
Honesty
What we cannot tell you
You will not find client logos, case studies, testimonials or delivery statistics on this site. That is deliberate. Our client work is covered by confidentiality, and we are not willing to publish invented figures or unattributed praise to fill the gap — which is what most pages in this position do.
What we can offer instead is a conversation with the engineers who would do the work, references provided directly to a serious prospect with the client’s permission, and a company whose legal existence and filing history you can check in a public register in under a minute.
Check the register entry