← All whitepapers
May 2 — May 18, 2026

I built a mobile app in 17 days. Here is exactly how I did it:

The full story of how Braindex went from a simple idea to an app officially submitted to the App Store — all in just 17 days.

50
commits
17
days
1
person
$20
budget

Here is every tool I used:

This list may seem short, but in reality, it’s everything I used and all you need! I stayed disciplined and focused on building an MVP (Minimum Viable Product) without overcomplicating the process. The goal of this whitepaper is to inspire other builders to build, so I hope sharing my toolkit with you greatly helps you, and my only ask in return is to please give Braindex a go and do share any feedback you might have with me — I am hoping to improve the app day by day!

Built with:

Content, Frontend, Backend
  • Claude Code — acted as my pair programmer for Dart, and polished Lovable’s first drafts ($20/month plan)
  • VS Code — the central workspace where everything comes together (my IDE of choice)
  • Lovable — prototyped the app’s userflow & the landing page for the braindexapp.com website (free plan)
  • Flutter + Dart — learned of the advantages of coding in Dart when we built Pi-Squared: one codebase compatible with both iOS + Android
  • Firebase — Auth, Firestore, Database, Analytics, security rules
  • Manus + Perplexity + Gemini + Claude Cowork — performed deep research on AI topics and generated the 1,645 vocab + MCQ items across 20 sections

Shipped with:

Sign, Upload, Host, Distribute
  • GitHub — where you store & save all your code, and monitor version control
  • Xcode — iOS signing, provisioning
  • Transporter — IPA upload to App Store Connect
  • App Store Connect — Apple submission, TestFlight, store listing
  • Google Play Console — Android submission, closed test
  • Vercel — free hosting & analytics for braindexapp.com
  • GoDaddy — domain registration + DNS

Prerequisites assumed:

My timeline below says “initial commit, empty Flutter project” on day one… but what that doesn’t show is the administrative setup I guess I had already completed behind the scenes. A lot of these administrative hurdles had been solved last year while building Pi-Squared, which gave me a huge head start. Even then, there’s still a stack of things you need in place before that first commit is actually possible:

Hardware: Mac with current macOS + Xcode installed · an iPhone for real-device testing (Sign in with Apple doesn’t seem to work on a simulator).

Accounts: Apple Developer Program ($99/yr, allow a day for enrollment) · Google Play Console ($25 one-time + ID verification, which can take days) · Firebase project with billing enabled · domain you control with DNS access. Claude Personal plan ($20/month).

Skills: familiarity with Dart certainly helped, basic Firestore data modelling, understanding of data tracking, understanding of app userflows, iOS signing concepts, and some patience for the administrative hurdles. If any of these feel new, add maybe 1–2 weeks of ramp before “Day 1.”

Honest Disclosure: AI did the heavy lifting. I simply orchestrated!

Building an entire functioning Flutter app, a secure & clean Firebase backend, 1,645 AI content questions, a website, and two app store submissions in 17 calendar days is not a story you should believe without an asterisk! So, here’s the asterisk:

Claude Code wrote most of the Dart. Lovable created most of the website — I mostly made architecture calls and reviewed every change. Gemini, Perplexity, Claude Cowork and Manus wrote the 1,645 definition questions from a taxonomy I got AI to draft for me in an afternoon. Without these, this is easily a ~ six-month project. With AI, the bottleneck shifts from “writing code” to “knowing what to ask for, what to keep, and what to throw away.” That’s the skill the next decade is going to reward! Disclaimer: I didn’t do it all alone… I did set up some agents to help me…
Figure 01

Six AI agents with six different roles, each aligned & reporting to a manager.

For each general task or item on my to-do list, I spun up an agent. The job became routing work between them and reviewing what came back. And I even created a ‘project manager’ agent to dish out the different tasks to the different agents.

Product

Product manager

Translated “Build a daily AI vocab game” into a v1.0 / v1.1 / v1.2 scope ladder. I pushed it hard to prioritise simplicity and basic functionality over complexity for early versions.

Engineering

Engineer

Wrote and refactored the Dart. Owned the Firebase rules, the auth flows, the technical work. I basically just described to the engineer what worked well for us when building Pi-Squared — simple daily games with countdown timers, multiple choice questions and leaderboards always go down a treat with all ages.

Content

Question creator

Generated 1,645 vocab + MCQ items across ~25 areas in AI, working from a taxonomy I got the AI to author for me in an afternoon.

Delivery

Project manager

