Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-11 · Instrument version 1.0.0
What Matters
The cost of a custom agent service continues after the first working demonstration. Price the build, maintained variants, support, acceptance, remedies and exit obligations over the actual commitment period. DN’s model separates reusable investment from customer-specific work and shows a stated remedy stress. It does not turn a cost reserve into a guarantee or predict future failures.
A customer asks for a small change: another data source, a special approval rule or a guaranteed turnaround. The code may be quick to write. The commercial obligation can last for months, including every later platform change and every operator who needs support.
This article combines customization economics with outcome-guarantee feasibility. Both ask what the seller has actually promised to maintain and remedy. It extends DN’s supervision and insurance coverage into the lifetime economics of one scoped customer contract, without claiming that a provider warranty or insurance policy covers the promise.
DN Evidence Block
Sources reviewed: 2026-11-11 · Evidence type: Primary documentation review and original DN method; examples are explicitly synthetic.
Scope: A defined customer implementation over a stated number of months, with base costs and a separate remedy-cost stress.
- Anthropic’s commercial terms distinguish defined services and third-party features, illustrating why upstream scope must be read rather than assumed: Anthropic commercial terms.
- GOV.UK prototype guidance separates design testing from production readiness: GOV.UK Service Manual: Making prototypes.
- All prices and costs below are synthetic. DN’s tool calculates the entered commitment, not its legal enforceability.
Not established by this work: No customer contract, actual delivery margin, claim probability or insurance coverage was evaluated.
Original DN instrument · version 1.0.0
DN Customisation Break-Even Model
Calculate one contract’s base contribution and a separately entered remedy-cost stress. One currency; include relevant costs once.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
No tax, financing, revenue recognition or legal opinion. Cash collection and cancellation require separate timing scenarios. Unentered shared overhead remains outside contribution.
1. Define and fund the customer-specific build scope
The first commitment is the build scope. Identify which work belongs to a reusable product and which exists only because of this customer. Reusable does not mean free: the business still needs a deliberate allocation or investment decision. Customer-specific does not mean bad: a buyer may be willing to fund it. The problem arises when the quote hides one inside the other.
Record the supported inputs, outputs, integrations, roles and acceptance conditions. A customer-specific approval rule can create a permanent branch in testing and support, even if the initial change is small. Cost the branch over its promised life rather than judging it by the number of lines changed.
Use an explicit allocation for shared work. If a 1,200 CU capability is being funded across four committed implementations, the illustrative allocation is 300 CU each. If the other three customers are only hoped for, calling the first customer’s share 300 CU transfers the remaining 900 CU into an unfunded assumption. Preserve that difference in the investment decision.
A reusable component needs an owner and a supported version boundary. If each customer keeps a different variant, the work may be reusable in concept while remaining separate in operation. Count the distinct versions that must be tested after a shared change. A common codebase can still carry several different commercial promises, and a single test result does not establish that every promised configuration remains supported.
2. Price maintained compatibility
The second commitment is maintained compatibility. List the variants that must continue working after changes to the model, connector, data format or customer process. Decide which changes are included, which require a new quote and which end the supported scope. The agreement must make that boundary intelligible to the customer.
A prototype that passes a demonstration is not automatically ready for production operation. The GOV.UK prototype guidance makes that distinction in service design. DN applies it here by separating demonstration effort from release checks, recovery procedures, monitoring and maintained operator instructions.
3. Price the human support and exception path
Estimate routine delivery and maintenance separately. Include the time needed to diagnose ambiguous customer reports, reproduce failures and explain the result. An apparently cheap service can move the difficult work into unpriced calls with the founder. Where effort is uncertain, present a bounded allowance and a stress scenario instead of disguising a guess as a stable per-customer cost.
For each included exception, specify the response the buyer receives. Is the commitment to investigate, correct within a window, retry under approved conditions or deliver an accepted result? Those promises consume different resources. They should have different cost assumptions and escalation rules.
4. Define acceptance and dependencies
The fourth commitment is acceptance. Describe the output the buyer can inspect and the conditions under which it counts as complete. If the outcome also depends on customer data, human approval or another supplier, record that dependency and the consequence when it is unavailable. The seller should not quietly promise control it does not possess.
Read the upstream service boundary alongside the downstream promise. Anthropic’s commercial terms distinguish its defined services from third-party features. DN’s inference is that a reseller must map each dependency to the actual applicable agreement; the upstream provider’s scope should not be assumed to mirror what the reseller tells its customer.
5. State the remedy and stress its cost
A remedy budget is a scenario allowance. It does not cap contractual liability, make a guarantee enforceable, transfer risk or prove that failures are insurable. The contract and relevant advice govern those questions. Keep the calculation focused on a specified commercial scenario, such as a 500 CU replacement-work obligation, with the basis for that amount recorded.
Avoid vague unlimited outcomes in a fixed-fee quote. If the buyer requires a stronger commitment, identify the additional controls, evidence and funding needed to support it. The appropriate response may be a narrower paid pilot or a different scope. A reassuring promise does not make an uncontrolled dependency predictable.
6. Price exit and reassess the promise at renewal
The sixth commitment is exit. Define required export, documentation, account removal, handover assistance and any retained obligations. Estimate the work and include it in the price or a clearly described separate charge where appropriate. A customer should understand the exit path before becoming dependent on the implementation.
At renewal, compare the actual maintained scope with the original quote. Count support cases, release work, exceptions and customer-requested changes. Do not assume the next period is cheaper merely because the initial build is complete. Conversely, a mature reusable component may genuinely reduce work; record that evidence before sharing the saving.
A useful customization decision has three outputs: the priced standard scope, the separately funded special obligations and a clear stopping boundary. It should remain understandable to the next operator, without reconstructing the sales conversation. The commercial objective is a service the buyer can rely on and the seller can afford to maintain through the promised term.
Compare two proposals with the same headline monthly fee. One includes one approved workflow and a defined review window; the other includes every future customer process change. The cost model should not treat them as the same service. For the broader promise, identify a funding mechanism or narrow the commitment before quoting. This is ordinary scope discipline applied to an agent service whose low initial build cost can otherwise make long-lived obligations seem deceptively cheap.
Methodology, limitations and corrections
Inventory the obligations before estimating effort. Assign each cost to customer-specific build, deliberate shared investment, recurring delivery, maintenance, exit or a separately labelled stress. Preserve the quoted scope and the customer’s acceptance evidence.
The worked example is synthetic. Review actual effort after each delivery cycle, including unsuccessful attempts and support. Recalculate when the scope, term or supplier dependency changes. A tool allowance does not amend a contract; any change to a commercial promise must follow the actual agreement and applicable process.
Worked example: full-term customization economics
In a synthetic six-month implementation, the customer pays 1,000 CU upfront and 500 CU per month, producing 4,000 CU of contracted revenue in the model. Customer-specific build work costs 1,500 CU and shared work allocation costs 300 CU. Monthly delivery costs 200 CU and maintenance costs 100 CU, adding 1,800 CU across six months.
The base cost is therefore 3,600 CU, leaving 400 CU contribution before any costs excluded from the model. A separate 500 CU remedy stress turns that into minus 100 CU. The model does not claim a 500 CU expected loss or assign a probability. It shows the consequence if that entered obligation is incurred.
After the 1,000 CU setup fee, the recurring fee needed to cover the base costs is approximately 433.33 CU per month over six months. That is a break-even calculation for this scope, not a recommended selling price. If the customer can cancel earlier while the seller’s build and supplier commitments remain, rerun the shorter collected period and the remaining unavoidable costs.
Now change only maintenance from 100 to 180 CU per month. Base costs rise by 480 CU and the original 400 CU contribution becomes minus 80 CU. The initial build has not changed at all. This sensitivity explains why a service priced from implementation effort alone can lose money even when the promised feature works.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version1.0.0, 2026-11-11. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Is reusable development free for the first customer?
No. Decide how it is funded. Future customers that have not committed should not silently subsidize the quote.
Does the remedy reserve cap liability?
No. It is a calculation input. Contractual obligations and enforceability are separate questions.
Should every customization be rejected?
No. Price the full obligation and confirm that the buyer values it enough to fund the maintained service.
Why model exit at the start?
Export, handover and access removal can require real work. Including the boundary early makes the commercial commitment clearer.
Primary sources
- GOV.UK Service Manual: Making prototypes. Prototypes test ideas and are not production-ready implementations by default. Reviewed 2026-11-11.
- Anthropic commercial terms. Commercial terms A.1/A.2 define Services and distinguish Third Party Features, which Anthropic states are not its Services. The downstream dependency-mapping recommendation is DN’s inference, not a ruling on a customer contract. Reviewed 2026-11-11.
Turn the finding into a decision
The DN Research Desk can scope a customization cost and obligation map, subject to source access and a written quote. Start with one unresolved decision and the records available to answer it. This article does not promise a completed audit, integration or independently verified result.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
