A founder came to us with a scoped project, a term sheet already signed, and a competing quote for six weeks. We looked at the same requirements doc and landed on eighteen. Same feature list, same two people reading it, three times the number. We didn’t take the project. Not because we couldn’t hit six weeks — we could have, the same way you can drive from Chennai to Bangalore in three hours if you don’t stop for traffic, fuel, or the possibility of a flat tire.

The gap wasn’t a pricing disagreement. It was a scope disagreement dressed up as a timeline disagreement, and that distinction is the whole post.

A timeline is a bet on what “done” means

When an agency hands you a number, they’re implicitly telling you what they think the project includes. A six-week quote for an app with user accounts, payments, and an admin console usually means one of three things is true: they’re planning to skip something you assumed was included (data migration, edge-case handling, admin tooling), they’re quoting the happy-path build and treating bug fixes as a separate future invoice, or they haven’t actually read your requirements closely enough to know what they don’t know yet.

In the project we turned down, the six-week quote covered building screens against a fixed, ideal API. Our eighteen-week estimate included the same screens, plus the actual state of the backend the client already had — which had no real authentication layer, an admin console that existed only as a Postman collection, and payment logic that had never handled a refund or a failed webhook retry. None of that was hidden. It was in the documents both agencies received. Only one estimate priced it in.

This is the pattern to watch for: a low number isn’t usually a sign of efficiency, it’s a sign of a narrower definition of the work. The question worth asking any studio isn’t “how long will this take” — it’s “walk me through what’s in week one, week four, and the week before launch.” If they can’t produce that breakdown on the spot, the number was a guess dressed as a quote.

How to pressure-test a quote before you sign anything

You don’t need to be technical to catch this. You need to ask questions that force the estimate to show its work.

  • Ask what happens to existing code. If you have a partially built product, ask explicitly: “does your estimate assume you’re rewriting this, patching it, or auditing it first?” Those are three different timelines, and an agency that hasn’t opened your codebase yet can’t have priced in the right one.
  • Ask for the three riskiest weeks, not the whole plan. Any studio can build a Gantt chart. Ask which specific parts of the build they’re least certain about, and what happens to the timeline if that uncertainty resolves badly. If the answer is “nothing, we’ve built this before,” ask what “this” refers to — a similar feature, or this exact integration.
  • Ask what’s excluded. Testing, app store review cycles, client feedback rounds, a security pass before handling real payment data — these get quietly left off short quotes and reappear later as “phase two.” Get the exclusion list in writing before you compare numbers.
  • Ask to see it working, not just described. If a studio claims a capability — offline sync, background jobs, biometric auth — ask for a two-minute walkthrough of it running in a shipped product, not a slide describing it. Claims about what’s already been built are cheap; screen recordings of a live app aren’t.
  • Compare scope line by line, not totals. Put both quotes side by side against your actual requirements doc and mark what each one silently assumes. The gap usually isn’t in the coding — it’s in what counts as “the project.”

Why the honest number is usually the safer bet

A founder choosing between a six-week quote and an eighteen-week quote is, understandably, going to lean toward six. But the real choice isn’t six weeks versus eighteen — it’s eighteen weeks versus six weeks plus however long it takes to discover, mid-build, that the admin console was never actually scoped, followed by a change order, a schedule slip, and a harder conversation than the one you could have had up front.

We’d rather have that harder conversation on day one, when you still have options, than in week seven when you’ve already paid a deposit and lost the leverage to walk away.

This is also why “why you and not a freelancer” isn’t really about skill — plenty of freelancers are excellent engineers. It’s about who’s incentivized to tell you the truth about scope before you’ve committed. A studio quoting to win the deal has a reason to underprice the timeline. A studio that’s turned down work over exactly this mismatch has already shown you which way it leans.

What this looks like in practice

At orithLabs, we’ve built and shipped our own products — Crumb Count and Kompete — end to end, which means our estimates come from having personally sat through the parts of a build that don’t show up in a feature list: the auth edge cases, the app store rejection nobody budgeted for, the API that behaves differently under load. When we quote a timeline, it’s built the same way we’d want someone to quote it to us. If that number comes in higher than someone else’s, we’ll walk you through exactly why, line by line, and let you decide — no pressure, just the real shape of the work.