The 14-day app launch playbook for Shopify brands

We get the same question on every Appolar kickoff call: "How fast can we actually launch?" The honest answer is two to three weeks if your team can move and your developer accounts are already set up. The optimistic case study answer of "one week" is real but unusual; it requires every dependency to be ready before kickoff. The pessimistic answer of "six weeks" is what happens when assets, accounts, and approvals slip in the same project.

This piece is the actual sequence we run, day by day, when a brand wants to ship in two weeks. Read it as a checklist, not a story. The order matters more than the words.

Days 1–3: configuration and brand assets

The first three days are about getting the right inputs into the right hands. The platform team — Appolar in our case, but the same principle applies to any vendor — needs three things: developer accounts, brand assets, and a Shopify install. None of these are exotic, but missing any of them stalls the project.

Developer accounts come first. Apple Developer ($99/year) and Google Play ($25 one-time, paid directly to Google). If you do not already have these, start the Apple application on day one because it can take 24–72 hours to clear identity verification. Google Play is faster but still needs a real human to set up a payments profile.

Brand assets are the second blocker. You need a square app icon (1024x1024), a wordmark or logo for splash screens, a color palette, and access to a font (Google Fonts works; custom uploads do not, for legal-licensing reasons). The brands that ship fast already have these in their brand guidelines folder. The brands that stall spend day two and three sourcing assets from a designer who is on vacation.

Days 4–7: configure the builder and stand up the screens

With assets in hand, days four through seven are about configuring the app. The merchant works in the Appolar builder inside Shopify admin, picking a starter preset, swapping in their colors and fonts, and arranging the home, product, cart, and account screens.

This is where the builder model earns its keep. A merchant who knows their store can configure the screens in two or three focused sessions of an hour each. The screens that take longest are the home screen (because it has the most blocks) and the product detail page (because it has the most variant interactions to think through). Cart, checkout, account, search, and category browse usually look right with the default block sequence and just need theme tokens applied.

Days 8–11: App Store optimization and launch prep

The app binary is ready by day seven. Days eight through eleven are about the listing — App Store and Play Store — and the install promotion plan. This is the work that determines whether your app shows up in search and whether the buyers who see the listing actually install.

For the listing itself: ten screenshots per platform (or videos, on iOS), a 30-character title, a 170-character subtitle, a longer description, and the right keyword list. The keyword list matters disproportionately on iOS — get it wrong and your app is unfindable for the categories that should be sending you free installs.

For the install promotion plan: at minimum a mobile-web banner pointing to install, an email campaign timed for launch week, and a first-order discount gated on install. Each of these takes a day to set up cleanly. Do them now, while the app is in review, so they go live on day fourteen with the listing.

Days 12–14: submission, approval, and launch

Day twelve is submission to both App Store and Play Store. Google Play approval is fast and usually clears the same day or next day. Apple is the variable. The typical review window is 24–48 hours, but a 5% chance of a rejection on first submission is real for any new app, and a rejection can add three to five days.

Rejections are usually mundane: a missing privacy policy link, a screenshot that does not match the app, an unclear app description, or — increasingly — a webview-detection trigger if the platform has too much webview content. We handle the resubmission, but the brand needs to be reachable to confirm any copy changes.

Day fourteen, in the happy case, is launch. The app is live in both stores. The mobile-web banners flip on. The email goes out. The first push to early installers fires. From this point the install acquisition flywheel takes over, and the build phase of the project is officially done.

“A two-week launch is not heroic. It is well-sequenced work, done in the right order, with no parallel dependencies.”— Appolar launch playbook

What breaks this schedule

Three things, in our experience. First, missing developer accounts on day one. Second, indecisive brand approvals — particularly on the home-screen layout, which a brand can iterate on indefinitely if no one calls "ship." Third, App Store rejection on the first submission, which adds three to five days that no amount of planning can compress.

If you want the two-week timeline, the discipline is to pre-resolve those three failure modes. Get the developer accounts in motion before kickoff. Time-box the home-screen configuration to two sessions. Trust the platform team's suggestions on listing copy and screenshots, because they know what passes review faster than the people writing it for the first time.

After day 14, the real work starts

The launch is not the destination; it is the starting line. The first ninety days after launch are when the install acquisition strategy proves itself or does not. If you arrive at day fourteen with no install promotion plan, the app is live but invisible. If you arrive at day fourteen with the plan running, you will see your first thousand installs in week two and a meaningful cohort by month three.

The brands that succeed at launch are not the ones who built the prettiest app. They are the ones who treated days 8–11 as seriously as days 4–7. The promotion plan is the product. The app is just the vehicle.