A founder once told us they’d been quoted “6-8 weeks” for an app with a booking flow, payments, and admin dashboard, based on a 45-minute call and a one-page brief. No mention of which payment provider, no mention of who’d handle refunds and disputes, no mention of whether “admin dashboard” meant a spreadsheet-style table or a role-based system with permissions. That number wasn’t an estimate. It was a guess dressed up as one, and it usually turns into a change-order conversation around week 5.

Fixed-price quotes fail for a predictable reason: the price gets set before the scope is actually known. The fix isn’t a longer sales call or a fancier proposal template. It’s a specific set of questions that force scope decisions to happen before the contract, not during the build. Here’s what we actually ask, and why each question exists.

Questions about what already exists

Most “new” projects aren’t actually greenfield. There’s an old codebase, a half-built MVP from a previous freelancer, an existing user base, or data sitting in a spreadsheet that needs to migrate somewhere. Skipping this step is the single biggest source of scope blowups we’ve seen, because inherited constraints don’t show up in a feature list.

  • Is there existing code, and can we see it before quoting? A codebase in reasonable shape adds days. A codebase with no tests, mismatched dependencies, or an abandoned migration can add weeks — and you can’t know which one you have without opening it.
  • Is there existing data, and in what shape? “We have a Google Sheet with 3,000 customers” and “we have a Postgres database with 3,000 customers” are different projects, even if the end result looks identical to a user.
  • Are there existing accounts we’re inheriting — payment processor, app store listings, cloud hosting, domain/DNS? Access delays here quietly eat calendar time that never shows up in a scope document.

Questions that separate “must work” from “would be nice”

Every brief has soft edges. The work of a real estimate is finding them before they become disputes about what was “included.”

  • What happens when it fails? A payment integration isn’t just “charge the card.” It’s what happens on a declined card, a timeout mid-transaction, a refund request, a chargeback. Most briefs describe the happy path only. The failure paths are usually half the engineering effort.
  • Who else touches this system, and what do they need to see? “Admin dashboard” can mean a founder checking totals once a week, or three internal roles with different permissions and an audit log. These are different builds, and the word “dashboard” hides the difference.
  • What’s the actual load? A booking system for 50 appointments a week and one for 50 an hour aren’t the same architecture. We ask for a real number, even a rough one, because “it needs to scale” without a number is not a requirement — it’s an anxiety.
  • Which platforms, specifically? “Mobile app” isn’t a spec. iOS only? Android only? Both, and does it need native performance for something like camera or offline sync, or is a single Flutter codebase enough? This decision changes both cost and timeline, and it needs to be made with you, not assumed by us.
  • What’s the definition of done for the AI feature? If there’s an AI component, we ask what “working” means in numbers — acceptable error rate, response time, cost per query at expected volume, and what happens when the model gets something wrong in front of a customer. “Add AI to it” without those answers isn’t a scoped feature yet.

Questions that expose who actually owns the decision

Scope creep often isn’t a technical problem. It’s an unclear decision-making chain that surfaces mid-project as a new “must-have.”

  • Who signs off on scope changes, and how fast can they respond? A two-day approval delay on a design decision doesn’t disappear — it gets absorbed into the timeline, usually silently.
  • What’s the real launch constraint? A fundraising deadline, a trade show, a contractual date with a partner. “As soon as possible” isn’t a constraint we can plan around; a specific date is, even if it means cutting scope instead of cutting corners.
  • What’s the one thing that, if it broke on day one, would be unacceptable? This question tends to produce the most honest scope conversation of the whole process, because it forces prioritization instead of a wish list.

Why most agencies skip this

Asking these questions properly takes real time — often several hours across a couple of sessions, sometimes with a short paid discovery phase for anything with unclear existing code. That’s slower and less flattering than a same-day quote, and a same-day quote is easier to sell. But a fast quote built on assumptions isn’t cheaper — it’s the same cost, deferred and disguised as a change order later. The agencies that skip discovery aren’t more efficient. They’ve just moved the estimation risk onto you, and it usually shows up around the point you’ve already paid a deposit.

This is the process we run before any fixed-price number leaves our mouths — partly because we’ve had to fix codebases where this didn’t happen the first time, and partly because it’s how Crumb Count and Kompete got built without a mid-project scope fight. If you’re currently staring at a quote that feels more like a guess than an estimate, it’s worth running it through these questions yourself before you sign anything.