Technology services have traditionally been sold through people: a number of engineers, a rate card, and a monthly calculation of hours consumed. That model is easy to administer, but it can disconnect commercial incentives from the reason a client engaged a technology partner in the first place: to get something delivered.
Branemind uses a delivery-based billing model. We define the intended deliverable, establish measurable acceptance criteria, agree commercial milestones, and bill against accepted delivery. The unit of commercial conversation therefore shifts from 'How many people did we deploy?' to 'What capability or outcome did we deliver?'
This does not mean every business outcome can be guaranteed by a technology provider. Revenue, adoption, regulatory approval and operational performance can depend on factors outside a delivery partner's control. A credible delivery-based model distinguishes between what the partner can commit to, what can be jointly measured, and what remains a client-side dependency.
The commercial misalignment in headcount billing
In a headcount model, the primary billable unit is capacity. More people or more time generally creates more billable value for the supplier, even when the client's objective is to reduce cycle time, automate work, simplify architecture, or require fewer interventions.
That is a structural tension: efficiency benefits the client, but may reduce the supplier's billable base. Delivery-based billing attempts to align both sides around completion, quality and usefulness instead.
People, hours, timesheets.
Headcount bills hereCode, pipelines, tickets closed.
A bounded capability that passes acceptance.
Delivery bills hereThe business change that follows.
Headcount vs delivery: a different unit of value
What Branemind means by 'delivery'
A delivery is not a vague promise such as 'improve AI' or 'modernise data'. It is a bounded, testable capability with a clear definition of done. Depending on the engagement it can be a production workflow, an integration, an agentic process, a migrated data product, a reconciliation capability, a measurable automation milestone, or another agreed unit of business functionality.
The strongest deliverables combine four elements:
- A business objective: what this is for, in the client's language.
- A technical artifact or capability: the thing that actually gets built.
- Acceptance criteria: observable and testable, agreed before implementation begins.
- Evidence that the criteria were met: the artefact that triggers the milestone.
The outcome contracting framework
- 1Define the outcome
- 2Establish a baseline
- 3Agree acceptance criteria
- 4Build and validate
- 5Accept the delivery
- 6Measure impact
Step 6 feeds step 1 of the next phase. Impact informs what gets scoped next, without pretending every external variable is the delivery partner’s to control.
Define the outcome
Translate the business problem into a bounded result. Avoid using team size as the definition of scope.
Establish a baseline
Where measurement matters, capture the current state: cycle time, manual touches, accuracy, failure rate, throughput, cost per transaction, or another relevant metric.
Agree acceptance criteria
Define what evidence constitutes completion. Criteria should be observable, testable and understood before implementation begins.
Build and validate
Branemind chooses the engineering approach, automation level and internal resourcing needed to reach the agreed delivery.
Accept the delivery
Client and Branemind review the evidence against the agreed criteria. Commercial milestones are connected to this acceptance.
Measure impact
Where appropriate, track operational or business KPIs after release. Impact metrics inform subsequent phases without pretending every external variable is under the delivery partner's control.
How tangible outcomes can be quantified
Delivery-based billing works only when 'done' can be made concrete. The measurement method should match the nature of the work.
| Work type | Example deliverable | Possible acceptance evidence | Possible impact metric |
|---|---|---|---|
| AI agent | Production-ready workflow | Tool-call tests, guardrails, eval threshold, deployment | Automation rate / handling time |
| Data engineering | Reliable data pipeline | Freshness SLA, reconciliation checks, observability | Latency / incident reduction |
| Integration | System-to-system workflow | Successful test cases, idempotency, error handling | Manual steps removed |
| Process automation | Automated operational process | Defined scenarios complete without manual execution | Cycle-time reduction |
| Analytics | Decision-ready data product | Metric definitions, validated outputs, access controls | Time-to-insight / adoption |
A simple commercial example
Consider a reconciliation process that currently requires repeated manual matching across invoices, ledgers and bank transactions. A headcount contract may sell two engineers for a period of time. A delivery contract instead defines the capability: ingest agreed sources, match transactions according to approved rules, surface exceptions, preserve an audit trail, and meet agreed validation thresholds.
If Branemind can reach the agreed result through better tooling, reusable components, automation or a smaller expert team, that efficiency is not penalised. It becomes part of the value proposition.
Why this matters more in the AI era
AI-assisted engineering changes the relationship between effort and output. Code generation, reusable agent patterns, automated testing, infrastructure automation and increasingly capable models can compress work that previously required larger teams. If commercial models remain tied only to hours, clients may pay for an old proxy even as the underlying productivity curve changes.
Illustrative shapes, not measured data. The point is the direction, not the gradient.
Delivery-based billing makes the commercial model more compatible with AI-enabled productivity. The provider is rewarded for engineering leverage, while the client retains focus on the capability received.
What this changes for the client
- Budget conversations become connected to defined milestones rather than open-ended utilisation.
- Procurement can compare proposals on scope, acceptance and value, not only rate cards.
- Engineering partners have an incentive to automate their own delivery process.
- Smaller expert teams can compete on capability instead of staffing volume.
- Governance becomes clearer, because change requests can be separated from the agreed definition of done.
What it requires from the delivery partner
This model is not simply fixed-price billing with a new label. It requires stronger discovery, sharper scoping, reusable engineering assets, evaluation discipline, observability, documentation, risk management and transparent change control. A supplier that cannot define and measure delivery will struggle to price delivery responsibly.
Where delivery-based billing needs guardrails
Not every engagement is equally suited to a pure outcome model. Early-stage research, ambiguous discovery, rapidly changing requirements, third-party dependencies and client-controlled adoption can make a final business outcome impossible to price responsibly. Branemind's approach is to make accountability explicit rather than over-promise, by separating three layers.
A tested integration deployed to the agreed environment
Reduction in manual handling after client rollout
Revenue growth, regulatory approval, end-user adoption
Accountability is strongest at the top and deliberately weaker further out. Naming which layer a metric belongs to is what keeps the model honest.
Delivery-based does not mean unlimited scope either. If the target outcome, source systems, acceptance criteria, compliance requirements or dependencies change materially, the commercial scope should change transparently as well. This protects both the client and the delivery partner.
Branemind's position
Branemind believes the technology services industry should progressively move from selling capacity to selling accountable delivery. Headcount will remain relevant for some forms of staff augmentation and open-ended programmes. But when a client hires a specialist partner to solve a defined problem, the commercial model should reflect the problem solved.
“We do not want clients asking how many hours Branemind spent. We want them asking what Branemind delivered, and what changed because of it.”
A call to buyers and builders
- For buyers: ask technology partners to make the definition of done visible.
- For builders: invest in the engineering systems that let you accept delivery accountability.
- For procurement teams: evaluate commercial models not only by day rate, but by the clarity of the outcome, the quality of the acceptance criteria, and the risk each party is prepared to own.