What You're Actually Buying When a Dev Shop Quotes You

We write these quotes for a living. Fifteen years of them. The pattern that hurts buyers most is rarely a shop charging too much. It is a shop quoting too little, winning the work on price, and handing you the difference later, as change orders, as skipped testing, or as a system that fails quietly in year two.

Here is the anatomy from our side of the table. Five line items that belong in any serious quote. Four costs that quietly go missing. Two numbers that reveal padding.

A quote is a bet the shop makes about your project

A fixed-price quote is a bet. The shop is wagering that the work fits the hours and the hours fit the people. When the bet pays off, nobody notices. When it fails, a shop with margin absorbs the loss and tells you about it over coffee; a shop without margin comes back for more money, cuts the testing, or goes quiet in month three. Margin is not greed. It is what lets a shop eat its own mistake instead of billing you for it. What you are actually buying is the quality of that wager, because the wager is the plan.

The most expensive software quote we know of started under $5 million. In 2003, Levi Strauss set out to replace a patchwork of country-specific systems with a single SAP platform and hired consultants to lead the effort. Requirements the quote never priced, including a supply-chain interface Walmart insisted on, piled up as the build progressed. Orders stopped going out. The company shut its three U.S. distribution centers for a week during the switchover and booked a $192.5 million charge against earnings in the second quarter of 2008. The CIO resigned.

Harvard Business Review told that story in 2011 as a warning about how little a total tells you. The thinking stapled to the total is the product. The total is downstream.

The five line items that belong in every serious quote

When a quote arrives, check for these five before you look at the price.

1. Discovery and scoping, as its own line. Somebody has to map what exists today, who uses it, and where the data lives before fixed numbers mean anything. On our projects this phase runs 10 to 20 percent of the build, and we bill it openly rather than hiding it inside the rates. A quote with no discovery line is a guess wearing a letterhead.

2. Design with a revision cap. Ask how many revision rounds are included; two or three is normal, and anything unlimited is a sign nobody has managed a creative loop before.

3. Development in milestones. One lump sum for "build the app" gives you nothing to audit. Milestones tied to running software mean you can see progress, catch drift at week six instead of month six, and stop the project with something usable in hand if the relationship sours. Insist on deliverables you can click, not documents you can read.

4. Testing, with hours. If quality assurance doesn't appear as a line with its own budget, the checking will happen in production, and your customers will do it for free.

5. Launch, documentation, and handover. Credentials, repository access, deployment steps, environment notes, and a written list of what you own. If the quote treats launch as one checkbox at the end, ask in writing what happens to all of that if the shop disappears the day after it sends the invoice. This is the cheapest insurance paragraph in the whole contract.

A quote carrying all five is not automatically honest, and a quote missing one is not automatically crooked. But the five lines force the conversation the total alone never has.

The four costs that quietly go missing

The invoice is the beginning of the spending, and four costs routinely sit outside it.

Project management and communication. The calls, the status notes, the decisions logged so they stay logged. On a healthy project this is 10 to 15 percent of the hours. When a quote pretends it costs nothing, either nobody will do it or it is folded invisibly into every rate on the page. You will feel the absence either way, usually around the first missed deadline, when nobody can say what changed or why.

Year two. Warranty windows typically run 30 to 90 days. After that, a bug and a change request become different things at different prices, and most quotes are silent on both. The distinction that matters is defect versus enhancement: work the shop owes you free, against work you pay for again. A quote that never defines it is defining it against you. Ask what an hour of maintenance work costs a year from now, and whether you are allowed to buy none of it.

Third-party services. Hosting, domains, email delivery, API usage, app store fees, license renewals. Small amounts, forever, and they belong to you rather than the shop. A careful quote lists what it estimates and names what it excludes; the pattern of the exclusions tells you how closely anyone read your current stack.

Change orders. Every project changes, because every business changes while the software is being built. The quote should state the change rate and the process that triggers it. Ours does, and we have watched competitors win deals with quotes that mention neither, which works out great right up until the first change request.

None of this is usually a scam. Mostly it is optimism. Buyers pick quotes off the happy path, so shops quote the happy path, and the market quietly trains everyone to lowball. The cure is asking, in writing, about the four costs above.

Fixed price or time and materials

The quote also has to pick a pricing model, and the model is a statement about who carries the risk. Fixed price means the shop carries it, and the premium for carrying it is built into the total. Expect the number to run higher and the scope to be defended hard, because every hour past the estimate comes out of someone's margin. Time and materials means you carry it. The numbers get smaller and more honest per hour, and the discipline moves onto you, or onto the plan you paid for in the discovery line.

Neither model is the problem. We quote fixed when a project's edges are knowable, meaning the discovery work has pinned the integrations and the workflow is stable. We quote time and materials when the edges are genuinely unknowable, usually because the software has to match a process the owner is still redesigning while the build runs. The tell is a shop that quotes the same model regardless of the project, because that shop is optimizing its close rate rather than your risk.

A middle structure exists and is worth asking for: milestones priced individually at fixed rates, with a time and materials tail reserved for the exploratory edges. Most of the rescue work we inherit lands there eventually.

Two numbers that reveal padding

Two arithmetic checks, sixty seconds total, and they work on any quote that lists hours.

The first is hours per line item. Real estimates are lumpy, because real features differ; the login screen and the reporting engine are not the same amount of work. When every line carries the same hours, 40 and 40 and 40, nobody estimated anything. The total was set first and divided backward. Uniformity is the fingerprint of a number in search of a justification.

The second is testing share. Add the QA hours and divide by the total. Under 10 percent means the checking phase gets sacrificed the first time the schedule slips, and a missing QA line means it already was. Honest quotes land between 15 and 25 percent, and a quote that skips the range entirely is telling you where the padding lives: everywhere.

Both checks are blunt. Use them that way. A quote can fail both and still be honest if the shop will show its assumptions, and a quote can pass both and still be a trap if the team assigned to it is all junior. Which is why the last step is a conversation.

How to pressure-test a quote in one call

Read the quote once by yourself, then book thirty minutes and ask five questions.

• "What did you assume to get this number?"
• "Which parts of our current systems did you not look at?"
• "Who is on the team day to day, and what is the senior to junior mix?"
• "What triggers a change order, and what does one cost?"
• "If we cut 20 percent of the budget, what stops being built?"

The last question separates shops that estimated from shops that divided. A shop that knows its numbers will name what disappears, feature by feature, because the estimate maps to real work. Listen for specifics. "We can be flexible" is what a padded total sounds like when it is asked to defend itself.

The bottom line

Buy the plan, not the number. The smallest quote you collect will usually be the least examined project on your desk, and cheap is what an auditable plan costs before it becomes expensive. Run the two arithmetic checks, spend the thirty minutes on the five questions, and you will know more about the shops on your list than their references will ever tell you.

When you want to see what a quote looks like with its math showing, our custom software development page walks through how we scope, stage, and hand over projects, and what you hold when we are done. Ask us for a quote and judge it against every rule on this page. We would rather lose the deal than write the thinnest one.