Kept the parallel workstreams in sync. Logged what got shipped, what got blocked, what moved to the next version, and who (which agent) we were waiting on. I basically had this agent mentor me throughout the entirety of the process, and had it guide me on ranking my priorities and deciding next steps.

Design

UX

Owned the screen flows, the layouts, the mobile app functionality, and the website’s first draft. I used Lovable for first drafts and ran the edits through my design agent. Lovable is great for rapid prototypes, and I took a lot of inspiration from each of my different Lovable projects. But ultimately, you still need to push back on these no-code tools a lot these days to maintain non-AI feels to your apps… as a lot of the designs that come from these tools feel somewhat similar. Hence, the design agent!

Telemetry

Analytics dashboard

Defined the Firebase event schema, built the daily-tracking dashboards. I wanted to track retention from day one. I honestly learned so much from the first time I built an app. And I am only now really realising how far I have come since the good old days… tracking user data religiously from the beginning helps you understand who your ICP (ideal customer profile) is, what to build next by seeing which features people actually use and where you lose people. Data tells powerful stories.

The unlock wasn’t any one agent — it was the handoff between them. I really had to focus on getting the agents to communicate to one another. Product manager defines a feature, engineer implements, analytics adds instrumentation, UX designs the screen, project manager ensures the loop is closed. All within an hour. Multiple chats flowing at the same time. By the time you get back around to the first one, it’s finished its job, and you simply repeat this process. The bottleneck stopped being waiting on AI outputs to load as they could all now run in sync.

Figure 02

AI terms and definitions added per active day.

It’s important to note the sheer volume of terms required to make this game a success and sustainable. Each question requires four potential answer options, with only one of them being the right answer each time. So ideally, as a user, you see twenty-four different definitions each day across the six questions. And nobody enjoys seeing the same questions everyday. I wanted users to feel excited to come back and learn new terms each day!

May 3
269 *
May 8
70
May 9
1,575

* On May 3, I created just enough for about 11 solid days of the original game (v1.0), separate from the 1,645 words that followed. I do believe in shipping the bare minimum first before you spend your precious energy on building sections out. But for this app to be sustainable, I did initially worry there might not be enough AI terms out there… but six days later, I was gladly proved wrong!

Definitions weren’t typed by me of course — they’re generated in batches across Gemini, Manus, Perplexity — you name it. Open one AI tool, prompt it, while that loads, open the next. Repeat. The 1,575-item explosion on May 9 came from running 25 section-generator passes in parallel through the question-creator agents. Each pass took ~5 minutes. None of them would have been possible without a taxonomy and detailed plan written first.

Note: I did have to ensure each definition was roughly the same length in terms of the number of characters… as each had to fit in the same size space on the app screens for the UI to look clean.

Figure 03

Where the 10 active days went:

The day-by-day timeline categorised. 22% of active days were spent on marketing + submission admin — almost as much as on writing the app itself! But wait, David, I thought you said it took you 17 days?! This is 17 calendar days, outside of my full-time job Monday–Friday and evenings playing semi-professional soccer. Of the 17, I worked on the app on only 10 of the days.

Build, test & scaffold
3 days
Content
1 day
Cloud / backend
1 day
UI polish
2 days
Website
1 day
Ship / submit
2 days

The number that might surprise you: ~22% of active days went towards the app submission — my advice to you would be to get started on the admin hurdles while your code generates and while your AI agents are running. Most “shipped fast” stories under-count this. If you’re planning your own 17-day sprint, I recommend budgeting easily two days for app store admin from the start!

The day-by-day:

Active development days only. In between building days, I was kept busy working my day-job and training for ~2 hours in the evenings with Grand Rapids Soccer Club, though I certainly did think deeply about building while driving to training each night during the week, while listening to inspiring podcasts too.

📅 May 2Day 1

The repository was created.

  • Initial commit. Empty Flutter project, a name, pretty much just a hunch about a daily AI vocabulary game. Some markdown files describing what was on my mind and the vision I saw.
📅 May 3Build day

From nothing to playable in one sitting.

  • iOS & Android scaffolding, build fixes — App Store preparation already on the mind
  • v1.1+ cloud architecture plan (auth, leaderboard, analytics) — designed before built
  • Firebase Analytics event schema
  • Mini-games frameworks — I mostly had word games in mind
  • Brand: brain mascot iOS icon, wordmark logo on splash and home
  • Decided to pursue the Definitions Game v1.0 — 269-word tiered word bank, Q1–6 navigation, bright theme, minimalistic design
  • View Results + Play-for-fun (practice mode)
📅 May 8Content

