Suited to
- Companies launching a new internal or external product
- Founders with deep enterprise domain knowledge but no delivery team
- Business units standing up a new platform
- Early-stage products that need production-grade foundations
Home/Engagements
Engagement models for serious enterprise work.
Work is structured to suit the problem and the way your organization procures. Below are the five shapes an engagement usually takes, what each is suited to, and how it is governed.
When to involve us
The situations this practice is built for.
Most engagements begin from one of a small number of recognizable situations. If one of these describes where you are, the first conversation is likely to be worth having.
- An internal system the business depends on has become difficult to change or expensive to support, and the risk of touching it has become a constraint in its own right.
- A process spans several enterprise platforms held together by manual handoffs, and no single system owns the result end to end.
- A migration has to preserve history, metadata, permissions or an audit trail, rather than merely move data from one store to another.
- A modernization has to proceed in stages while the business keeps running, with the old and new systems coexisting instead of meeting at a single cutover.
- An AI use case has to operate inside real security, privacy or on-premises constraints, where the data cannot leave your network.
- The team that will own the system afterwards has to be able to run and extend it without the people who built it.
Where the work is outside what this practice does well, we say so at the first conversation and, where we can, point you toward a team who does it well. What we do not take on.
Before any model
Every engagement starts the same way.
The first conversation is about the problem rather than the technology: what is failing, what it is costing, which constraints are genuinely fixed, and what the system would have to guarantee before the business trusted it again. It costs nothing and it commits you to nothing.
What follows from it is either a scoped proposal with a fixed price, or a straight answer that this is not work we should be doing. Both are useful outcomes, and we would rather give the second at the first meeting than discover it at the third invoice.
Duration follows the problem rather than a template. Some engagements are a few focused weeks. Others run for months, because the system is genuinely large and pretending otherwise would help nobody. We would rather lose a bid than agree to a timeline we do not believe.
Model 01
Fixed-scope project delivery
The default shape of an engagement. A defined system, scoped in discovery, quoted as a fixed proposal, and delivered against a plan that both sides agreed before implementation started.
Fixed scope is only honest when discovery has been done properly, which is why we treat it as a phase with its own output rather than a sales conversation. Where the shape of the problem is genuinely unclear at the outset, we will say so and propose a short paid discovery instead of pricing a guess, because a fixed price on an unexamined problem is a fiction that one of us will pay for later.
Suited to
- Defined application builds
- Workflow and case-management systems
- Integrations between systems of record
- Migration utilities and one-off engines
- Internal platforms and operator tooling
- Discrete modernization modules
How it runs
01
Discovery
02
Scope definition
03
Fixed proposal
04
Delivery plan
05
Implementation
06
Handover
Model 02
Product launch build
We help turn a validated business requirement into a working product foundation, with an architecture that can evolve beyond the first release.
The failure mode of a first release is not that it is too small. It is that it is built in a way that makes the second release disproportionately expensive: no separation between the domain and the interface, no migration path for data written by version one, authentication bolted on at the end, and no way to run the thing in two environments. None of that is visible at launch. All of it arrives in month four.
So a launch build is scoped as a foundation as well as a feature set. That does not mean gold-plating, and it does not mean building for imagined scale. It means being deliberate about which decisions are cheap to defer and which are expensive to reverse, and spending the budget on the second category.
What we hold to
- An architecture that survives the second release
- A data model that can be migrated, not just written
- Environments, deployment and rollback from the start
- Code the client's future team can take over
Model 03
Modernization program
A staged programme to replace an aging system, structured so that the business keeps running throughout and so that the work can be stopped at any point without leaving the organization worse off than when it started.
That last property is the one that matters. Modernization programmes are cancelled far more often than they fail technically, usually because the benefit is deferred until a big-bang cutover that never quite arrives. A programme designed to deliver value incrementally survives a change of sponsor, a budget freeze, and a reprioritization, because each stage has already paid for itself.
Suited to
- Aging internal systems still carrying the business
- Legacy forms and workflow estates
- Manual processes that have become key-person risks
- Platforms approaching end of support or a licence cliff
What the programme includes
- Assessment of the estate and its real dependencies
- A migration approach, with what cannot be translated made explicit
- Incremental delivery with value at each stage
- Coexistence planning and controlled, reversible cutover
Model 04
Technical advisory & architecture review
A short, senior engagement to answer a question the organization needs settled before it commits budget: whether to build or buy, which platform will hold, what a modernization roadmap should actually sequence, or whether an AI use case is viable at all.
These engagements are deliberately independent of the delivery that might follow. We will tell you to buy the product rather than build it, or that the integration you are planning is a symptom of a data model problem that will not be fixed by more integration, or that the AI pilot you have been asked to run cannot work because the data it needs is not permitted to leave your network. Those answers are worth more than a project, and they are cheaper.
Typical questions
- Build versus buy, with the total cost of each stated honestly
- Platform and technology selection
- Modernization roadmap and sequencing
- AI feasibility, and what would have to be true for it to work
- Integration strategy across a fragmented estate
- Review of a system design before it is committed to
What you receive
- A written assessment, with the reasoning shown
- Options, each with its cost and its failure mode
- A recommendation, and the conditions under which it would change
- No obligation to engage us for the delivery
Model 05
Support & evolution
A retained arrangement for organizations that want the team who built the system to stay reachable: enhancements, monitoring review, process improvements, integration maintenance, and advisory access as the business changes around the system.
This is offered and it is never required. Every system we deliver is designed so that your own team can run, change and extend it without us, and the handover is complete whether or not a support arrangement follows. A retainer that exists because the client cannot operate what we built would be evidence that we built it badly.
Stated plainly
No system we deliver depends on a retainer. If we disappeared the week after handover, your
team would still be able to run and change what we built. That is the design goal, and it is
testable at handover.
Procurement
We work the way enterprises actually buy.
We can work with NDAs, defined statements of work, milestone-based delivery, documentation requirements, and enterprise review processes.
None of that is treated as friction. Security review, change control, audit requirements and architecture governance are the environment an enterprise system lives in, and a supplier who finds them inconvenient is telling you something about how they build.
- Commercial
- Fixed price against a defined scope. Milestone-based invoicing where required. Time-and-materials only by explicit agreement, and never as a default.
- Contractual
- NDAs, statements of work, and your standard supplier terms. We read them.
- Data & access
- We work inside your accounts and infrastructure rather than copying data out of them. Access is scoped to the engagement and revoked when it ends. Where data cannot leave your network at all, that constraint is designed for from the first day.
- Intellectual property
- Yours, in full. Code, documentation, infrastructure, and the accounts everything runs in.
- Governance
- Architecture review, security review, UAT and change control are planned into the delivery rather than encountered by it.
Tell us what needs building, and how you need to buy it.
The first conversation is a scoping discussion. It costs nothing, and it ends with either a proposal or a straight answer.