Process
Most of the work happens before anyone writes code.
Four stages. Each one has a question it has to answer before the next starts — and if the answer isn't there, we don't move on. Sometimes that means telling you not to build. No ten-step waterfall diagram, no phase that exists to fill a proposal.
The four questions
Analysis What is this costing you, and how does the work really flow today?
One stage, two jobs. First, name the problem in numbers: the orders that don't complete, the spreadsheet three people email around, the forty minutes someone spends every Friday moving data between two systems that don't talk.
Then map how the work actually happens — step by step, including the workarounds nobody wrote down, because that's usually where the real requirement is hiding. The process on paper is rarely the process in practice. Alongside it we check the idea against the market: who else serves these customers, what they already expect as standard, what they'd actually pay for.
Requirements come out of this ranked, not listed. This is the stage where scope gets cut, and that's the stage doing its job.
You get
- Problem statement with a cost attached
- Process map — how it works now, how it should work
- Requirements ranked must / should / later
- Market and competitor scan
- What we're deliberately not building
Gate Every requirement traces back to a step in the map or a demand in the market. The ones that don't get dropped.
Architecture What should the system be, and what should it be built with?
Solution architecture before code. How the pieces fit together — the application, the data store, the payment and identity providers, the accounting and CRM systems already in the building — where each piece of data lives, what talks to what, and what happens when one of those parts goes down at 4pm on a Friday.
Technology gets chosen for your business, not for our preference. The constraints that decide it are who maintains it after we leave, what it costs to run in year three, how it behaves at ten times the volume, and what it has to comply with. If something off the shelf does the job, we'll tell you that instead of quoting you.
You get
- Solution architecture on one page
- Integration and data map
- Technology decision record — with the options we rejected, and why
- Running-cost and scaling estimate
- Build vs. buy vs. extend recommendation
Gate You can explain the architecture to someone else without us in the room.
Build Does the thing being built still match the thing we agreed?
Design and engineering run together rather than being handed off in sequence. You see the system working in short cycles — on a real environment, with real data flowing through it, not as a flat picture of a screen.
Every piece of work traces back to a ranked requirement from stage 01. Testing happens as it's built: the paths users take, the edge cases, the integrations, the moments something upstream fails. Changes are cheap now and expensive after launch — which is the entire reason we show you the system while it's still soft.
You get
- Working system on a staging environment, updated continuously
- Design reviewed in the real interface
- Progress tracked against the ranked requirements
- Test coverage on the paths that matter
Gate Nothing ships that isn't traceable to a requirement you approved.
Delivery & maintenance Is it live, owned by your team, and staying healthy?
Launch is a checklist, not an event. Performance measured rather than assumed, security reviewed, data migrated and reconciled, integrations run end to end with real transactions, monitoring and alerts confirmed to be firing. A rollback plan ready before it's needed. Every item green, or launch waits.
Then it becomes yours. Admin and configuration set up around the changes your team makes weekly, documentation written in the words they actually use, and a walkthrough recorded so the next person to join can watch it instead of guessing. All access and credentials in your name from day one.
After that, the system keeps running: monitoring and uptime, security patches and dependency updates, a defined response time when something breaks, and a small improvement backlog reviewed with you rather than accumulating in silence. Support is there when you want it. Dependence isn't the business model.
You get
- Signed-off launch checklist and rollback plan
- Monitoring, alerting and backups in place
- Documentation and recorded handover session
- All accounts, code and credentials in your name
- Maintenance agreement — patching, updates, response times
- Improvement backlog, reviewed on a set cadence
Gate Someone on your team completes a real task in the live system, unaided, while we watch.
It starts with the first question.
A discovery conversation — no cost, no deck. Bring the problem and we'll tell you whether it's worth building.
Book a discovery call