The engine started to take shape.

  • iOS warnings, share button fix, timer-resume behaviour fixed (I tested the app on TestFlight and started to uncover these errors myself!)
  • Marketing prep: Canva designs for App Store pictures
  • v2.0 learning-platform roadmap written in docs (pen-to-paper as I think of future game modes — saving ideas as markdown files)
  • v1.1 foundation: domain models for sections + games + content items
  • v1.1 foundation: repositories + services (local-first, cloud-ready abstractions)
  • Flash Cards game + section-library screens prototyped
📅 May 9Content

The content explosion!

  • 20 department sections authored (1,645 items total)
  • Concept Quiz mode
  • I wanted to ensure there was enough AI buzz words out there to be asked about
📅 May 11Cloud launch

Local-only → backed by Firebase.

  • v1.1 cloud release — Firebase backend, auth, leaderboard, account UI
  • iOS: Sign in with Apple entitlement wired
  • iOS: Google Sign-In URL scheme
  • Onboarding gate + Firestore rules + timer-on-revisit fix
  • Privacy policy rewritten to be accurate to Firebase + v1.1
  • Results-screen polish + auth cache + display-name fix
  • Share-link domain fixed: braindex.combraindexapp.com (domain purchased)
📅 May 12v1.2 features

The v1.2 feature push.

  • Daily on-device reminder system (unnecessary for v1.0, but I started the admin work too late so I had time!)
  • User profile screen + in-app feedback + home/results navigation
  • Android project scaffold + Firebase Android config (Android first appears)
  • Firestore composite indexes for leaderboard queries
  • Apple-SI error visibility + guest restrictions + delete-account cleanup
  • v1.2.0+1 — merged v1.1 bugfixes + the rules
  • Privacy policy updated for user data collection + feedback + reminders
  • v1.2.0+2 — sign-out routing + notification permission + View Results fix
  • Podfile.lock refresh after I worked the notifications feature
📅 May 13Polish

UI polish on a working v1.2.

  • v1.2.0+3 — streak chip on home + UI polish + provider tweaks
  • v1.2.0+6 — Apple sign-in errors in Settings + accumulated polish
📅 May 16Marketing site

The web presence you need but nobody builds in time.

  • Marketing landing page (index.html) + /newsletter Firestore rule
  • Compliance pages: delete-account.html + support.html — required by both stores
  • Deletion policy text aligned with what the code actually does
  • Landing-page polish: bigger logo, trim features, hide delete-account from nav – move to inside the support page
  • Drop features grid, keep “How-it-works” 1-4 only
  • Rebrand all site pages – make it feel “less AI”
  • Founder note + back-to-home + mobile responsive + domain swap
  • Tighter hero spacing (logo + headline + signup above the fold)
📅 May 17Ship-ready

v1.2 finally feels shippable.

  • v1.2 commit — email/password auth, top-streaks board, daily telemetry
  • Results share functionality (for virality effect)
📅 May 18Submission day

Everything you save until the very end… every time!

  • Sign in with Apple refactored to provider-based linking — fixed the silent failure
  • Display name fix: auto-generate “AI Learner #” for guests → account creation allows you to change your name
  • Share format updated: brain emojis, time on score line, simpler URL
  • Post-play notification re-ask (one-shot, after first daily completion)
  • iOS IPA built (1.2.0+8), uploaded via Transporter — in Apple review
  • Google Play Console: data safety, content rating, target audience, advertising ID, encryption — all completed
  • Android closed test in flight — 14-day clock running
📅 May 21Day 11

Approved, live, in 100 hands.

  • App approved by Apple — Braindex officially live on the App Store
  • From zero to in 100 people’s hands in 20 days
  • From May 22 to June 10, I’d say I spent more time writing this whitepaper about how I built the app than I did actually building it!

The hurdles nobody warns you about:

People usually talk about “the build.” Almost nobody talks about these mini-mountains I had to climb — the things that turn a 30-minute task into a half-day rabbit hole… learn from my mistakes, and save yourself having to learn the hard way!

1. Sign in with Apple silently breaking on Flutter + Firebase.

Tap “Sign in with Apple” → see a brief success tick → get an “auth error.” Repeatable. Devastating! The Apple identity-token nonce is single-use, but the manual credential flow tries to re-use it on retry, which Firebase rejects as invalid-credential.

Fix: switch from the manual signInWithCredential flow to provider-based linkWithProvider(AppleAuthProvider()) / signInWithProvider.

2. Xcode’s “Product → Archive” fails where the CLI works.

