Most software budgets are not lost during the build. They are lost in the decision to build, taken months earlier by people who did not yet have the information that would have changed their answer. By the time that information turns up, it arrives disguised as a delivery problem.
Product Feasibility — Market to Motion starts at $3,500, and that is a floor. It is a fixed-scope investigation of one product idea, run before anyone commits an engineering budget: market reality, technical risk priced by a working spike, a three-band cost envelope, and a build or do-not-build recommendation with the reasoning shown. The purpose is not enthusiasm. It is to move discovery to the cheapest point on the timeline.
The cost of finding out late
Every project has a moment where the real constraint appears. The data you assumed was clean is not. The API you assumed was public requires a partnership. The users you assumed wanted this already have a workaround they like. That moment is going to happen either way. The only variable you control is how much has been built on top of the assumption by the time it does.
Discovery is cheap before anything is committed and expensive once delivery is underway, because the cost of being wrong is not the wrong decision itself. It is everything scheduled behind it. Hiring gets committed. Contracts get signed against a launch date. Other teams plan a quarter around a dependency. Unwinding that costs more than the engineering it replaces, and it costs credibility, which has no line item.
For scale, our own Enterprise Build engagement starts at $25,000, and that is a floor, not a teaser. Spending a fraction of that floor to find out whether the floor is worth crossing is not caution. It is arithmetic.
A working spike reveals what a document cannot
A feasibility document written from research tells you what should be true. A spike tells you what is true. The difference matters most exactly where the money is.
A spike is real code written against the real system: the actual endpoint, the actual authentication flow, the actual rate limits, the actual shape of the data once it leaves the vendor's example payload. That is where the surprises live. The endpoint you need is read-only. The sandbox behaves differently from production. The export you were promised exists, but only as a nightly file, which quietly rewrites the product from real-time to batch.
None of that is visible from documentation, and none of it is something a vendor volunteers. It becomes visible the moment someone actually tries. A spike also changes the quality of every estimate that follows, because whoever produced it has already done the hardest part of the work rather than imagining it.
Why a three-band cost envelope beats a single number
A single number claims a precision nobody has, and everyone reads it differently. Finance reads it as a commitment. The buyer reads it as a ceiling. The team reads it as an aspiration. When reality lands somewhere else, the argument becomes about the number instead of the thing that moved.
Three bands make the uncertainty explicit and legible. Each band is attached to what has to be true for it to hold. The low band assumes the integration works the way the spike suggests and the scope stays put. The high band prices the failure of those assumptions. That turns an estimate into a decision instrument. You can ask whether the idea is worth doing at the top of the range instead of quietly betting on the bottom, and you can see which assumption carries most of the spread and test that one first.
A do-not-build recommendation is a successful outcome
What you are buying is a decision, not a permission slip. If the honest answer is that the idea does not survive contact with the market or the technology, delivering that answer is the service working, not failing.
The incentive is the hard part, and it is structural. A firm paid to build has a reason to find a way to build. We price feasibility as its own fixed-scope purchase, separate from delivery, so the recommendation costs us nothing either way. It is also why the reasoning is shown rather than summarised: you should be able to disagree with the conclusion on the evidence.
A do-not-build finding is not a flat no. The recommendation is specific about what it rules out: not this way, not this segment, not before the data problem is fixed. A finding like that hands back the rest of the budget and the calendar for better odds. It also makes the opposite verdict mean something. A recommendation to build is only worth having from someone who was willing to say the other thing.
What happens next
If the answer is build, the work continues into Product Development, into the Service Configurator if what you need is a storefront rather than a platform, or into the Growth Loop Program if the product exists and nobody knows. If the answer is do not build, you have spent the price of an investigation rather than the price of a build on a question that would otherwise have been answered by your bank balance.
Every engagement we sell is fixed-scope and publicly priced. All four are on the store. You can book a time or write to us with the idea you have been arguing about internally.