Selling a Six-Figure Build to a Buyer Who Cannot Evaluate It

A buyer who understands software judges your technical approach. A buyer who does not - which is most of the people signing six-figure development contracts - judges something else entirely.

They judge how likely you are to fail them. And in the absence of any way to assess that, they default to the one variable they can compare: price.

Most lost deals in technical services are lost here, not on capability.

What the buyer is actually worried about

Sit with the buyer’s position for a moment. They are about to spend a meaningful portion of a budget on something they cannot inspect, will not be able to evaluate when delivered, and which they have probably watched go wrong before - either here or at a previous job.

Their real questions are not about your stack.

• Will this cost what you said?
• Will it arrive roughly when you said?
• Will it do the thing we actually need, or the thing I badly described?
• If it goes wrong, how exposed am I personally?

That last one drives more decisions than anything else and is almost never said aloud. The person signing is making a career-visible bet. A proposal that reduces their personal exposure is worth more to them than one that is technically superior.

Make the first commitment small

The single most effective change to a technical sales process is refusing to quote a large build from a vague brief - and offering paid discovery instead.

Paid discovery is a short, separately-priced engagement producing a specification, an architecture outline, a phased plan and a firm estimate. Priced at a small fraction of the build.

This works on three levels simultaneously.

It reduces the buyer’s decision size. They are no longer approving a six-figure build on faith. They are approving a small, bounded piece of work with a concrete deliverable. That is a decision a manager can make without a committee.

It makes your eventual quote credible. You are quoting against real understanding rather than assumption, which means the number holds. As covered in why development quotes vary 10x, the cheapest quote is usually the one that understood the least - discovery is how you demonstrate that you are not that quote.

It qualifies hard. A prospect unwilling to pay a small amount for discovery was rarely going to sign the large contract. Finding that out in week one instead of week eight is worth the deals it costs you.

Name the risks before they do

Counterintuitively, the fastest way to build confidence with a nervous buyer is to tell them what could go wrong.

Every vendor claims their process is solid and their team is experienced. It is noise; the buyer has heard it from everyone. What almost nobody does is say:

“The two things most likely to go wrong here are the data migration from your existing system - we have not seen inside it yet, and if the data is inconsistent that could add three to four weeks - and getting sign-off from your compliance team, which we would want to start in week one rather than week ten.”

This does several things at once. It demonstrates you have actually thought about their project rather than pattern-matched it. It sets expectations before there is a problem, which is the only time expectation-setting works. And it makes every competitor who claimed everything would be smooth look like they had not looked closely.

Buyers do not expect zero risk. They expect you to know where it is.

Sell in stages

Large projects sold as single commitments are hard to approve and brutal when they go wrong. The same project sold as phases - each with its own deliverable, price and decision point - is much easier to say yes to.

A workable structure:

Phase	Deliverable	Buyer’s decision
Discovery	Spec, architecture, firm estimate	Small, low-risk
Phase 1	Working core, one complete workflow	Continue or stop with something usable
Phase 2	Remaining scope	Continue, having seen you deliver
Support	Ongoing maintenance	Renewal, not a leap

The point of the “stop with something usable” property is that it genuinely de-risks the buyer, which is why it closes deals. It also imposes useful discipline on you - a Phase 1 that must stand alone forces exactly the scoping rigour described in MVP scoping.

When you lose on price

Losing to a cheaper vendor is almost always a scoping failure rather than a pricing one.

If two proposals describe similar deliverables and one costs half as much, the buyer is being rational. They cannot see what the extra money buys, and “higher quality” is not visible in a document.

The response is not to discount. It is to make the difference legible - usually by being concrete about what the cheaper proposal has not accounted for. Not as a criticism of the competitor, but as a set of questions the buyer can go and ask:

“It is worth asking any vendor at that price point what happens when the legacy data does not match the schema, whether the estimate includes the compliance review, and who owns the system after handover. Those three things account for most of the difference between quotes on projects like this.”

You have now armed the buyer to evaluate properly rather than asking them to trust you. If the cheaper vendor genuinely covered all three, they deserved to win.

The uncomfortable part

Some deals are lost because the buyer wanted the cheapest option and always would have. Chasing those with discounts trains your pipeline toward exactly the clients who will be hardest to serve profitably.

The buyers worth winning are the ones who have been burned before - they understand why the cheap option was expensive, and they are looking for evidence that you are different. Everything above is that evidence.

For those buyers, the strongest asset is not a portfolio. It is being visibly specific in public about how this work actually goes - which is the entire argument for publishing honest content about costs and trade-offs rather than case studies claiming everything went perfectly.