Same code, same Pods, same machine. flutter build ipa produces a clean 48 MB IPA. Then you open Xcode and click Archive and it dies on Command CompileC failed for a gRPC-Core C++ file.

Cause: the CLI passes CLANG_CXX_LANGUAGE_STANDARD = c++17; Xcode’s GUI uses defaults that don’t. Workaround: use the CLI, upload via Transporter. Real fix: Podfile post_install hook (deferred to v1.2.1).

3. CocoaPods stale-cache landmines.

Four-minute build that died on a missing header: 'absl/strings/cord_analysis.h' file not found. Search the web, find 200 contradictory fixes. The actual fix takes one minute.

Fix: flutter clean && rm -rf ios/Pods ios/Podfile.lock ~/Library/Developer/Xcode/DerivedData/Runner-*, then pod install --repo-update. Comes up about once a quarter on any Flutter + Firebase project.

4. Google Play’s mandatory 14-day closed test.

New personal developer accounts created after November 2023 must run a closed test for 14 days with at least 12 active testers before being permitted to submit to production. So even after everything is signed off, Android is ~3 weeks behind iOS by default.

Strategy: ship iOS first. Use the 3-week Android wait productively — recruit testers, run real-device QA, plan the next version. The clock only counts once you have 12+ active testers, so find and add them on day one.

The admin surface area:

Every box below was a form, declaration, asset, or URL you had to provide.

Apple

App Store Connect
  • Apple Developer Program enrollment ($99/yr)
  • Bundle ID registered
  • Distribution certificate + provisioning profile
  • App Store Connect record (separate from dev portal)
  • App icons
  • Screenshots for ~2–5 device sizes
  • App name, subtitle (30), promotional text (170)
  • Description (4,000) + keywords (100)
  • Copyright + Content Rights declaration
  • Primary + Secondary category
  • Linked-to-identity vs Used-for-tracking calls
  • Age Rating questionnaire (15 questions)
  • Export Compliance
  • Privacy Policy URL (must return HTTP 200)
  • Delete-Account URL (since 2022)
  • Demo account for reviewer
  • What’s New release notes
  • Pricing + per-country availability
  • TestFlight build upload + processing wait

Google

Play Console
  • Play Developer registration ($25 one-time)
  • Data Safety form (different from Apple’s)
  • Target Audience declaration
  • Ads declaration
  • Advertising ID declaration (separate from Ads)
  • Content Rating questionnaire
  • App Access instructions for reviewer
  • Financial features declaration
  • Health features declaration
  • App icon (512×512)
  • Feature graphic (1024×500, Play-only asset)
  • 2–8 phone screenshots
  • Short description (80) + Full description (4,000)
  • Release notes
  • 14-day closed test with 12+ testers (new accts)
  • Production review (1–7 days)

What I’d tell my past self:

Five things I learned having now built two apps.

1

Minimalistic designs win.

Make it so obvious to users where they should click next and make playing your daily games so intuitive — every single click matters, and each is an opportunity to lose your user. So be careful to design your flow and functionality to perfection.

2

People love competition.

If you are building a consumer app, try your best to gamify it. People love quick minute-long challenges especially when you are given a score, and even more so when you can see where you rank amongst others, and so even if your goal is to teach, you might need to create fun, competitive mini-games to earn sticky users.

3

Your MVP still needs to be good.

MVP stands for Minimum Viable Product. But if your game is not fun and your design is not good, people will not come back. You don’t always get given a second chance. So if somebody takes the time to download your app, make sure it was worth their time! Especially today, we all expect better products. The bar has been raised. So make something you’re proud of, and then share it. It doesn’t need to be perfect of course, but it needs to be good enough so that people can see the potential in it in my opinion. Otherwise future marketing efforts won’t attract lost users back to the app regardless of how much the app has improved… first impressions matter!

4

Screenshots don’t have to be screenshots.

Think marketing artwork that happens to contain a screenshot. Clean background colour, headline copy, device frame, gradient — all design decisions that make a big difference. Your app store listing is your landing page. You want to have your users excited at this point. Make it look interesting.

5

Document your journey.

This time round, I was determined to track how long it would take me to go from zero-to-one. But even on social media, sharing news about what you are working on always helps. People appreciate being taken on the journey with you. Build momentum early!

Give Braindex a go!

50 commits and 17 days later, Braindex is now live on the App Store. If you would like to play:

Braindex brain mascot waving
braindexapp.com
Thanks for reading! — David

What is Braindex?

Braindex has since evolved… Braindex is still the first daily AI game, but there is also daily Trivia games now too! Enjoy!