Last spring we bid on a warehouse system. Forty-one bullets, every one starting "the system shall," fixed price demanded, twelve-week deadline. Nowhere in nine pages did it mention that inventory lived in a 2011 Sage instance with no API, reachable only via a nightly CSV drop that a warehouse manager kicked off by hand. We found that out on a call, because we asked. The other five bidders priced the document as written and came back somewhere between $40k and $600k. The buyer had no way to tell whether the $40k was efficiency or ignorance.
That spread isn't vendor greed. It's the RFP working exactly as written: a features list says nothing about where the work lives, so each vendor privately guesses at the unknowns and buries the guess in margin. Optimists bid low and change-order you in month three. The scarred ones bid high, because they've all met a legacy Oracle instance that nobody mentioned until week five. If you want comparable bids, write down the things that make estimates differ. Those are almost never features.
The four things that actually move the number
Integrations, data migration, auth, and who signs off. That's the list. A CRUD app on a clean Postgres schema with Google login is a solved problem; any competent shop lands within 20% of the same estimate. The variance is your logistics provider's SOAP endpoint that returns HTTP 200 with the error in the body, so every call needs a parser before you can tell success from failure. It's the 900k customer rows carrying three date formats in one column, plus 40k where the format is just wrong and someone has to decide what 03/04/12 means. It's SAML against an identity provider whose admin left in 2023. It's the compliance officer who must approve every screen and is only in on Thursdays — which turns a two-day change into a nine-day one, every time.
So put those in the RFP. Name every system we have to talk to. For each, say whether documentation exists, whether you control it, and whether we get sandbox access before contract signature — that last one alone moves our number 15-25%, because sandbox access is the difference between reading an integration and testing it. Say how many rows, exported from where, and when someone last actually looked at the data. Name the single decision-maker and their real turnaround on a review, not the aspirational one. A vendor who reads that prices the work instead of pricing their fear of it, and the bids converge.
Stop asking for a fixed price on a discovery-shaped problem
Fixed price is a fine instrument when scope is genuinely known: a rebuild of something that already runs, an integration against an API we've already read end to end. It's a terrible instrument when half the requirements are "we'll know it when we see it." What a fixed price on unknown scope actually buys is an adversarial relationship. Every clarification becomes an argument about whether it was implied in section 4.2, and the vendor's incentive flips from building the right thing to building the cheapest thing that survives acceptance testing. You can watch it happen: the fourth change request is where the tone of the email thread changes.
The structure we push for — and would tell you to demand from anyone — is a paid discovery. Two to three weeks, fixed price, roughly 5-8% of the expected build, real money but not much of it. It ends with a technical spec, a working spike against the scariest integration, and a fixed or capped number for the build. On the warehouse job, the spike was one script pulling a real CSV export; it found 6,000 rows with a supplier code that didn't exist in the master list, and that finding reshaped the whole migration plan before anyone signed anything. If a vendor won't do discovery, or offers it free, those are red flags pointing opposite directions. Free means they're recouping it somewhere you can't see. Refusing means they intend to guess.
What makes us no-bid
A no-bid isn't an insult, it's information. Read it that way. We walk from a fixed price on undefined scope, because we'd have to pad 60% to sleep at night, and you'd correctly reject us for a shop that padded 10% and plans to win the difference back in change orders. We walk when evaluation criteria are 70% weighted on price — that's a purchasing decision wearing a technical costume, and the winner is whoever misunderstood the work most confidently. We walk when there's no named technical contact. If procurement is the only door in, every answer we get has been through two translations, and we'll be discovering the real requirements in week six at your expense.
The other reliable tell is an RFP that specifies the implementation. Mandate the framework, the cloud, the database, and the sprint cadence, and you've either already picked your vendor and are running a compliance exercise, or you paid a consultant to write a document they won't have to build. Real constraints are welcome and belong in the RFP: we're a .NET shop, data can't leave EU regions, we're reusing this identity provider. Those are facts we price against. Preferences dressed as constraints cost you exactly the vendors who'd have told you something you didn't know.
The RFP we'd actually like to receive
Six pages. One page of business context: what's broken, what it costs — in hours, tickets, or churn you already measure — and what "working" looks like in a number you already track. One page of integration surface, listed honestly, sandbox availability marked per system. One page on data: volumes, sources, the quality problems you already know about, and what cutover means (big-bang weekend, or dual-write for a month?). One page of non-negotiable constraints, kept separate from preferences. One page on process: who decides, how fast, what acceptance actually requires. One page on commercials, including budget range and who owns the thing after launch.
Include the budget range. Every buyer believes withholding it prevents anchoring; in practice it means half the responses solve the wrong problem. Tell us $80k and we propose the $80k version — narrower scope, sharper phasing, phase two named and deferred — instead of the $250k version you'll bin unread. And ask for a reference from a project that went badly, not a case study. Anyone can produce a happy client. What you need to know is what a vendor does in week nine, when the integration turns out to be a nightly CSV and a warehouse manager with a mouse.