Our approach
Where the project is won or lost: the scoping stage
The scoping stage is where a project is won or lost. This is where we set the scope, identify the structural choices, and rank features by value and criticality — before a single line of code is written. When the scoping stage is short or rushed, the project pays the price later: features that go unused, business rules misunderstood, dependencies discovered only in production. When it is done properly, the project moves forward with a saving of effort that shows all the way to delivery.
Scoping a business application is not about producing an exhaustive specification that would freeze every decision upfront. It is about isolating what must be settled early — the structural, irreversible choices — and organising the rest so it can take shape as the project advances, without costing much to change. The whole exercise comes down to telling apart what must be stable from what must be able to evolve.
To do this, we rely on three proven decision frameworks, whose combination shapes our trade-offs.
Our decision frameworks
Three decision frameworks guide our work. Each answers a specific question that the scoping stage must address.
The MoSCoW matrix sorts the features of a project into four categories — Must, Should, Could, Won't — by criticality: what absolutely must be delivered, what should be, what could be if the context allows, and what is explicitly left out of scope. It is the tool that prevents specification drift: anything that isn't ranked tends to become a priority as the project advances.
The RACI matrix clarifies, for every decision and every deliverable, who is Responsible, who is Accountable, who is Consulted, who is Informed. Without this groundwork, responsibilities blur and trade-offs get taken by default. RACI doesn't create governance where none exists — it makes visible the governance already in place and exposes the areas where it is incomplete.
The Cynefin framework classifies problems by their nature — simple, complicated, complex or chaotic — and points to the method that fits each. It is a safeguard against false certainties: applying a simple-problem method to a complex subject produces plans that don't hold up.
The three frameworks complement one another. MoSCoW arbitrates value, RACI clarifies responsibilities, Cynefin sets the method. None replaces expertise — they equip it.
From scoping to deployment: the sequence
Once scoping is settled, the project moves into its build phase. We work in short cycles, each delivering a usable functional scope. This rhythm prevents the tunnel effect — those months when the project advances with no visibility on what it will become — and lets your team adjust what isn't working as planned, rather than discovering at final delivery a product that hasn't found its audience.
Deployment is prepared from the scoping stage, not at the end of the journey. The choices of architecture, data structure and rollout method are settled early, because they determine everything that follows. When release day comes, we have known for some time how the application will be deployed, how it will be monitored, and how the first changes will be handled.
The project does not end at release. A business application lives, changes, and adapts to the evolution of the business it serves. Our engagement covers that longer arc — not as a generic maintenance service, but as the natural continuation of the work begun at the scoping stage.
AI: an accelerator under expert control
The arrival of generative models has changed part of our work, without changing its nature. A growing share of the code we produce is AI-assisted — a real acceleration on formatting, test generation, and the review of well-defined routines. This assistance does not replace the scoping stage, does not settle structural trade-offs, and does not arbitrate between two architectures. It accelerates what has already been clarified.
On the subjects where agentic AI comes into play — when a model is given autonomous execution of a chain of operations — we work along the principle we developed in our series on Claude Code: the advisor pattern, an arrangement in which a lightweight executor consults a powerful model on an ad hoc basis for structural decisions, rather than mobilising the heaviest capability across the board. This principle lets us keep control over costs, over the predictability of behaviour, and over the scope of autonomy granted to the agent.
Our position is consistent. AI is an accelerator whose value depends on the framework in which it is deployed. Without rigorous scoping upfront, AI is quick to produce — and quick to produce the wrong thing.
Where this leads
A methodology only takes shape on real projects, with their own constraints. The things we build — portals, platforms, internal tools — are detailed on the Custom business applications page. The technical choices that carry them over time are the subject of the Technology page. And to see this approach at work in finished projects, our selected work offers a tangible sample.