How to buy (or sell) development work without betting the budget: paid discovery, credited on continuation, deliverables that survive alone
For anyone commissioning custom software, AI systems, or digital products - and for the builders who sell them. One commercial structure, explained from both chairs, because it only works when both sides understand why it's fair.
Every custom development project starts with the same uncomfortable gap. The buyer is being asked to commit real money to a builder they haven't worked with, for a system that doesn't exist, based on a proposal that is - however polished - a prediction. The builder is being asked to price something whose hardest unknowns can only be discovered by doing the early work. Both sides paper over the gap with confidence, and the gap gets paid for later: in change requests, in disappointment, in the project that should never have been built at all.
The standard workarounds are all bad. The free pilot makes the builder subsidize the buyer's uncertainty, which means only builders desperate enough to work free will do it - and you get what desperation builds. The big fixed quote makes the buyer prepay for unknowns, padded accordingly. The hourly open-ended start removes the padding and replaces it with a meter nobody can predict. And the bake-off of free test projects - increasingly common with AI work - gets you three rushed freebies from three candidates, none of whom could afford to do it properly.
There is a better structure, and it is simple enough to state in three sentences:
The first engagement is a small, paid piece of work that answers the project's most expensive question. If the project continues, the fee is credited against the full build. Either way, the buyer keeps deliverables that stand on their own.
That's the validation slice. The rest of this document is why each clause matters, how to scope one, how to price one, and the failure modes on both sides. (For the smaller end - buying a single-task tool rather than a full build - the companion guide is How to Buy a Custom AI Tool Without Getting Burned.)
Part 1: Why "paid" - the clause buyers resist and shouldn't
Buyers often ask: why should I pay to find out whether I should pay you? Three honest answers.
Paid work is real work. A free test gets the hours left over after paying clients; a paid slice gets the same attention as any engagement - which means what you're evaluating is the builder's actual work, not their charity tier. If you're comparing candidates, this matters double: free bake-off submissions tell you who had a free weekend, not who does the best work.
Payment filters both directions. A buyer who won't fund a small validation was never going to fund the build - better discovered at slice-size than at proposal-signing. And a builder who won't scope a small paid start (who insists the whole thing must be committed at once) is telling you something about how flexible the next twelve months will be.
Free work creates debt, not data. After a substantial free pilot, both sides feel the obligation: the builder expects the contract, the buyer feels guilty comparing alternatives. The relationship starts with a lien on it. A paid slice ends clean: work delivered, invoice settled, decision free.
Part 2: Why "credited" - the clause that makes it generous
The credit is what transforms the slice from "an extra cost" into "the de-risked front of the same budget". If the slice is €2,500 and the build is €25,000, a continuing buyer pays €25,000 total - the slice was effectively free. Only the buyer who stops pays for the slice alone, and stopping is precisely the scenario where paying a small amount to avoid a large mistake is the best money in the whole story.
Two guardrails keep the credit honest:
Price the slice at its real standalone value. The credit is not a discount and must not be priced like one. If the slice would cost €2,500 as standalone consulting, it costs €2,500 - because it might be standalone (the project dies at validation, which is a legitimate outcome, not a failure). A builder who discounts the slice "because they'll probably continue" is spending the same margin twice; a buyer offered a suspiciously cheap slice should ask what corners fund it.
Time-box the credit. Credited if the build starts within a defined window - 60 or 90 days is normal. An open-ended credit is a stale quote waiting to be honored at old prices for a project whose context has moved.
Part 3: Why "deliverables that survive alone" - the clause that proves good faith
This is the least obvious clause and the one that does the most trust-building: whatever the slice produces must be valuable without the builder. A findings document. A scored analysis. A tested prototype with its code and an honest readme. A recommendation with the reasoning shown. Written so that a different builder - or the buyer's own team - could pick it up.
For the buyer, this is the insurance: worst case, you paid a fair price for a useful artifact and can continue with anyone. For the builder, it's the strongest sales argument that exists, because it's structural rather than verbal: I am safe to hire for a first step, because nothing about this step locks you to me. Builders who resist this clause are revealing that their retention strategy is dependency. The ones who embrace it retain clients the only durable way - by being worth continuing with.
(Corollary for builders: build the slice as throwaway-by-design. No product scaffolding, no accounts, no polish - nothing built to last, so no budget leaks into infrastructure before the core question is answered. The discipline keeps the slice cheap and honest.)
Part 4: Scoping a slice - one question, the most expensive one
A validation slice is not "phase one of the build, but smaller". It is scoped backwards from a question: what is the riskiest assumption this project rests on - the thing that, if wrong, makes everything downstream worthless?
For a scoring or analytics product: can the score be made credible against reality, on real data, for one category? For an automation: does the messy real-world input actually contain the signal the automation needs? For a marketplace: will the supply side show up? For an AI feature: does the model, on your actual documents, reach the quality bar - and at what token cost per run? For a rebuild: what does the legacy system actually do, verified, versus what everyone believes it does?
The test of a well-scoped slice: it can be stated as a question with a yes/no/here's-the-catch answer, deliverable in one to three weeks, and the answer changes what you'd build next. If the proposed slice doesn't change any downstream decision, it's not validation - it's a deposit wearing a lab coat.
What a slice is not: a discount trial of the full service, a mockup sprint (mockups validate desire, rarely feasibility), or a scoping exercise that only produces an estimate. Estimates are the builder's homework; the slice produces knowledge about the project.
Part 5: Pricing and the numbers that make it credible
Rules of thumb that hold across project sizes:
- A slice typically runs 5-15% of the anticipated full build - enough to fund real work, small enough to decide quickly. On a €20-40k build, that's roughly €1,500-4,000; on larger systems, proportionally more.
- One to three weeks of calendar time. Longer, and it's a phase pretending to be a slice; the decision it exists to enable gets stale.
- Fixed price, always. The slice is itself tightly scoped - it's the one part of the project with no excuse for a meter.
- The deliverable list is written into the slice agreement like any fixed-scope work: the question, the method, the artifacts, the date.
Part 6: The conversation, from each chair
Buyer, proposing it to a builder: "Before we commit to the full project, I'd like to buy a small validation piece first - fully paid, at your normal rate, answering [the riskiest question]. If we continue, credit it against the build. Whatever you produce, I keep, documented well enough to stand alone." Builders worth hiring say yes quickly - you've just described their favorite kind of engagement. Hesitation, or a push to "just commit to the full scope, it's more efficient," is your data.
Builder, proposing it to a buyer (or a bake-off): "If you want to evaluate me - or several of us - on actual work, here's my version: a paid validation slice at €X, scoped to answer [the question], delivered in [timeframe], fully credited if we continue within 60 days. You get a real deliverable either way, and you're judging my real work rather than my free work." In a bake-off, this reframes the free-test-project ask into a structure where the serious candidate is also the safest one to fund - and where declining to work free reads as professionalism instead of reluctance, because you've replaced "no" with a better offer.
Part 7: Failure modes, both chairs
Slice creep - "while you're in there, could you also...". The slice has one question; additions are the next slice or the build. (Yes, scope discipline applies to the discipline itself.)
The eternal validator - a buyer who strings three, four slices without ever committing is doing cheap consulting procurement, not validation. Two slices is the honest maximum before the build decision.
The foregone conclusion - a builder who designs the slice to always answer "yes, proceed" has sold a deposit, not a validation. The tell: no version of the slice's outcome would recommend stopping. Insist the "stop" scenario is described up front.
The buried verdict - a findings document that hedges everything. The deliverable must contain a recommendation in one sentence, even when - especially when - the recommendation is "don't build this yet, and here's what has to be true first."
The whole structure on one page
The first engagement answers the project's most expensive question - one question, one to three weeks, 5-15% of the build, fixed price. Paid, because paid work is real work and clean decisions need no debts. Credited on continuation within a time window, so the cautious path and the committed path cost the same. Deliverables that survive without the builder, so nothing about step one locks step two. Scoped backwards from the riskiest assumption, with the "stop" outcome defined up front and the verdict stated in one sentence. It is the rare commercial structure where the incentives of a careful buyer and an honest builder point the same direction - which is exactly why the people who resist it, on either side of the table, are telling you who they are.