How to read a dev quote before you sign it

A dev quote is a sales document formatted to look like an engineering document. Once you see it that way, reading one gets much easier.

Last year a first-time founder sent us an $85K quote for a two-sided marketplace. Nothing about it looked wrong to them, because nothing about it was visibly wrong. The line items were plausible. The tech words were real tech words. We tore it apart line by line and got the same product built for $42K. Here's what we looked for, in the order we looked.

1. Find the line items that don't have a user

Every line item should map to something a user does. "Admin dashboard, $12K" sounds necessary until you ask: who logs into it, and what do they do there in month one? In the $85K quote, $35K of scope had no answer to that question: an analytics module, a recommendation engine, and a custom content-management system for a product with zero users.

The rule: if a feature exists to serve scale you don't have, it's not scope, it's padding.

2. Check the estimates against the boring parts

Agencies rarely pad the exciting features, because you're paying attention to those. They pad the boring ones: "project setup," "testing & QA," "deployment," "project management." In our audit, setup and project management alone were $8K, roughly 60 hours of billable time for work that modern tooling does in an afternoon.

A reasonable benchmark: setup and automatic, safe deployments for a standard web stack (the usual set of tools an app is built on) is 1–3 days of work, not 2 weeks. If QA is quoted as more than ~20% of build time for a v1, ask what exactly is being tested.

3. Ask what stack, then ask why

The quote said "custom backend." The product was a standard forms-and-data app with payments. A Next.js + Supabase + Stripe stack covered the entire v1 and removed an invented microservices architecture (lots of separate mini-apps where one would do) from the bill. You don't need to know the right stack yourself. You just need to ask the vendor to defend theirs against a simpler one. If the defense is "scalability," see rule 1.

4. Look for what's missing

Padded quotes are also usually incomplete, because detail is where padding gets caught. Things commonly missing that you'll pay for later: error monitoring, backups, admin access handover, who owns the accounts, and what "done" means. If the quote doesn't say you own the code and the infrastructure accounts, assume you don't.

5. Get the price per outcome, not per feature

Reframe the conversation: "What do I pay to have a version live that a real customer can use?" That number, and the date attached to it, is the only quote that matters. Everything past it should be a decision you make later with real usage data, not something you pre-purchase at maximum uncertainty.

The short version: map every line to a user, audit the boring line items, make them defend the stack, hunt for what is missing, and buy outcomes instead of features. Or send us the quote: we run this exact process for $49 and send you the teardown as a PDF within 48 hours.