Send the same one-paragraph app idea to five development shops and you’ll typically get quotes back within days. One of them will hand you a fixed number, no questions asked. Another will send back three follow-up questions and a range so wide it looks evasive. Founders usually pick the tidy number. That’s the wrong instinct, and it’s worth understanding why before you sign anything.
A quote is not just a price. It’s a readout of how much the shop actually understands about what you’re asking them to build. Software estimates are only as good as the assumptions behind them, and on a one-paragraph brief, there are dozens of assumptions that haven’t been made yet — they’ve just been guessed.
Why a single number this early is a red flag, not a reassurance
Think about what has to be true for someone to give you one firm number before they’ve asked how your app handles offline use, what your auth model looks like, whether you need App Store and Play Store parity on day one, or how “admin dashboard” translates into actual screens and permissions. Either:
- They’ve built something similar enough times that they’re pattern-matching off a template, and they’re quietly going to build you their template whether it fits or not, or
- They haven’t actually thought it through, and the number is a sales tool, not an engineering estimate.
Both outcomes tend to end the same way: change orders. The number that got you excited stops being real around week three, once the questions that should have been asked upfront get asked mid-build instead — as scope changes, each with its own invoice.
A wide range with caveats attached is the opposite signal. “Somewhere between X and Y, depending on whether you need real-time sync and how much of the existing backend we can reuse” means someone has already started identifying the variables that actually move cost and timeline. That’s not hedging. That’s the estimate doing its job.
What a competent first estimate actually looks like
A serious estimate, given honestly and early, tends to share a few traits:
- It comes with questions, not just a number. Things like: is there an existing codebase or API we’re integrating with? What’s the actual MVP feature set versus the “eventually” list? Who’s the target device — is this Flutter-cross-platform or does part of it need native Swift/Kotlin because of a platform-specific feature?
- It names what’s driving the range. Not “it depends,” but specifically: “if the AI feature needs to run inference server-side for data security reasons versus client-side, that’s a different architecture and a different cost.”
- It separates discovery from build. If your project involves an existing codebase — a stalled build, a freelancer’s half-finished handoff — a competent shop will often ask to spend time auditing it before quoting the rebuild, because guessing at the state of someone else’s code is how projects get re-estimated twice.
- It’s willing to say “we don’t know yet” out loud. Not as a stall tactic, but as an accurate description of the current state of information. The number tightens as the questions get answered — that’s the expected shape of the process, not a failure of it.
The freelancer trap looks similar, for a different reason
It’s worth naming that freelancers and small shops sometimes give fast, firm numbers for the opposite reason: not overconfidence, but underestimating the work themselves. A single developer pricing a mobile app plus backend plus admin console may genuinely not have hit the edge cases yet — the push notification permission flow that behaves differently on iOS 17, the admin panel that needs role-based access nobody mentioned in the brief. The quote isn’t dishonest, it’s just naive. The result for you is the same: the number moves later, usually upward, usually after you’re already committed.
This is also where “cheaper” and “faster” quotes deserve extra scrutiny rather than less. If two shops are looking at the same brief and one comes back significantly lower with fewer questions, that gap is information, not a bargain.
What to actually do with this
Before you accept any first quote, low or high, ask directly: “What would need to be true for this number to change?” A shop that’s done its homework will have a ready answer — specific features, specific unknowns, specific dependencies. A shop that hasn’t will either get vague or get defensive. Either response tells you what you need to know before any code gets written.
Where this fits into how we work
At orithLabs, our first conversation with a prospective client is usually more questions than promises — about existing code, real constraints, and what “done” actually means for the first release. If that means the initial range is wider than a competitor’s tidy quote, that’s on purpose: we’d rather narrow it with real information than narrow it later with a change order. If you’re mid-search for a dev partner and want a second opinion on a quote you’ve already received, that’s a conversation we’re happy to have.