LA App Development Timeline:What 12 Weeks Actually Buys

"We have twelve weeks until the investor meeting. iPhone, Android, an admin panel and payments. Doable?"

That request is a composite, not a quote from one client, but it's the shape a timeline question tends to arrive in: a fixed date, a long list, and the hope that the list fits the date. Picture it on a whiteboard with a box drawn around the words "12 weeks".

My answer to that request is no. Not "no, it's impossible", but no, not all four, not launched in both stores, not by that date. Then we spent an hour working out which part of the list the twelve weeks could actually buy.

This article is that hour, written down. I'll use only three kinds of numbers: the process durations and price bands we publish on our own service pages, the review and account rules Apple and Google publish, and arithmetic I do in front of you. Everything else, I leave out and say why.

To be clear about who's writing: I run Frenchy Digital, a senior-led app and AI agency in Los Angeles. I've got a stake in how you plan your build. So I'll show you where our own numbers say "this doesn't fit", including for the work we sell.

The wrong model goes like this. Twelve weeks is a quantity of development, a bucket of effort. If the bucket is big enough, you pour features in until it's full, and whatever fits, ships.

It's a sensible model. It's also the reason most deadlines slip.

Twelve weeks is a calendar, not a bucket. Some of the work inside it runs in sequence and can't be sped up by adding people. Discovery has to end before design is final. Design has to settle before the expensive screens are built. The app stores run clocks you don't control at all: a 14-day testing window, a review queue, a business identity check.

There's a concept from project management that captures this better than any metaphor I could invent: the critical path. It's the longest chain of tasks that each depend on the one before. Whatever sits on that chain sets your finish date. Work that sits off it can run in parallel and doesn't move the date at all.

Think of cooking a holiday dinner. The turkey takes four hours no matter how many cousins are in the kitchen. Extra cousins make the side dishes faster. They don't make the turkey faster. If you want dinner at six, the only question that matters is when the turkey goes in.

Therefore the useful question isn't "how many features fit in 12 weeks?" It's "what's on the critical path, how long is it, and what's left over?" For an app, the turkey is usually some mix of decisions, core screens and store approval. The side dishes are everything else.

The rest of this article walks that critical path for three kinds of build, using durations we've published, and then shows the store clock that sits at the end of any native app.

Start with hours, because that's where most budget conversations start, even when the contract ends up fixed price.

Twelve weeks at 40 hours a week is 480 hours for one person working full time on your project. Our senior rate runs $150 to $225 an hour. So one senior person for the whole twelve weeks is about $72,000 at the low end of the band and about $108,000 at the top.

Now hold those numbers next to our published MVP bands: $30,000 to $50,000 for the MVP Launch tier and $55,000 to $75,000 or more for MVP Plus (from our MVP development page). The MVP Launch band is less than one senior person for twelve weeks. That's not a discount; it's a different shape of work.

Why does the price come in under the full calendar? Because an MVP isn't twelve weeks of continuous coding. It's a short discovery, a prototype, a build sprint and a launch, and the published tier finishes in 6 to 10 weeks. Nobody is billing for weeks eleven and twelve because they aren't in the plan.

What about after launch? The spare weeks aren't the end of spending. Our retainers run $2,500 to $9,500 a month for ongoing work. At $150 to $225 an hour, that's roughly 11 to 63 hours a month of senior time, depending on where in both bands you land. Put that next to the build budget when you plan the year, not only the twelve weeks.

Let's check that division, since I told you I would. $2,500 divided by $225 is about 11 hours. $9,500 divided by $150 is about 63 hours. Neither end is a quote; they're the edges of what the two published bands allow.

The downside of reading hours this way: it tempts people to fill the whole 480 hours. If the MVP fits in eight weeks, the pressure is to spend the other four adding features. That's usually the wrong call, and I'll explain why in the risk section.

This is a worked scenario, not a client story. Suppose a founder wants a web app that customers sign into, where they do one core job, and where the team manages users from an admin panel. No native app yet. Payments later.

Here are the phases we publish for an MVP, and what they add up to.

Let's do the addition out loud. At the short end, 3 days plus 1 week plus 3 weeks plus 3 days is 4 weeks and 6 working days, a little over 5 weeks. At the long end, 5 days plus 2 weeks plus 6 weeks plus 5 days is exactly 10 weeks.

