--- slug: vibe-coded-app-timeline title: "From Idea to App Store: A Realistic Timeline for Vibe-Coded Apps" excerpt: "Most vibe-coded apps don't stall because the building is hard. They stall because nobody planned a timeline. Here's a week-by-week breakdown that actually works." primaryKeyword: "vibe coded app timeline" publishedAt: 2026-05-02 readingTimeMin: 8 author: "Robert Boylan" tags: - vibe-coding - shipping - indie-dev - app-launch - app-planning --- There's a particular flavor of failure you'll recognise if you've spent any time in indie dev circles. Someone posts in a Discord: "I've been building my app for six weeks and I'm almost done." Three months later, same person, same message. Another three months: "just a few more features and I'll launch." The app never ships. Not because the building got too hard. Because they never had a plan for what "done" looked like or when. The vibe-coded app timeline problem is real, and it's almost never about the tools. Lovable, Bolt.new, Cursor, Claude Code, v0: all of them can get you to a working prototype faster than anyone could have managed five years ago. But fast-to-prototype and shipped-and-used are two very different destinations, and the road between them needs a map. This is that map. ## Day 0: the idea is not the plan You have the idea. Good. Write it down. Not in a way that satisfies you, in a way that would satisfy a stranger who has never heard of you. This means: what does it do, who uses it, and what does the very first screen look like? That last one matters more than it sounds. If you can't describe the first thing a user sees when they open your app, you don't have a product yet. You have a concept. Day 0 is also when you make the web-versus-native call. Most vibe-coded apps should start on the web. Full stop. The App Store review process (Apple's review where a human, and increasingly a bot, approves your app before it goes live for download) typically takes one to three days but can stretch to a week or longer if something flags. The Play Store (Google's Android equivalent) tends to move faster but has its own review queue. Neither of these timelines are in your control, and they're the wrong thing to be thinking about on day zero. Build a web app first. Ship it. If people use it on their phones, build a native version. That's the right order. ## Days 1 and 2: write the spec before you open any tool This is the step most people skip, and it's the reason most vibe-coded apps stall. Spending two days on a spec sounds like delay. It isn't. It's insurance. The spec is your contract with yourself: what you're building, what you're explicitly not building in v1, and what the core user journey looks like from signup to their first moment of value. The format doesn't need to be fancy. Call it [a PRD, which is just a one-page description of what your app does before any code gets written](/what-is-a-prd). Feature list, prioritised. Main screens, described in plain English. What the AI tool you're about to use needs to know. Every hour you spend talking a vague prompt into a specific app is an hour you could have spent building. [Vibe coding without planning isn't faster, it just feels faster at the start](/blog/vibe-coding-why-planning-matters). The cost shows up later, on prompt forty, when you're trying to explain to Lovable that you wanted the sidebar on the left the whole time. Two days on the plan is not lost time. It's what determines whether week three feels like momentum or mush. ## Days 3 to 7: build v1, scope is the whole game You have the spec. Now you build. This week has one rule: do not add features. The spec says what's in v1. If you think of something new, write it down in a separate list. Do not add it now. This sounds obvious and is apparently very hard to do in practice. By day 7 you should have something that does the core thing. One or two screens. The main action works. You can sign up, do the thing the app is for, and sign out. Nothing is polished. That's correct. Where you land on the tool spectrum matters here. A non-technical builder using Lovable or Bolt.new will likely have a working prototype in two to three days and spend the rest of the week tuning. Someone using Cursor or Claude Code who knows their way around a codebase might move faster on complex logic but slower on UI. Neither is wrong. [The right AI coding tool depends on how much code you want to touch](/blog/which-ai-coding-tool-should-you-use). What you should have at the end of day 7: something you can share a link to, even if it's embarrassing. ## Week 2: close friends testing, and the "works for me" problem Here is where most vibe-coded app timelines fall apart. Not because of bugs. Because of a specific failure of imagination called "works for me." Your app works for you. You built it. You know where everything is. You know to click the thing in the corner before you do the other thing. You know that the blank state means "add one first." You know all of this without knowing you know it. Your close friends do not. Week 2 is for finding out what you took for granted. Share the app with three to five people who weren't involved in building it. Not for feedback on the idea. For watching what they do when you say "try using it" and then you say nothing. The spots where they pause, go quiet, or say "wait, where do I..." are your bugs. Not code bugs. Experience bugs. And they are almost always fixable in a day or two once you can see them. TestFlight is worth knowing at this stage. It's Apple's tool for sharing pre-release iOS apps with testers before App Store submission, a bit like a private link for your app. If you've built a web app you don't need it yet. If you've built for iOS and want real testers, this is how you get the app to them. The goal at the end of week 2: a list of things to fix before you open the doors publicly, and a rough sense of whether the core thing actually resonates or needs rethinking. ## Week 3: polish and public launch Polish does not mean finished. It means: good enough that a stranger who doesn't owe you anything will give it a fair try. That usually means: the happy path works without confusion, error messages make sense, and you haven't left any "lorem ipsum" in the UI. It also means you've picked a home page that explains what the thing does in one sentence. Not two. One. For the launch itself, the indie dev pattern that works is soft launch first. Product Hunt (a site where people post new products and the community votes on them) is the most common venue, but it works best when you already have a handful of real users. Drop a link in two or three communities where your target user hangs out. Post once where you have any audience at all. Don't wait for the App Store to launch publicly if you have a web version. The review queue is not in your control. Launch the web version, drive people there, and submit the mobile version in parallel. If the App Store approves it while you're already live, great. If it takes two weeks, you haven't lost anything. Week 3 is also when you find out whether the spec you wrote on days 1 and 2 held up. It usually mostly does, with a couple of surprises. That's normal. ## Weeks 4 through 8: iterate on real feedback, not imagined feedback Real users will surprise you. They'll use the app for something you didn't plan. They'll skip the feature you thought was the whole point. They'll write in asking for the thing you put on the "v2 maybe" list. The vibe-coded app timeline for weeks 4 to 8 is not "build more stuff." It's "understand what the people who actually showed up are trying to do." One useful change that makes three existing users happier is worth more than one new feature that might attract hypothetical new ones. This is also when the [implementation plan](/blog/export-implementation-plan) you made for v1 gets retired and you write a new one for v2. Because you know things now you didn't know before, and building v2 off an outdated spec is the same mistake as having no spec at all. If the app is getting real engagement, this is when mobile starts making sense. People visiting the web version on their phones repeatedly is your signal to build native. The App Store and Play Store both want a polished, stable product before they approve it, so don't rush that submission. If engagement is low: don't add features. Go talk to the people who did try it. That conversation is worth more than a week of building. ## Most failures come from having no timeline at all Not an unrealistic timeline. No timeline. When you don't have a timeline, you don't have a stopping condition for "planning" or a starting condition for "shipping." Planning becomes perpetual. Building becomes its own reward. Launching gets postponed until it feels ready, and it never quite does. The specific weeks above are guidelines, not gospel. Maybe your v1 takes ten days, or your close-friends test stretches to three because you have a day job. That's fine. What matters is that each phase has an end, and the end has a date. The apps that stall in weeks 2 and 3 usually fail for the same reason: nobody defined what "ready to share" meant. So they keep polishing forever, or they share it and get confused feedback with no framework for acting on it. Planning the timeline is thinking, not paperwork. The thinking you do before you open any tool is what determines whether you actually ship. Draftlytic is built for exactly this part: turn the idea into a prioritised spec in ten minutes, then hand it straight to Lovable, Cursor, or whatever you're building in. It's the kind of structured output that keeps AI tools honest instead of inventive. [See how it works](/blog/how-to-use-draftlytic). Build the thing. Ship it on a date you decided in advance. Build the next version based on what you learn. That's the whole pattern.