A founder sends three agencies the same one-paragraph brief and gets back three numbers: $18k, $44k, $90k. Same app, same screens, a 5x spread. The instinct is to assume someone is overcharging. Usually no one is. The three quotes are pricing three completely different projects, because the brief never said which one it was.
Before we quote a native iOS build, we ask five questions. None of them are about features. They're the questions that decide whether your project lands at the bottom of that range or the top — and whether it ships on time at all. Here they are, in the order we ask them.
IMAGE PROMPT: A dark-mode MacBook Pro showing a scoping whiteboard with five numbered questions, soft purple ambient glow (#7F1BFF), Apple-style minimal design, 8K, founder-meeting context — no stock handshakes.
Key takeaways
- The 5x spread between quotes is almost never price — it's undefined scope. Scope creep affects roughly half of software projects and drives most failures.
- Ask: what ships day one, who owns the backend, does it need to feel native, where does trust break, and who maintains it after launch.
- The questions an agency asks you are a better signal than the number they send back.
- Industry data: projects with clear scope hit ~90% success rates; projects without it overrun by ~45%.
Why a feature list is not a scope
Most founders think they're buying a list of screens. They're actually buying a set of decisions about risk — and the feature list barely touches those. That gap is where projects die. Scope creep affects more than half of software projects and is implicated in the large majority of failures, and changing requirements mid-build can add up to 50% to cost.
The Standish Group's long-running data tells the same story from the other side: only about a third of software projects succeed overall, but the ones with clear scope and real planning succeed roughly 90% of the time. The variable isn't talent. It's whether anyone defined the project before building it.
So when an agency answers a vague brief with a confident flat number and no questions, that's not efficiency. It's an argument scheduled for month three. These five questions are how we surface that argument in week zero, while it's still cheap.
1. What has to be true on launch day — and what can wait?
Almost every founder describes version three when we ask about version one. They want the social feed, the AI assistant, the admin dashboard, and payments — at launch. The real question is narrower: what does the first release have to do for a user to get value and for you to learn something?
This single answer can move a quote by half. A focused first release with two or three core flows is a different project than a platform. We push hard here because a narrow, sharp launch is the cheapest risk reduction available — and it's exactly the trade-off we break down in our guide to what $12k vs $80k actually buys. If you can't name what waits, the budget will decide for you, badly.
2. Who owns your backend, and can I see the API?
This is the question that most agencies skip and that most accurately predicts the timeline. A native app is, to a first approximation, a UI on top of your API. If that API is clean, well-documented, and free of browser-session assumptions, data flows fast. If it returns HTML fragments, leans on cookies, or has no owner who can answer questions, weeks disappear before a single screen exists.
On our SOAPNoteAI iOS build, the backend was clean enough that we had core data flowing in about a week against a two-week estimate. We've also seen the opposite, where the API is the project and the app is the easy part. We can't tell which one you have from a feature list. We can tell in twenty minutes of looking at the API.
3. Does this need to feel native, or just run on a phone?
These are different products with different price tags. “Runs on a phone” often points toward React Native and a shared iOS/Android codebase. “Feels native” — Face ID, background audio, widgets, a motion system tuned rather than translated — points toward Swift and platform-specific work.
We don't answer this with a framework preference. RueBlur runs on React Native because moving across both stores together mattered more than per-platform polish. SOAPNoteAI is native because clinicians needed it to feel trustworthy and fast on iPhone. The honest version of this decision — and the questions behind it — lives in our native vs hybrid breakdown. Choosing the stack before answering this is the most expensive guess a founder can make.
4. Where does trust break if you get it wrong?
Every product has one or two places where a quiet failure costs you a user permanently: authentication, payments, data handling, compliance. These are never the demo-friendly parts, and they're where founders under-budget the most.
Authentication is the classic trap. On SOAPNoteAI, the OIDC login flow took more iterations than any other workstream — not because it was hard to write, but because its failure modes were silent and only appeared in production-like conditions. A missing offline_access scope doesn't fail at login; it fails an hour later when the token expires. In regulated builds, the risk hides one layer further out: push notification payloads and analytics SDKs can process protected data without a Business Associate Agreement and fail a HIPAA review while passing every functional test. ⚠️ VERIFY BEFORE PUBLISHING — confirm any specific compliance claim against your own BAA and counsel.
5. What happens after launch — and who owns the code?
An app is not a delivery; it's a dependency. iOS ships a major version every year, and ongoing maintenance commonly runs around 20% of the original build cost annually. If nobody scoped that, the “finished” app quietly rots until an OS update breaks it.
And read the ownership clause before you sign anything. Some contracts quietly retain rights to the source code, and if an agency uses subcontractors without work-for-hire agreements, those people may own pieces of your product. We hand over full IP and the repository as a default. Not every shop does — so ask, in writing, early.
| The question | What a vague answer hides | What it changes |
|---|---|---|
| What ships day one? | Version three described as version one | Can swing the quote by ~50% |
| Can I see the API? | Browser-coupled endpoints, no backend owner | Weeks added before any UI exists |
| Native or just on a phone? | Stack chosen before product risk is known | Determines codebase and rewrite cost |
| Where does trust break? | Silent auth, payment, and compliance failures | The bugs that don't show in a demo |
| Who maintains it? | No post-launch budget, unclear IP ownership | ~20%/yr upkeep, and who owns the code |
The recommendation: judge the questions, not the quote
Here's the stance we'll defend: the cheapest quote that skips these questions is the most expensive option on the table, because the cost lands later as change requests, rewrites, and a launch that slips two quarters. A scope is not a price — it's a shared understanding of what could go wrong.
So when you're comparing agencies, invert the test. Don't grade the number they send back. Grade how many of these five they asked you before sending it. The ones who ask are pricing your actual project. The ones who don't are pricing a guess, and you'll pay the difference.
What this looks like in practice
When SOAPNoteAI's founder came to us, the brief was “take our live web product native on iOS.” Before quoting, we ran these questions. Day-one scope: preserve every existing account and the core clinical workflow, nothing new. The API: clean, which we confirmed by reading it. Native vs hybrid: native, because trust on iPhone was the point. Trust failure point: OIDC auth and HIPAA-adjacent data paths. Maintenance: a clear owner for OS updates.
That conversation reshaped the estimate before a line of Swift was written — the API came in faster than planned, auth slower, and nobody was surprised, because we'd named both risks up front. The app cleared App Store review on the first submission. That's what scoping buys: not a smaller number, a number that holds.
FAQ
What questions should I ask before hiring an iOS development agency?
Five: what ships on launch day versus later, who owns the backend and can you see the API, whether the app must feel native or just run on a phone, where a quiet failure breaks user trust, and who maintains the code after launch. The agency's own questions matter more than their quote.
How do I avoid scope creep on a mobile app project?
Define what the first release must do for a user to get value, and write down explicitly what is deferred. Scope creep affects roughly half of software projects; the fix is a narrow, named launch scope agreed before building, not a long feature list everyone interprets differently later.
Why do agencies quote such different prices for the same app?
Because a short brief lets each agency assume a different project. One prices a focused MVP, another a full platform, a third a regulated build. The spread reflects undefined scope, not dishonesty. A real proposal names assumptions, risks, and what is excluded — a flat number with none of that hides them.
Should I give an agency my full feature list before getting a quote?
Share it, but don't expect it to produce an accurate quote on its own. A feature list describes screens; cost lives in risk — your API quality, auth, payments, and compliance. The most useful thing you can hand over is a list of backend endpoints that rely on cookies or browser session state.
How much does mobile app maintenance cost after launch?
Plan for roughly 20% of the original build cost per year. iOS ships a major version annually, and SDKs, payment libraries, and OS APIs change underneath you. An app without a maintenance owner degrades until an update breaks it, so scope upkeep and code ownership before you sign, not after.
Scoping a native iOS build and want the five questions asked properly? Book a free 30-min call →