That matches the MVP Launch tier we publish: 6 to 10 weeks for $30,000 to $50,000, covering a working product with 5 to 7 core features, user authentication and onboarding, a database with validation, an admin panel, analytics and production deployment on a custom domain, with 30 days of post-launch support.

So in a 12-week window, the MVP Launch tier leaves somewhere between 2 and 6 weeks of calendar unspent (12 minus 10, and 12 minus 6). That's the scenario I like best, bc those spare weeks absorb the things that always happen: a stakeholder on vacation, a copy rewrite, a pivot in week three when the prototype test goes badly.

One caveat I want on the record. These are web MVPs built in React and TypeScript. They run on a phone browser and can be installable as a PWA at the higher tier, but they aren't native App Store apps. That distinction is the whole next section.

Second scenario, also illustrative. A Los Angeles services business wants a new marketing site with 10 to 20 pages, a blog, a CRM integration and two languages.

Our website development page publishes four phases: discovery and information architecture in 1 to 2 weeks, UI and UX design in 2 to 3 weeks, development and CMS integration in 3 to 6 weeks, and testing, SEO and launch in 1 to 2 weeks.

Add them up: 1 plus 2 plus 3 plus 1 is 7 weeks at the short end, and 2 plus 3 plus 6 plus 2 is 13 weeks at the long end.

You might spot that the phase sum (7 to 13 weeks) is longer than the business tier (4 to 6 weeks). That's because the phase ranges are written to cover every tier. A five-page site doesn't need two weeks of information architecture, and the tier timeline reflects that. I'd rather point it out than have you find it.

Our scenario business sits in the corporate tier: 6 to 10 weeks, $30,000 to $60,000, which includes a design system, structured data, a blog with categories and search, 2 to 3 languages and CRM and email platform integration. It fits in 12 weeks.

What eats the spare weeks on websites isn't code, in my experience. It's content. Photos that haven't been shot, bios that haven't been approved, a translation that arrives in week eleven. A website with finished copy on day one is a very different project from one where the copy is "coming".

For a real example of the kind of web work we do here, our Janvier LA case studycovers a Shopify e-commerce build for engagement rings and custom jewelry, with customization features and appointment booking. To be clear, it's a web and e-commerce project, not a native app, and the case study doesn't state a timeline, so I'm not using it as proof of any duration.

If you're comparing web agencies rather than app studios, the sibling piece ranking Los Angeles web development companiesscores firms on things you can check, including whether they publish pricing at all.

Third scenario. The founder wants a native iPhone app in Swift, in the App Store, in 12 weeks.

Here's where our own numbers say no. Our iOS app development pagepublishes discovery and planning in 2 to 3 weeks, UI, UX and development in 8 to 16 weeks, testing and QA in 2 to 3 weeks, and App Store launch in 1 to 2 weeks.

At the very shortest, that's 13 weeks. One week over, before anything goes wrong. At the longest, 24 weeks, twice the window.

The iOS MVP package we publish says the same thing a different way: $50,000 to $100,000 for a single platform with 3 to 5 core features, basic design, API integration and App Store submission, over 3 to 4 months. Three months is about 13 weeks. Four is about 17.

Could a very small native app squeeze into 12 weeks? Sometimes, if discovery is already done, the design is locked, and there's no backend to build. But I won't promise it, and you should be wary of anyone who does without a written phase plan that adds up.

What I'd suggest instead, when the date is fixed: run discovery before the clock starts, or ship the web MVP in 12 weeks and start the native app after. Our discovery phase guide walks through what that paid scoping step costs ($9,000 to $22,000 over 2 to 4 weeks with us) and why taking it off the critical path is often the cheapest time you can buy.

What about cross-platform tools, one codebase for iPhone and Android? They can shorten the path to two stores compared with two separate native builds. They don't remove the store clock, the D-U-N-S wait or the Google testing window, and they bring their own tradeoffs in platform features and upgrades. I'm not going to put a week count on them here, bc we don't publish one, and a number I made up would be exactly the kind of figure this article refuses.

There's also a quieter reason native takes longer that has nothing to do with Swift. Every screen has to be checked on real devices, across iPhone sizes and iOS versions. Our published testing phase (2 to 3 weeks) includes device testing, version compatibility and a TestFlight beta. That's the part people try to cut when the date gets close, and it's the part that decides whether review goes smoothly.

If you're set on native and want to compare local studios, the round one ranking of Los Angeles app development companies is a reasonable place to start your shortlist.

