The most expensive digital projects are not the ones that cost the most to build. They are the ones that get built wrong – and then cost twice as much to fix. Our approach is designed to prevent that.
Twenty-five years of delivery has produced a consistent finding: The projects that fail do not fail in the build phase. They fail in the conversation that happened before the build – or more often, the conversation that did not happen at all.
Scope that was never fully agreed. Data relationships that were never mapped. User roles that were added as an afterthought. Edge cases that were assumed to be simple. These are the things that turn a six-week project into a six-month one.
Our process is structured around eliminating those failure modes before they become expensive. It is not a methodology for its own sake – it is the accumulated experience of knowing exactly where things go wrong and building in the checkpoints that stop them.
25+
Years of delivery informing this process
10+
Years average client relationship – the real measure of process quality
0
Proprietary platforms, lock-in clauses, or systems you cannot take elsewhere
These are not stages we move through quickly to get to the interesting part. Each phase has specific outputs that the next phase depends on.
Understanding the problem before proposing a solution.
What happens
We begin by understanding your organisation – not just the feature list you have in mind, but the business processes the system will need to support, the people who will use it, and the data it will need to handle.
This involves structured conversations with stakeholders, a review of any existing systems or processes being replaced, and a careful analysis of user roles, permissions, and workflows. We ask difficult questions – including ones that reveal when what you have asked for is not actually what you need.
For complex projects, this phase includes a formal discovery document: A written record of what has been agreed, what the system will and will not do, and the assumptions underpinning both. This becomes the contract that protects you as much as it protects us.
What you get
Discovery is occasionally billable as a standalone engagement for complex projects. The output is valuable in its own right – and if you choose not to proceed with us, you own it completely.
Designing the system before building it.
What happens
Architecture is the phase most agencies skip or compress – and it is the one that causes the most problems later. Before any code is written, we design the complete structure of the system: The data model, the application logic, the user journey flows, and the platform choices.
Platform selection is made here, matched to the specific requirements of your project. We do not begin with a preferred platform and fit your requirements around it. We assess what the system needs to do and select accordingly – prioritising robust, widely-supported technologies with strong long-term futures and large developer communities.
Security architecture is also addressed at this stage – not added as a layer afterwards. Access control, data validation, encryption requirements, and audit logging are designed into the system from the start.
What you get
This is where expensive mistakes do not get made. An extra week in architecture routinely saves four to six weeks in build – and avoids the far greater cost of re-architecting a live system.
Incremental delivery. Working software throughout.
What happens
Build proceeds against the milestones established in architecture. Each milestone delivers working, testable software – not a progress update, not a percentage complete, but actual functionality you can use and evaluate.
Development is non-destructive by default. Changes are made incrementally, with version control throughout. At no point is there a situation where the old system is gone and the new system is not yet ready. Rollback is always available until you are satisfied.
We write clean, well-documented code – not because it looks professional, but because you will need to maintain this system in three years, possibly with a different developer, and code that cannot be understood cannot be maintained. Clarity is a feature.
What you get
We do not disappear for three months and reappear with something finished. You will see and be able to use the system throughout the build – which means you can spot problems early, when they are still cheap to fix.
A system is only as good as the team using it.
What happens
Launch is not the end of the engagement – it is the point at which the real-world test begins. We remain involved through the post-launch period, monitoring for issues, responding to user feedback, and making the adjustments that only become visible once real users are in the system.
Documentation is produced for every system we build – written for the people who will use and administer it, not for developers. Where training is appropriate, we provide it. The goal is a system your team can operate independently, with us available as a resource rather than a dependency.
Most clients move into an ongoing support and development relationship at this point – retaining us to maintain the system, implement improvements, and respond to issues. This is where the majority of our long-term client relationships are based.
What you get
We have clients we have supported continuously for over ten years. That is not dependency – it is the outcome of building something worth maintaining, and then maintaining it well.
Every project is different. But the shape of a well-run engagement tends to be consistent.
Week zero
A call or meeting with no agenda beyond understanding your situation. We listen more than we talk. We ask about the problem you are trying to solve, what has been tried before, who will use the system, and what success looks like. We do not bring a proposal – we leave with enough understanding to write one that is actually useful.
Weeks one to two
For straightforward projects, this is a detailed written proposal with a fixed price and a clear scope. For complex projects, it is a paid discovery engagement that produces a document both parties can build a contract around. Either way, there are no surprises about what is and is not included.
Weeks two to four
The data model is mapped. The platform is confirmed. The build milestones are agreed. A staging environment is set up and you are given access. Before a line of production code is written, you already have a clear picture of what the system will look like and how it will work.
Build phase
Each milestone delivers something you can use. You test it, give feedback, and sign it off before we move to the next. Progress updates arrive regularly, in plain language. If something needs to change – and something usually does – we discuss it openly, agree the impact on scope and timeline, and proceed. Nothing is hidden, nothing is rushed.
Launch
Launch day is carefully managed – not a moment of collective anxiety, but a controlled transition that has been rehearsed on staging. The post-launch period is when real users reveal the things testing never quite anticipates. We remain close, respond quickly, and treat post-launch adjustments as part of the job rather than out-of-scope extras.
Year one and beyond
Most clients move into a retained support arrangement – a predictable monthly cost that covers maintenance, security updates, minor improvements, and a guaranteed response time. Others prefer a time-and-materials basis for ongoing work. Either way, the relationship continues: We know your system completely, and you are never starting from scratch with someone new.
Commitments are only meaningful if they include the things you will refuse as well as the things you will deliver. These are ours.
We will not underscope to win a project
A low initial estimate that grows by 40% during the build is not a bargain – it is a failure of honesty at the scoping stage. We price accurately from the start, even if it means losing a project to a cheaper quote that will later prove otherwise.
We will not build lock-in
Your codebase is yours. Built on robust, open, widely-supported platforms with large developer communities. Fully documented. Transferable to another developer without our involvement if you ever choose to move on. We want you to stay because the work is good, not because leaving is too difficult.
We will not push a preferred platform
We have no commercial relationship with any platform vendor, no reseller arrangement, and no financial incentive to recommend one technology over another. Platform selection is made on the merits of your specific requirements – and we will tell you honestly when a simpler solution would serve you better than a complex one.
We will not disappear after launch
Every system we build is a long-term commitment. We remain reachable, we respond quickly, and we treat the ongoing health of what we have built as part of our responsibility – not an optional extra available only on a premium support plan.
We will not write code we cannot explain
Clever code that only one person understands is a liability, not an asset. Everything we write is clear, well-structured, and documented. If you asked another competent developer to look at it in five years, they would be able to understand and extend it without starting again.
We will not take a project we are not right for
If what you need is outside our expertise, or if another supplier would genuinely serve you better, we will say so – at the first conversation if that is when it becomes clear. Our reputation is built on outcomes, and a project that goes badly is bad for everyone.
There is no pitch, no deck, and no sales process. A first conversation with us is exactly that – a conversation. We listen to what you are trying to achieve, ask the questions that help us understand your situation clearly, and give you an honest initial view of what is involved.
It typically runs thirty to forty-five minutes. It costs nothing and commits you to nothing. If it becomes clear during that conversation that we are not the right fit, we will say so – and we can usually point you towards someone who is.
If there is a good fit, the next step is a written summary of what we have understood, followed by a proposal or a scoping engagement depending on the complexity of the project. Everything at a pace that suits you.
Start a conversationCome prepared to discuss
None of this is a requirement. Come with whatever you have – even if that is only a vague sense that something needs to change.
A first conversation costs nothing and commits you to nothing. We will give you an honest view of what is involved – and whether we are the right people to do it.