Discover, Design, Build, Deploy.
Four stages for every build, with the price fixed at the end of stage two. Skipping stage two is how technology projects end up over budget and unused.
How we work: Discover, Design, Build, Deploy
- 01
Discover
Understand the business and identify opportunities.
We sit with the people who do the work and map how it actually happens, not how the process document says it happens. Then we rank what’s worth changing.
- Stakeholder interviews
- Workflow and systems mapping
- Data and access review
- Opportunity scoring by value, effort and risk
- Output
- A ranked, costed list of opportunities
- Typical duration
- 1 to 3 weeks
- 02
Design
Define the system, workflow and technical architecture.
Before anything is built, the specification is written and signed off: inputs, outputs, decision points, failure handling and what "working" means. This is where the price gets fixed.
- Technical architecture and data model
- Workflow specification with exception handling
- Interface design and prototype where relevant
- Fixed-price scope agreed in writing
- Output
- A signed specification and a fixed price
- Typical duration
- 1 to 3 weeks
- 03
Build
Develop and integrate the solution.
Built against your real systems in increments, with something working at the end of every one. You see progress weekly rather than at the end.
- Incremental development with weekly demos
- Integration with your live systems
- Testing against real data in parallel with the manual process
- Security, error handling and monitoring built in
- Output
- A working system validated on real data
- Typical duration
- 2 weeks to 6 months by scope
- 04
Deploy
Launch, measure and optimise.
Go live with monitoring in place, a named owner and documentation your team can use. Then we measure what it’s doing and tune it.
- Production deployment and cutover
- Monitoring, alerting and runbook
- Team training and handover
- Post-launch tuning window
- Output
- A running system your team owns
- Typical duration
- Ongoing from launch
Six commitments, in every engagement
These are in the contract, not the pitch deck.
A written specification before a price
We don’t quote against a conversation. The specification defines inputs, outputs, decision points, failure handling and what "done" means, and you sign it before the build starts.
Fixed price, staged payments
The price is fixed against that specification and split across delivery milestones. If we estimated badly, that’s our problem, not a change request.
Weekly working software
From the first build increment you see something running, every week. No three-month silence followed by a reveal.
Tested against real data
New systems and automations run alongside the existing process until the output matches. We don’t go live on the strength of a demo.
You own everything
Source code, infrastructure accounts and data transfer to you on final payment, with documentation and a deployment another engineer can perform.
We’ll tell you not to do it
If a process doesn’t need software, a product you can buy would do the job, or the data isn’t there yet, we say so during discovery rather than taking the build fee.
How an education engagement runs
Training is built around a real problem your team needs solved, so the learning and the deliverable are the same piece of work.
- 01
Establish the starting point
Who is being trained, what they can already do, and which real problem they’re going to build against.
- 02
Practical training
Workshops on the tools and the workflow, worked through on your problems rather than a sample project.
- 03
Guided implementation
They build something real. We review the design and the code while they do it, and correct course early.
- 04
Ongoing support
Available for review and the hard questions once the formal sessions finish, for as long as it’s useful.
Why technology projects disappoint
We’d rather tell you this before you spend money than after. Almost none of these failures are about the technology.
- 01
The tool was bought before the process was understood
A licence doesn’t change how work moves. Software gets purchased, nobody changes the process around it, and the seats go unused.
- 02
The business was bent to fit the software
When the product can’t do what you need, the team works around it. Every workaround is a cost that never appeared in the business case.
- 03
The demo was never meant to run
Demos are built on clean data and a happy path. Real operations are neither. If the exceptions were not scoped, the exceptions are the project.
- 04
The people doing the work were not involved
Systems imposed on a team get quietly routed around. The people who do the work have to shape what’s built, and understand it once it is.
- 05
Nobody owned it after launch
Anything that depends on changing data needs someone watching it. With no named owner, the first bad week ends the project.
- 06
Success was never written down
If the goal was never stated in hours saved, errors removed or cost avoided, there’s no way to tell whether it worked, or to defend the budget next year.
Our process exists to close each of these off before a line of code is written. That is what the specification stage is for, and why we fix the price against it.
The things people ask before they commit
Businesses where the way the work moves has become the problem: too many tools, too much retyping, a spreadsheet nobody else understands, or software that was built for someone else. Size matters less than whether there’s a real process to improve, and the smallest engagement is a short audit.
Not always, and anyone who says otherwise is selling something. A build has an upfront cost a subscription doesn’t. It tends to win when per-seat fees keep growing, when the workarounds are costing real hours, or when your process is what makes you different. We do that arithmetic with you before you commit, and if a product you can buy fits, we’ll tell you to buy it.
Then that’s what we tell you. Sometimes the fix is a process change, a module you already pay for, or cancelling a tool. The audit is priced to stand on its own, so we have no reason to steer you towards a build.
Yes, that’s our Education & Enablement service. We train your people on AI coding tools and a proper development workflow, using your real problems, then support them while they build. You keep the capability rather than renting it from us.
Fixed price against a written scope. We agree a specification first, then quote against it. We don’t bill by the hour for clearly defined work, which means the risk of the estimate sits with us rather than you.
Yes. Source code, infrastructure and data transfer to you on final payment. Handover includes documentation and a deployment another engineer can perform. There’s no lock-in and no licence to keep paying.
Where it genuinely removes work, yes: drafting, summarising, pulling data out of documents, searching your own information. It sits behind an abstraction so the provider can change, we document which provider sees your data and where, and we never send your data to one that trains on it without your sign-off. Plenty of good solutions involve no AI at all.
Not yet. Autonomous agents are in development and deliberately not for sale until the evaluation and guardrail work is done. Most requests described as needing an agent are better served today by an automation or a system with an assistant built into it.
An audit is 2 to 4 weeks. A single automation is 2 to 4 weeks. A prototype is around 6 weeks. A production system is 3 to 6 months. Training is scheduled around your team. Every proposal carries a dated plan.
No, but data quality is one of the biggest drivers of cost. Part of the audit is telling you honestly what state your data is in and what it would take to use it.
Every build includes a post-launch tuning window and a documented handover. After that you choose: we maintain it under a monthly support arrangement, your own team takes it on (we can train them for that), or you hand it to someone else.
The United Kingdom. We work remotely with businesses across the UK and internationally, and we’ll come to you for discovery where it matters.
Next step
Tell us what the work is costing you.
Five short questions about the business, the problem and the budget. We’ll come back with a view on scope, cost and whether it’s worth doing at all.