Back to the whiteboard. iPhone, Android, an admin panel and payments in 12 weeks. Let's price and time it from what we publish, and see where it breaks.

The iOS app alone already overshoots 12 weeks on our own phases. Android adds its own build and, if you open a new personal Google Play account, a mandatory 14-day closed test before production. Then there's review on both sides.

So the full whiteboard doesn't fit. Not bc anyone is slow, but bc the critical path is longer than the calendar.

Here's what does fit, in rough order of how often I recommend it:

• A web MVP with the admin panel and payments (MVP Plus scope) inside 10 to 14 weeks, accepting that 14 would miss the date. Native apps follow once real users prove the product.
• A web MVP at MVP Launch scope in 6 to 10 weeks, plus a clickable native prototype for the investor meeting, clearly labelled as a prototype.
• One native platform started in the 12 weeks with a TestFlight beta by the date, not a public App Store launch.
• A cross-platform build scoped tightly enough to fit, which is a separate conversation with its own tradeoffs and not something I'll pretend is free.

For the whiteboard scenario, I'd pick the second option. A clickable prototype plus a working web product is a pitch a founder can stand behind. "Half of four things" isn't.

Any native app ends at a review queue you don't control. The good news is that both stores publish their rules. The bad news is that the rules are easy to learn in week eleven.

After launch, updates have a clock of their own. Apple's phased release spreads an update over 7 days to users with automatic updates (1%, 2%, 5%, 10%, 20%, 50%, then 100%), and lets you pause for up to 30 days in total (Apple, phased release). That's a good tool for the first update after a 12-week sprint, when bugs are most likely.

The slowest part of an app launch is sometimes the paperwork, and it's the part people start last.

If you publish as a company, both stores want proof the company exists. Apple requires organizations, other than government entities, to have a D-U-N-S number, displays your legal entity name as the seller (no DBAs or trade names), wants a public, functional website on your organization's domain and a work email on that domain, and charges 99 USD per membership year (Apple Developer Program enrollment).

Google Play charges a US$25 one-time registration fee and may ask for a government ID and a credit card under your legal name (Google Play, registration). For organization accounts it requires a D-U-N-S number, except for government organizations (Google Play, required information).

Now the fun part. How long does a D-U-N-S number take? Three primary sources give three answers:

Sources: Apple, Dun and Bradstreet, Google Play.

I don't know which one you'll get, and neither does anyone else. So plan for the slow one. Thirty business days is six calendar weeks. If you start it in week eight, it finishes after your deadline. If you start it on day one, it's done by week six and nobody thinks about it again.

One more thing that matters for ownership. Open these accounts in your company's name, not your agency's. We transfer full source code and IP to our clients, but the store account is a separate asset, and it's much easier to own from the start than to move later.

There's a tradeoff hidden in the table, too. A personal Google Play account skips the D-U-N-S wait but triggers the 12 testers for 14 days rule. An organization account skips that rule but needs the D-U-N-S number. Neither is free; pick the one whose clock you can start earlier.

Two pieces of work show up in almost no pitch deck, and both land on the critical path of a native launch: account deletion and a real testing track.

Start with deletion. Apple's support page says that since June 30, 2022, apps that support account creation must let users start deleting their account inside the app (Apple, offering account deletion). The same page says offering only to deactivate or disable the account isn't enough, and that deletion should cover the account record and the personal data tied to it.

That sounds like a button. It isn't. It's a settings screen, a confirmation step, a backend job that finds every table holding that person's data, and a decision about what happens to things they shared with others. If the app has subscriptions, Apple also expects you to tell people that billing continues until they cancel.

Think of it like moving out of an apartment. Handing back the key takes a minute. Clearing every cupboard, forwarding the mail and closing the utilities takes a weekend. Scope the weekend.

The second one is testing. Google Play offers three tracks: an internal test for up to 100 testers, where a new build reaches testers within minutes, a closed test by email list or Google Group, and an open test anyone can join (Google Play, testing tracks). Google recommends starting internal and then widening to a small closed group.

Why does that matter for a 12-week plan? Because the 12 testers for 14 days rule is counted on a closed test, and 12 people who stay opted in for two weeks don't appear on their own. Somebody has to recruit them, send the invites and chase the ones who drop out. I'd line up closer to 20 names than 12, bc the page asks for testers opted in continuously, and people drop out of betas for ordinary reasons.

