Before stage one
Almost nobody does at the start, including businesses that end up commissioning something substantial. Working out what the right thing is — and what is not worth building — is the first part of the job, not a prerequisite for calling us.
Enough to start
No technical vocabulary needed. “Everyone spends Monday morning copying things between two systems” is a better brief than most specifications.
The stages
Every stage produces something you can read, use or make a decision against. A stage that produces only reassurance is a stage that has not happened.
The business, the current systems, the workflows and where they hurt.
We sit with the people doing the work, not only the people commissioning it. The interesting detail is almost never in the brief — it is in the spreadsheet somebody rebuilt because the official system could not handle a case that happens twice a week.
You get
A written account of how the work happens now, and where the cost is.
Decide what the right solution is before development starts.
What gets built, what deliberately does not, how it fits the systems you already run, and what the first useful version looks like. This is also where we tell you if the answer is smaller than you expected, or if it is not software at all.
You get
A scope, a shape, and a cost you can make a decision against.
Develop the application, with working software to look at throughout.
You see it working as it is built rather than at the end. Modern engineering practice underneath: version control, automated tests, code review, a staging environment separate from production, and deployments that can be undone.
You get
Working software on a staging environment, updated continuously.
Review access, authentication, data, dependencies and the real risks.
A deliberate pass over the things that are easy to get almost right: who can reach what, what is logged, where secrets live, what happens to data you no longer need, and which dependencies carry known vulnerabilities.
You get
A security review you can read, with what was found and what was changed.
Test, migrate, deploy and watch it carefully.
Including the unglamorous parts: moving existing data across, training the people who will use it, and a plan for the first week when the things nobody predicted show up. Monitoring goes live before the users do.
You get
A system in production, and people who know how to use it.
Keep developing it as the business changes.
Fixes, refinements, new features, security updates and the next part of the business it should cover. This is where most of the value of a custom system is realised, and it is the part most projects skip.
You get
A monthly rhythm of changes, and someone who is responsible for it.
What we need from you
Access to the people who actually do the work. Not a lot of their time — but the real detail is never in the brief, it is in what someone does every Tuesday to get around a limitation nobody has written down.
How we deliver
Asked often enough to answer hereWe use AI tooling extensively in our own engineering — for writing and reviewing code, for research, and for the documentation that usually gets skipped. It is why a small team can take on the amount of work we do, and it is a reason our costs are what they are rather than a feature you are buying.
What does not change: a person is responsible for every decision, every line that reaches your production environment has been reviewed by one, and the security choices are made deliberately rather than accepted from a suggestion. You are buying the outcome and the accountability for it.