An AI engagement sold as "build an agent in four weeks" puts pressure on the team to write code before anyone understands the problem, the exceptions, the data or the controls. A loose time-and-materials engagement can drift for months without proving anything. A pure outcome-based contract can promise results the delivery team does not control.
None of these is dishonest in itself. Each one shapes delivery behaviour, and usually not in the direction the client wants. The commercial model is part of the delivery design.
Forward deployed work needs commercial stages that line up with evidence: pay for the next piece of certainty, then decide.
Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative. Sandveld had already been sold one AI fantasy. A year before Ironbark arrived, a vendor demonstrated an "AI invoice" product on clean sample invoices, sold a licence on the strength of it, and left. Six months later the AP clerks were still re-keying invoices from phone photos. When Ironbark proposed working differently, the CFO's first question was reasonable: how is this not the same thing again?
The engagement ladder
Qualification. Confirm the sponsor, the business pain, data access, a workflow owner, urgency, constraints and the organisation's ability to act on what it finds. Do not run a large discovery for an opportunity with no path to a decision.
Opportunity sprint. Map the workflow, its exceptions, systems and baseline. Prioritise use cases, define the target process, identify controls and produce an implementation option based on evidence.
Prototype and evaluation. Build a bounded slice on representative data. Create the first evaluation set, a cost model and the production architecture.
Controlled deployment. Integrate with real systems, complete security and operational readiness, train users, and release through shadow and canary stages.
Operate and improve. Monitor outcomes, evaluate drift, manage incidents, improve the workflow, and turn repeatable work into reusable assets.
Ironbark's answer to the CFO was the second rung. It sold Sandveld a three-week opportunity sprint for a fixed fee, credited against implementation if Sandveld went ahead. The sprint produced the operating map, the six-week variant sample and the responsibility model described in Parts 2 and 3. Only then was a prototype priced.
What the client keeps from discovery
The test of a good discovery is whether the client is better off even if implementation never happens. It should leave behind:
- a verified operating map of the current state;
- prioritised use cases, with the reasoning;
- baseline volumes, time, quality and risk;
- options for the future workflow;
- an architecture and integration view;
- data, security and governance requirements;
- an evaluation and value measurement plan;
- a delivery roadmap, estimate, assumptions and risks.
This is why a discovery can be a paid deliverable. It reduces uncertainty and prevents a more expensive wrong build. Sandveld's CFO said afterwards that the sprint would have been worth its fee if it had ended in "do not proceed", because it was the first time anyone had measured how the invoice work actually ran.
Free discovery and paid discovery
In the podcast that gives this series its spine, Vasuman Moza recommends free audits as a way for early-career forward deployed engineers to get in the door and learn. That can work. It is not a universal commercial rule.
Free work is appropriate when it is tightly bounded business development, a deliberate learning investment, or a partnership decision. It becomes harmful when it trains buyers to expect specialist work for nothing, or forces the provider to recover the cost by inflating implementation fees, which then distorts the build decision.
| Approach | Appropriate when | Guardrail |
|---|---|---|
| Free qualification | Establishing fit and the next decision | Time-boxed; no detailed solution design |
| Low-cost diagnostic | A small buyer or an early relationship | Fixed scope and a reusable method |
| Paid opportunity sprint | A material workflow and enterprise complexity | Clear deliverables and client access obligations |
| Credited discovery | The client wants commercial continuity | Credit applies only if agreed implementation proceeds |
| Provider-funded pilot | Strategic product learning | Agreed terms for intellectual property, data, support and exit |
Whatever the price, two lines should never be crossed under an informal arrangement: handling production data, and creating a business dependency. A free audit that ends with a client relying on a script nobody supports is not generosity. Under POPIA, a provider handling a client's personal information is an operator, and that needs a written agreement whether money changes hands or not.
Price the uncertainty honestly
Different stages carry different uncertainty, so they need different commercial models:
- fixed price for a bounded discovery;
- time and materials for uncertain integration work;
- milestone pricing tied to deliverables and acceptance evidence;
- a managed service for ongoing operation and improvement;
- a limited outcome component, only where causality and measurement are agreed in advance.
Avoid promising a specific revenue uplift or saving before the baseline and adoption assumptions have been validated. Sandveld's integration work was time and materials, because nobody knew how long the masked test environment and the import-file behaviour would take to tame. The deployment milestones were fixed, because by then the evidence existed. For the bid side of this, estimate and price the same solution covers keeping the commercial model consistent with the architecture.
The value case
Moza groups value into revenue uplift, risk mitigation and cost saving. These are useful executive categories. Service quality and capacity belong alongside them where they can be measured.
| Value dimension | Example evidence |
|---|---|
| Revenue | Conversion, retention, sales capacity or time to market |
| Cost | Labour released, rework reduced or infrastructure optimised |
| Risk | Loss avoided, control coverage, fewer errors or faster detection |
| Service | Resolution time, response quality or accessibility |
| Capacity | More cases handled without equivalent headcount growth |
The most common error in AI value cases is counting released time as cash. If clerks save two hours a week and the organisation does nothing different with those hours, the benefit is potential, not realised.
A simple value model
Annual gross benefit
= realised labour or supplier saving
+ attributable margin from additional revenue
+ expected loss avoided
+ quantified service benefit where agreed
Annual net value
= annual gross benefit
- build amortisation
- model, tool and platform cost
- support and improvement cost
- human review and exception cost
- change and training cost
Record ranges and assumptions. Do not hide uncertainty inside a single ROI percentage.
Sandveld's value case, as agreed at the end of the sprint, separated the two kinds of benefit explicitly:
- Realised: early-payment discounts that suppliers offer but Sandveld had been missing because exceptions sat in the queue too long, and duplicate payments avoided, valued as an expected loss from the duplicates found in the six-week sample.
- Potential, not cash: clerk capacity released, estimated at about two full-time equivalents. Sandveld decided to use it to absorb volume growth without hiring rather than to reduce headcount, so it appears in the case as capacity, not savings.
- Costs: build amortisation, model and platform, review time, support, and training.
Each figure was a range with its assumption written next to it. The net value was positive at the low end of the range, which is what made the CFO comfortable approving the prototype.
Questions every AI proposal should answer
- Who owns the workflow and the budget?
- What is the baseline, and how reliable is it?
- What client access, data and specialist time are required?
- Which outcomes can the provider actually control?
- What is excluded?
- Who owns the resulting code, configuration, prompts and evaluation data?
- What becomes reusable platform intellectual property?
- Who supports the service, and under which service level?
- What happens when a model, tool or client system changes?
- What is the stop decision if the evidence does not support implementation?
Questions 6 and 7 deserve particular attention in forward deployed work, because the model depends on field learning flowing back into a reusable platform. At Sandveld the contract was explicit: Sandveld owns its configuration, prompts and evaluation data; Ironbark owns the platform, including the configurable weight tolerance setting that grew out of Sandveld's discovery. Both sides knew that before the sprint started. Proposal teams will recognise this as the same discipline as deciding whether to bid at all: settle the uncomfortable questions before the writing starts.
The short version
The commercial model shapes delivery. Sell stages that line up with evidence.
Discovery must leave value behind. Even a "do not proceed" should be worth paying for.
Free work needs boundaries. Never production data, never an informal dependency.
Price uncertainty honestly. Fixed where bounded, time and materials where it is not.
Separate realised from potential value. Released time is not cash until something changes.
The strongest proposal sells a controlled path to evidence, not certainty that has not yet been earned.
Previous: Part 5, build into the business you actually have. Next: Part 7, one hero is not a delivery model. All parts are on the series page.
How CloudNala can help
We help organisations buy and sell AI work on evidence: scoping opportunity sprints with deliverables a client keeps whatever happens next, structuring commercial models that match the uncertainty of each stage, building value cases that separate realised from potential benefit, and answering the ownership and support questions before a contract is signed. We do the same for providers writing AI proposals, so the bid promises what the delivery team can prove.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za