This is a Founder Story: a real build, reconstructed from a founder's actual Denovo workspace with their permission. The founder and their product have been anonymized. What's left is the part that matters if you want to do this yourself: the exact sequence a non-engineer followed to take one idea from a single prompt to Google Play and the Apple App Store, and the integrations that made each step work.
Late one evening in March 2026, a founder typed their startup idea into Denovo. It was a consumer app, described in plain language — not a word about technology in it.
Roughly nine weeks later, that idea was a real product on both Google Play and the Apple App Store, with a paid subscription and reviews from strangers.
They didn't write the code themselves. But they shipped like an engineer: one problem at a time, pasting every error and every store rejection back into the workspace until it was gone. Here is the step-by-step path, so you can copy it.
Step 1: Start with the idea, not the tech stack
The first prompt wasn't "build me an iOS app." It described a human problem the founder wanted to solve. Denovo turned that into a validated concept, a scorecard, and a working web MVP they could click around the same week.
That order matters for everything that follows: both app stores ended up shipping the same web app that was built first. Get the product working in a browser before you think about app stores at all.
Step 2: Own your domain on day one
The day after the first prompt, the app was already live on its own domain. The founder bought a .app domain on GoDaddy and connected it to the Denovo MVP.
This step looks cosmetic, but it isn't — a real domain is a hard requirement later. Google Play's review process checks that your privacy policy and terms pages are publicly reachable, and Apple checks your support URL. All of those live on your domain.
Step 3: Make the web app installable (the PWA layer)
In early April, with a Google Play developer account activated, the work shifted to making the web app behave like an app. The workspace sent build instructions like this one:
"Add a complete PWA web app manifest to the app. This is CRITICAL for Google Play Store submission via PWABuilder/TWA."
The first PWABuilder audit scored the app 19 out of 45. A follow-up build request — full manifest fields, icons, screenshots, shortcuts, offline support — pushed it past 40. If you're doing this yourself: run your URL through PWABuilder, treat the score like a test suite, and fix what it flags before you package anything.
Step 4: Package for Google Play with a wrapper
For Android, the app didn't need to be rewritten as a native app at all. The web app was packaged with Median, a wrapper service that produces a ready-to-upload Android App Bundle around your live URL. Total new code written for Android: essentially zero.
The lesson: Android first. The wrapper route is fast, the review is more mechanical than Apple's, and everything you fix for Google Play (legal pages, privacy, mobile responsiveness) counts toward your Apple submission later.
Step 5: Survive Google Play review
Two rejections stood between the upload and the launch, and both were fixed in hours, not weeks.
Rejection 1 — permissions need a privacy policy. The uploaded bundle used READ_PHONE_STATE, and Google demanded a privacy policy. The founder pasted the error into the workspace:
"Your APK or Android App Bundle is using permissions that require a privacy policy: (android.permission.READ_PHONE_STATE)"
Minutes later a build request went out for a complete /privacy page under the founder's registered company name.
Rejection 2 — the legal pages must actually work. A later review failed because the linked pages didn't render. The fix instruction was blunt:
"CRITICAL FIX — Google Play rejected us because legal pages don't work. Make sure ALL of these pages are real, accessible, fully rendered routes with actual legal content"
One month after the first prompt, the app was live on Google Play — and in the same breath, the same workspace produced the launch marketing: an Instagram carousel, a Reddit ad, a Facebook launch post, and a Google ad for the Play Store listing.
Step 6: Apple is a different game — start the paperwork early
The same day the Android app went live, the founder asked how long an Apple developer account takes to be approved. The answer: over a week. They also needed a DBA (trade name) registered for the product, which took most of a month to come through. If Apple is in your plan, file the developer account and business paperwork while you're still building, because it runs on government-and-Apple time, not yours.
That same day, the founder asked the question that would eventually decide the whole iOS strategy:
"Capacitor wrapper (more native)?"
Step 7: Learn from every Apple rejection
Over two weeks in May, Apple rejected the app repeatedly. Each rejection letter was pasted into the workspace, and each one produced a concrete fix in the next build. The full list is a masterclass in App Store review:
- Guideline 3.2.2 — penalty-based payments. Apple read the app's paid commitment program ("pay to commit, lose it if you quit") as a penalty model. The fix reframed it as a program with a completion reward, not a forfeit.
- Guideline 5.1.1(v) — account deletion. Apps with accounts must let users delete them in-app. A working
/settingspage with account deletion shipped in the next build. - Guideline 1.5 — support URL. The support page had to have a working contact form, with no bare email address on the page.
- Guideline 2.3.3 — accurate metadata. The iPad screenshots didn't show the app actually running on an iPad. New screenshots, resubmitted.
- "Make it more native." The vaguest and hardest one: reviewers felt it was a website in a shell. That triggered a full mobile overhaul — bottom tab navigation instead of a hamburger menu, tap targets, safe-area insets, removing the 300ms tap delay.
The founder never argued with a rejection. Paste the letter, fix the exact issue, resubmit. Apple's reviewers reuse the same submission thread, so every fixed issue shrinks the next letter.
Step 8: Go truly native — Capacitor, RevenueCat, and Xcode
By late May, the wrapper approach had hit its ceiling with Apple, and the pivot began in earnest:
"connect to xcode"
"Create a complete Capacitor + RevenueCat implementation guide that extends your existing setup doc with the IAP integration steps?"
"walk me through how to install npm install @capacitor/core @capacitor/cli"
This was the first time the founder touched a terminal. The workspace walked them through it command by command — you can see the moment it got real in the pasted terminal output:
"% npx cap init — [success] capacitor.config.ts created"
RevenueCat handled Apple's in-app purchase requirement (Apple's Guideline 3.1.1 means Stripe checkout alone doesn't fly for digital subscriptions inside the iOS app). And when the Xcode build failed —
"AppDelegate.swift:11:9 Cannot find 'Purchases' in scope"
— the founder did exactly what they'd done with every Google and Apple rejection for two months: pasted the error verbatim and applied the fix (the RevenueCat SDK wasn't linked to the target yet). The build passed the next day.
Step 9: Ship, then keep shipping
By the end of May, the app was approved and live on the App Store, joining the Google Play version. The workspace didn't slow down:
- It responded to every Google Play review and summarized recurring complaints.
- An in-app review prompt went in after a user's third session (Google's In-App Review API), following advice on getting more ratings.
- Android 15 edge-to-edge feedback from the Play Console went straight back into the build queue.
- The paid commitment program launched as its own landing page and product tier.
The stack
Every integration this build actually used, and what it was for:
| Integration | What it did |
|---|---|
| GoDaddy | Custom .app domain, connected to the Denovo MVP |
| PWABuilder | Audited and scored the PWA before store packaging |
| Median | Wrapped the live web app into an Android App Bundle |
| Google Play Console | Android submission, review, and post-launch feedback |
| Apple Developer Program | iOS distribution (account approval takes a week or more) |
| Capacitor | Native iOS shell around the same web app |
| RevenueCat | In-app subscriptions, satisfying Apple's Guideline 3.1.1 |
| Xcode | Building and submitting the native iOS app |
| Stripe | Web-side subscription checkout |
| Google In-App Review API | Prompting happy users for Play Store ratings |
The playbook
If you want to repeat this with your own idea, this is the distilled sequence:
- Build and validate the web MVP first. Both stores shipped the same web app.
- Buy the domain immediately. Reviews check your privacy, terms, and support URLs.
- Run PWABuilder and fix everything it flags. Treat the score as a test suite.
- Ship Android first with a wrapper. Fastest route to a real store listing.
- Write real legal pages before submitting anywhere. Both Google rejections were about them.
- Start Apple paperwork weeks early. Developer account plus DBA took most of a month.
- Paste every rejection verbatim into your workspace. Fix exactly what's cited, resubmit, repeat.
- Expect Apple to demand native. Budget for the Capacitor + RevenueCat step if you have subscriptions.
- Market in the same breath as you build. The launch posts came from the same workspace as the privacy policy.
The whole run from first prompt to both app stores took about nine weeks, working nights around everything else. None of the individual steps required an engineering background — they required not stopping at the first rejection letter.
Have a question about any step? Reply below — and if you've shipped your own Denovo build to an app store, we want the next Founder Story to be yours.