Services
Start with evidence. Build with a plan.
Our engagements have two tiers. First, we determine what is worth doing and set out the work in practical terms. If the recommendation supports further investment, we can then deliver it with your team or as the delivery team.
Tier 1
Assessment
A short, fixed-scope engagement that replaces assumptions with a written recommendation and a costed, sequenced plan.
We begin by agreeing on the decision the assessment needs to support. That might be whether a generative-AI use case can be made reliable, how to consolidate overlapping services, or where delivery friction is putting a critical programme at risk. We define the scope, the people we need to speak with, the systems and data we need to examine, and the fixed price before starting.
What happens
We examine the current system, the available data, and the way the team designs, ships, and operates software. Depending on the question, that can include architecture and code review, data suitability, operational constraints, test coverage, delivery practices, and the dependencies that shape a realistic sequence of work.
The purpose is to test the premise, not defend it. We identify where the proposed work creates value, where risk has been understated, and which constraints cannot be designed away. If a smaller or less expensive intervention answers the need, we recommend that instead.
What you receive
The assessment ends with a written recommendation. It explains what we found, what we believe should happen next, and why. Where work is justified, it includes a costed plan arranged in a practical sequence, with dependencies, decision points, and the conditions needed for delivery.
The document belongs to you. You can use it with your own engineers, another delivery partner, or us. There is no requirement to continue into a build engagement.
How this tier ends: with a decision you can act on. If the proposed work is not worth doing, the assessment says so and explains the evidence behind that conclusion.
Tier 2
Build
Delivery against an agreed plan, either as the delivery team or embedded alongside your engineers.
A build engagement starts only when the assessment supports it. The recommendation gives us a shared view of scope, sequence, cost, and risk before delivery begins. If priorities or constraints have changed since the assessment, we make those changes explicit rather than allowing the plan to drift quietly.
What happens
We organise delivery around working increments and clear technical decisions. We can take responsibility for the build or join an existing team where additional senior engineering is needed. In either model, we work with the people who will operate and maintain the result, not around them.
For applied-AI systems, delivery includes the evaluation, observability, guardrails, and cost controls needed to judge behaviour in production. For platform and migration work, it includes rollout, compatibility, and recovery planning suited to systems where interruption has a direct customer impact. Across all work, test strategy and maintainability are delivery concerns, not tasks left for the end.
What you receive
You receive working software, the tests and operational material needed to support it, and a record of the decisions that shaped it. We keep the plan current as delivery reveals new information, so scope and trade-offs remain visible.
Handover begins during the build. We pair with your engineers, explain design choices, and transfer operational knowledge while the system is taking shape. This avoids a final handover meeting becoming the first time the permanent team sees how the software works.
How this tier ends: with a supported release, clear ownership, and a team able to maintain and extend what has been built.
Engagement boundaries
A clear start and a deliberate finish
-
Start with the decision
We agree on the question, scope, access, timing, price, and the person responsible for decisions before work begins.
-
Keep trade-offs visible
Findings and delivery choices are explained as they emerge. A change in evidence can change the recommendation or the plan.
-
End with ownership transferred
Each tier produces a usable outcome of its own. The assessment ends with your document; the build ends with your team able to operate and change the software.
Start with a conversation
Tell us what you are trying to build or fix. If we are not the right people for it, we will say so.