The honest downside of both: neither makes the product better in a demo. They cost real hours and produce nothing an investor will notice. That's exactly why they get cut, and exactly why they turn into a surprise in week eleven.

Here's how I'd lay out 12 weeks for the web MVP scenario, with the native and store items that should start early if a native app follows. It's a scenario plan, built from our published phase durations, not a promise.

Notice where the buffer lives. It's at the end, and it's protected. The moment a new feature request arrives, it goes on a list for after launch, not into weeks eleven and twelve.

Why does the paperwork track start in week one when the store work doesn't matter until week ten? Because of the critical path again. The D-U-N-S wait is up to about six weeks by the slowest published figure. Starting it in week one puts it off the critical path entirely. Starting it in week seven puts it right on top.

Weekly demos matter more than any tool. Once a week, you see the working product and make the decisions that are blocking it. A decision that waits a week costs a week. On a 12-week calendar, three of those is a quarter of your buffer gone.

If you're in Los Angeles, the in-person part of this is easy to do well: a discovery workshop around one table, and major reviews in the same room. Day to day, remote works fine. Our Los Angeles app and web development page has more on how we split that.

Let me argue against my own plan, bc it has real failure modes.

Why is the plan still worth it with those risks? Because the worst case is bounded. If the buffer gets eaten, you launch in week twelve with a smaller product. If the date slips by two weeks, you've still shipped a working, owned product at a published price. The alternative, the full whiteboard, risks launching nothing at all by the date, which is the one outcome an investor meeting can't absorb.

And a note on what we promise: nothing about outcomes. We publish price bands and timelines, send a fixed-price phased proposal within 5 business days, and back launches with a 30-day post-launch warranty. That's the extent of it.

When you compare proposals, the timeline is where the optimism hides. These are the red flags I'd look for, in any agency's quote, ours included.

• A single number of weeks with no phases underneath it. If you can't add it up, you can't check it.
• Native iOS and Android, both launched to the stores, in a window shorter than the vendor's own published iOS timeline.
• No mention of App Review, TestFlight, the Google Play closed testing rule or developer account setup.
• Store accounts opened in the agency's name rather than yours.
• No written change process, so every new idea silently lands inside the same deadline.
• A promise of a launch date rather than a plan for one. Nobody controls the review queue.

None of these means the vendor is dishonest. Most of the time it means the proposal was written to win the deal, and the hard parts were left for later. Your job is to pull later forward, onto the page, before you sign.

A good test: ask the vendor to walk you through week one. If the answer includes the D-U-N-S request, the developer accounts and the discovery workshop, they've done this before. If it starts with coding, ask what happens to the paperwork.

Search for "how long does it take to build an app" and you'll find confident averages: four to six months, three to nine months, a specific number of weeks for a "simple" app. I looked for where those come from.

I couldn't find a primary dataset behind any of them. The pages repeating them don't publish a sample size, a method, or even a definition of when an app counts as done. Most are agency marketing pages, and the ranges conveniently match what that agency sells. So I don't print them, and I'd ask your vendor where theirs come from.

The same goes for an "average cost of an app in Los Angeles". None traced to a primary source. That's why every price in this article is either our own published band or arithmetic from our rate.

A few other limits you should know about:

• Our published timelines are ranges for scoped work, not guarantees. Your project's written phase plan is what counts.
• Apple's 90% within 24 hours is Apple's own stated average. I have no independent measurement of review times.
• Google does not publish a typical review time in hours, only that some reviews take up to 7 days or longer.
• The three D-U-N-S timelines disagree, and I can't tell you which one applies to your company.
• We don't publish a separate Android price band, so I haven't invented one.
• Store rules change. I checked every store fact here on September 30, 2026; recheck before you plan.

Our own MVP page also carries a couple of marketing claims I won't repeat here, bc I couldn't tie them to a record I can show you. If a number in this article isn't linked or labelled as arithmetic, treat that as a bug and tell me.

If you have a date and a list, here are three things to do before you sign anything.

• Request a D-U-N-S number and open your Apple and Google developer accounts in your company's name today, even if the native app is months away.
• Write your list in order of the riskiest assumption first, and draw a line at what a 6 to 10 week web MVP could hold. Everything below the line is version two.
• Ask every agency you're comparing for a written phase plan with durations that add up, and do the addition yourself.

If you want us to be one of the plans you compare, our MVP build process (linked above) lays out each phase, or book a call at calendly.com/frenchydigital/discovery-call.

The turkey goes in first.