How We Scope an iOS Project in Two Weeks (Without Lying)

Most studio engagements go wrong before a single line of code is written. The scope was never locked. The timeline was optimistic. The budget was an estimate built on assumptions that never got challenged. Two months in, everyone is unhappy and pointing at the original agreement that was too vague to enforce.

We built our discovery process to prevent that. Two weeks, one structured sequence of questions and decisions, one written document at the end. Here's exactly what we do.

Why Two Weeks Is the Right Amount of Time

One week isn't enough to get the real requirements — the first meeting is always the surface level. The actual constraints (what the user can't lose, what the backend can't support, what the deadline is really about) come out in the second conversation.

Three weeks is too long for a discovery phase. If you can't understand the scope of a product in two weeks, that's usually a sign the product itself isn't defined — and no amount of discovery will fix that. It needs to be simplified first.

The Actual Sequence

• Kickoff call — understand the user, not the feature list

  We spend the first hour on the user. Who uses this app, in what context, under what conditions. A baby feeding tracker used at 3am by a sleep-deprived parent has completely different UI constraints than a CS performance tracker used by someone on a desktop. Before we talk features, we need to understand the person holding the phone.

• Map the core flows — maximum three

  Every app has 1–3 things it needs to do well. Everything else is secondary. We force the conversation to identify what those are: if a user could only do one thing in the first 60 seconds, what would it be? What's the action they'll do 10 times a day? What's the action they do once but that has to be right? The three core flows become the product backbone.

• Write the feature list — then cut it in half

  We write down every feature that was mentioned, requested, or implied. Then we go through it item by item: is this in v1 or v2? Most features end up in v2. The v1 list should be embarrassingly small. The fastest way to miss a deadline is to start building everything that seemed like a good idea in week one.

• Define the data model and backend architecture

  This is where most studios skip and pay for it later. What data does the app store? Where does it live? Who owns it? Does it sync across devices? What happens offline? Firebase, custom Node backend, or something existing? These decisions have major cost implications and need to be made before writing a line of code.

• Build the sequence — not a Gantt chart, a build order

  Which screen gets built first? Which integration gets done in week three vs. week eight? The build sequence is a prioritized order of what ships when. It determines what the client sees in TestFlight in week three and what the engineers work on first. Without a sequence, everyone starts working on what's interesting, not what's critical.

• Write the scope document — one page, no more

  Everything from the discovery goes into a single document: the three core flows, the feature list (v1 explicit, v2 explicit), the data model, the build sequence, and the budget range. This is the thing we sign. If a feature isn't in the document, it doesn't get built without a change order.

What the Budget Range Means

We don't give a single number. We give a range — for example, €55k–€80k — with a clear explanation of what would push it toward the bottom versus the top.

The lower bound assumes: backend is Firebase (fast to integrate), no third-party payment system, standard App Store review (no medical/health category complications), no major scope changes after week four.

The upper bound assumes: one or more of those things goes wrong. Third-party API is poorly documented. App Review rejects twice and requires architectural changes. A key feature turns out to be 3x harder than it looked.

The One Thing That Kills Scoping

The client who can't say no in discovery.

Every feature sounds reasonable in isolation. The social sharing component — sure. The onboarding quiz — makes sense. The admin dashboard — useful later. But a v1 with fifteen features is a v1 that ships in six months instead of three, and it's a v1 where nothing is done well because everything is done partially.

The hardest part of discovery isn't gathering requirements. It's helping a founder understand that the path to a good v2 is a ruthlessly small v1. Every feature you don't build in v1 is a feature you get to build properly, informed by what actual users do, in v2.

What You Get at the End of Discovery

• A written scope document (one page, signed by both sides)
• The three core user flows in plain language
• A confirmed feature list for v1 (and an explicit v2 list)
• The data model and backend architecture decision
• A build sequence that tells you what you'll see in TestFlight and when
• A budget range with a clear explanation of the variables
• A timeline with the first TestFlight build date and the expected App Store submission date

That's it. No 40-slide deck. No speculative wireframes. A document you can hold us to.