An agency will build what you specify, on schedule, to spec — and none of that touches the reason most ideas die. Across 23 real runs of our own discovery gate, 706 candidate ideas were rejected, and 438 of them failed the one question a statement of work never asks: is there a documented problem behind this? Three things are worth settling before you sign, and all three are cheaper than a change order.
What a build contract is actually good at
A good agency absorbs a specific risk for you: that the thing does not get built. Scope, price, date, quality of the code, somebody to call when the deploy breaks. That is a real service and it is worth paying for.
It cannot absorb the other risk, and it is not structured to try. The contract is satisfied when the software matches the specification. Whether anyone will pay for software that matches that specification is a question the agency did not take on, cannot answer from inside the build, and has no commercial reason to raise while the quote is being signed.
So the useful division of labour is: they own delivery risk, you own demand risk, and the moment to discharge your half is before the statement of work is fixed — because after that, every answer you discover arrives as a change order.
The three things that kill the most candidates
Our discovery pipeline sources candidate ideas itself and runs each one through a published set of deal-breaker checks. On 23 real runs it rejected 706 of them, and three checks account for most of the damage:
Counted on production 2026-09-06, bars relative to the largest. Each percentage is of all 706 rejections, and they sum to more than one hundred because a candidate can fail several checks at once — which is the next figure.
Read them as three different kinds of expensive. No documented problem means the work was never anchored to something a person wrote down. Support load means the product is shaped so that every customer needs a human, which is a payroll decision disguised as a feature set. Platform dependence means somebody else can end the business with a rule change, and that one shows up in the architecture the agency is about to write.
None of the three is a code-quality question. All three survive a flawless build.
Where we counted it, most of them failed in company
The rejections overlap, and the overlap decides whether a scope change is worth buying. We have the sole-cause split for two of the three checks above:
The solid segment is the candidates for which this was the only reason recorded; the faded one is the candidates that also failed something else. Both rows are drawn on the same scale, so the widths are comparable between them.
The two rows are not alike, and the difference is the useful part. 89 per cent of the platform-dependence kills named something else as well; on the pain check it is 50 per cent, near enough to a coin flip. What the census does not record is the split for any other filter, so this is two checks rather than a claim about all 706 rejections.
That is the arithmetic behind a familiar experience. You take the one objection you have heard, you pay to have it addressed, and the idea still does not work afterwards — because the objection you heard was one symptom of something that was wrong in several places at once. A weak idea is rarely weak in a single dimension: what has no evidence behind it is usually also hard to reach a buyer for, since both come from the same missing piece of work.
What to settle before the statement of work is fixed
Three pieces of evidence, none of which needs a developer.
- Find the complaint in writing. Not a conversation, not your own experience of the problem — a public post, thread or review from somebody who is not you, describing the thing your product would fix. If an afternoon of searching turns up nothing, that is information, and it is the cheapest information you will ever buy. Our own gate does exactly this and nothing more: it matches a candidate against documented problems collected during the run, and drops it when there is no match.
- Price the support before you price the build. Estimate minutes per customer per month, put it through the support-hours calculator, and read the band that comes back. A product needing an hour of you per customer per month has a ceiling that has nothing to do with how good the code is — the arithmetic is here.
- Name the dependency that can change its rules. An app store, one API, one marketplace, one vendor whose pricing you do not control. Write down what the product becomes if that party changes terms next quarter, and whether the answer is "a smaller business" or "nothing" (what to look for).
Each of those carries a decision. If the complaint exists, the support fits and the dependency has a fallback, then build risk really is your main remaining risk, and hiring an agency is a reasonable way to retire it. If not, the specification you are about to buy is the expensive version of a question you can answer this week.
What this census is not
The 706 rejections come from our own accounts rather than from customers, so this measures how our gate behaves and not how a market behaves. It is an honest denominator for a claim about what tends to be wrong with candidate ideas, and nothing more.
The biggest row also says something narrower than it sounds. "No documented problem" means we found no documented problem, not that none exists; plenty of expensive problems are discussed on calls and never written anywhere a crawler reaches. What rules out the other reading — that we simply had nothing to compare against — is that those runs collected 943 documented problems available to match against, roughly 41 per run, and the number of runs with none was 0. Every rejection on that row failed to match evidence we had.
Checking an idea you bring costs 1 credit — against the twelve-filter list, which is a different list from the one above and deliberately does not include the pain check, since a pasted idea has no collected evidence to match against. Signing up grants 2 credits, and the smallest pack after that is $19 for 2. Against a five-figure build, the price of the question is not the interesting variable.
The short version
- An agency owns delivery risk. Demand risk stays with you, and the window to discharge it closes when the specification is fixed.
- On 23 runs and 706 rejections, the three most common causes of death were a missing documented problem, support load, and platform dependence. A perfect build fixes none of them.
- Of the platform-dependence kills, 89 per cent named another check too; the pain check splits about evenly. Paying to fix the one objection you heard is a bet on which side of that your idea fell.
- Go and find the complaint in writing, put the support minutes through a calculator, and name the dependency. Then sign.