People ask how long it takes to build an app because they need a date they can tell a partner, a board, or a customer. A single number, offered before anyone has named the user and the job, is a courtesy. It is not a plan. The honest answer is a range tied to a written scope, with the phases overlapped on purpose.
A focused v1 typically runs 3–6 months, depending on integrations, compliance, and how much design already exists. “Focused” is doing real work in that sentence. It means one primary user and one job they can finish, on a platform choice you have argued, with the store accounts and the legal basics in motion early. A marketplace, a multi-party payment split, or a large offline sync problem can run longer, and the useful time to say so is during discovery, while cutting is still cheap.
The phase ranges below are what we see on that kind of v1. They overlap. Adding the long end of every phase as if the team waited for a ceremonial handoff will produce a number past six months. That arithmetic describes a project that refused to overlap and refused to cut. For how to hold the cut, read MVP Planning for Software Products and From Design to Launch: A Phased Approach.
Discovery: two to four weeks
Discovery is the two to four weeks in which the brief becomes a scope. You spend time with the people who do the job today, you look at the systems the app must touch, and you write down what v1 includes and what it leaves out. A workshop that only produces enthusiasm has not finished.
You should leave with a short pack: the problem in a paragraph, the primary user, the in-list and the out-list, the integrations and which of them are read-only, the risks in plain language, a success check you can observe, and an estimate whose assumptions are visible. If a vendor API has no sandbox, if nobody can log into the Apple account, or if legal copy does not exist, those facts belong in the pack. They will own weeks later if you discover them during QA.
Two weeks is realistic when the decision makers are available and the job is already well understood inside the company. Four weeks is realistic when you need more than one kind of user interview, or when a compliance or security person has to react to the plan. Discovery that drags past a month is usually a sign that the company has not chosen the job, and more workshops will not choose it for you.
Design
Design for a focused v1 is often about three to six weeks, and it should overlap the end of discovery. The core path can be drawn while the last integration question is still open. Waiting for a perfect requirements document before anyone sketches a screen is how the calendar becomes sequential.
The output is a flow of the core job, the key screens, and the states people forget: empty, loading, error, and offline if offline is in scope. A clickable prototype of the primary path is enough for a v1 decision. A pixel-finished comp of every settings screen is how design eats the build.
Start the words early. Store screenshots, empty states, error text, and the privacy policy all need sentences a human wrote. Design that shows lorem ipsum in the error state is unfinished, because the error state is where users decide whether the app is trustworthy. If a brand system already exists, say so. Design moves faster when the argument is about the flow, and slower when every meeting reopens the logo.
Build
Engineering is the long middle. For a focused v1 it is often about eight to fourteen weeks, starting on the slices that are already decided while design continues on the rest. The team should demo working software on a steady cadence—weekly is a healthy default—against realistic data, not a slide of what next month will contain.
A sensible order is a vertical slice through the core job: sign-in, the record the user came to create or finish, the one integration that makes the job real, and the failure the user will actually hit. Admin dashboards, extra roles, and the second integration wait until that slice is dull and reliable. A build plan that starts with a framework tour and a settings screen is spending the best weeks on the edges.
Put the unglamorous machinery in before the last month: a build pipeline, a crash reporter, and a place to see logs. Teams that postpone “DevOps” until submission week spend the buffer on plumbing. Also decide native versus cross-platform during discovery, not in week ten. Swift and Kotlin mean two UI codebases. React Native or Flutter means a shared UI with native modules where the device demands them. Changing that decision mid-build is a restart, whatever the proposal called it.
QA
QA is about two to four weeks of hardening, overlapping the end of the build. It is not a single Friday. The device list should be the phones your users actually hold, including one older model, not only the newest flagship in the office. Cover the roles you promised, the slow network, and the case where the integration times out.
Store submission has its own test artifacts. You need screenshots at the required sizes, a description that matches the binary, a privacy policy URL that loads, and data-safety or nutrition-label answers taken from the SDK list in the app. Guessing those answers from memory is a common way to earn a rejection or, worse, a later policy problem.
Create a reviewer demo account and write the steps. A login wall with no credentials is a reliable way to stall the first review. If the app needs a specific setup—a sample order, a location permission, a feature flag—put that in the notes. QA includes the listing, because the listing is part of what the reviewer and the customer both see.
Store review
Plan a buffer of several days to about two weeks for the first submission, and keep a person available to answer questions. Apple often responds in a couple of days and sometimes asks for a change that resets the clock. Google is often faster and still rejects builds for data-safety mismatches, broken demo access, or policy issues in the listing. A first release on a new developer account is commonly slower than an update on an app that already has a history.
The buffer sits inside the project calendar. “Code complete” plus a hope that review will be instant is how launch week gets loud. If a rejection arrives, the same team that wrote the code should be the team that answers it. A handoff to a different vendor at submission is how a two-day question becomes a two-week archaeology project.
Ship from accounts your company owns. Enrollment, tax information, a D-U-N-S number where Apple requires one, and the legal entity name all take calendar time that is independent of engineering. Start that paperwork during discovery. Finding out in QA that nobody can accept the agreements is a self-inflicted delay, and it is one of the few delays a buyer can remove personally.
What a 3–6 month calendar looks like when the phases overlap
Here is an illustrative shape for a focused v1 on a shared codebase, with a couple of integrations and a brief the company can already explain. It is a picture of overlap, not a promise that your project will land on these week numbers.
Weeks 1 to 3 are discovery, inside the two-to-four-week band. Weeks 3 to 8 are design of the core path, while open questions close and engineering starts on the slices that are settled. Weeks 6 to 18 are build. Weeks 16 to 20 are QA, store assets, and the reviewer account, overlapping the tail of the build. Weeks 20 to 22 are submission and the buffer for questions. That is about five months. It sits in the middle of the 3–6 month range on purpose.
A thinner internal app on one platform, with the flow already decided and almost no integration work, can compress toward about three months, mostly by shortening the build. Native work on both platforms, a payment flow with splits, a serious offline conflict problem, or a vendor with no test environment can push past six months. Say that when the scope is still a document. Pretending the long project is a focused v1 wastes the first half of the budget finding out.
What extends the timeline
These are the extensions we plan for in the open, because each one is capable of adding weeks and some of them add months. None of them is a moral failing. All of them are scope.
• A second primary user in v1, with a different permission model. An admin console is often a second product.
• Payments, especially anything that splits money between parties or has to reconcile with an existing billing system.
• Offline use that must merge conflicts, as opposed to a cache that can throw the draft away.
• More than a couple of external systems, or one system whose API has no sandbox and whose vendor answers slowly.
• Compliance, accessibility obligations, or a customer's security review on a calendar you do not control.
• Brand, flows, and copy that are still undecided when engineering is scheduled to start.
• Stakeholders who see working software for the first time at the end, and then restart discovery in the QA window.
• Store enrollment, tax, banking, and a privacy policy that begin when the binary is ready.
• A change to the primary job after the prototype. That is a new project wearing the old project's name.
How to ship a smaller v1
The calendar moves when the scope moves. If the date is fixed, the cut list is the tool, and it should be written in discovery while everyone is still polite. A smaller v1 is still a product: a real user can finish a real job on a real device, and you can watch whether they do it again.
• One primary user, and one job they can complete without a staff member finishing it in another system.
• One platform when the audience truly lives there. Both stores when it does not, through a shared codebase if the brief allows, so you are not funding two UI teams to learn the same lesson.
• Rare cases handled by a person—a shared inbox, a simple internal screen—until volume proves the case is common.
• A read-only integration before a write-back. Reading a customer record is a smaller risk than creating one in a system your finance team trusts.
• One sign-in method that you can support. Extra social logins can follow if users actually ask.
• The one notification that changes what someone does next. Five notification types in v1 means five things to get wrong.
• Manual reporting for the first month. A chart can wait until you know which number anyone checks.
The discipline is to ship the core loop and instrument it, then decide the second release from use, not from the leftover brainstorm. Our San Diego buyer's guide to choosing a mobile app company covers how to tell whether a studio will protect that cut or sell you the brainstorm.
How to read a date in a proposal
Ask which weeks belong to discovery, design, build, QA, and review. Ask what is excluded. Ask what happens to the date when a named integration slips or when review asks for a change. A date with no excluded list is a hope with a font.
Ask whether you will see a working slice in the first month of the build, or a reveal at the end. Early software is how you find out the job was misunderstood while there is still time to change the out-list. A big reveal is how you find out in the week you meant to submit.
Compare calendars only after the scopes match. A three-month quote and a six-month quote are allowed to differ because one of them left out Android, payments, or the admin role. Make both firms restate v1 in a page. Then the dates mean something.
Plan the calendar against a real v1
Nightcoders designs and builds mobile products with senior in-house engineers from downtown San Diego. A focused v1 typically runs 3–6 months, and we would rather show you the cut that makes that true than stretch the phrase to cover a larger product. Read mobile app development in San Diego, the full mobile app development practice, and the process we use to phase the work.
Contact Nightcoders with the user, the job, and any date you are already committed to. We will tell you whether that date fits a focused v1, what would have to come out to protect it, and when the honest answer is a longer program.
Ship mobile product with clarity
For mobile app development in San Diego and beyond, platform choice and store readiness matter as much as UI polish. Browse State National and other case studies for narrative depth.
When you are ready to scope v1, reach out with audience, constraints, and any existing systems we would integrate with.