A solo founder's honest recap of building HadaBuddy: 508 commits, 4 Apple rejections, one Gemini API key, and the parts nobody writes about.

---

I started building HadaBuddy on March 28, 2026.

I had it live in the App Store 24 days later.

I didn't quit my job. I didn't take vacation. I have a full-time engineering role I genuinely love, and HadaBuddy got built in the cracks: weeknights after my kid went to bed, Saturday mornings before the household woke up, the occasional Sunday afternoon when I should have been doing literally anything else.

This is the recap. Not the LinkedIn humblebrag. The real one, with the parts that didn't go to plan.

What I was building

HadaBuddy is an AI ingredient scanner for skincare. Scan any product with your phone, by barcode or by ingredient label, in any language, and it tells you what each ingredient is doing in your jar, whether it's likely to fit your skin, and what to actually do with the product. It runs OCR on-device, has a 47,000-ingredient reference database, and uses Gemini under the hood for the personalization layer.

Why I built it

I started this for myself. I wanted to learn AI properly, and the way I learn anything is to build with it.

The trick was picking the right something to build. I didn't want another notes app or chatbot wrapper. I wanted to point AI at a real pain point, the kind I lived with every day, where the wrong answer cost me real money or real skin.

Which brings me to last November. I came home from a Korea trip with a suitcase of masks, serums, and sheet packs in three different label languages, and realized I was about to spend a whole evening typing INCI names into Google. There were a few existing ingredient apps. None of them were built for the person I actually was.

That was my pain point. So I built the app I wished existed.

What "24 days" actually looked like

In numbers:

• 508 commits across 31 days, around 17 a day on average
• 9 of 15 planned phases shipped end-to-end
• 47,000 ingredients in the database
• 150+ conflict rules with severity badges
• 8 onboarding screens so the AI actually knows who you are before it gives advice
• 3 Gemini tiers for cost control (Flash Lite, Flash, Pro for high-reasoning calls)

Week 1: brand and foundation

The first week looked nothing like building a product. It looked like:

• Repo init, brand identity, gradient palette, the "✦ HadaBuddy ✦" mark
• Picking the stack. Expo for mobile, Next.js for the marketing site, Supabase for everything backend, Vercel for everything web. No exotic tools. I wanted to ship, not learn.
• Building the schema for the ingredient database. This was the whole product, so I spent a full Saturday on it.
• A waitlist site so I could collect emails while I built the real thing.

Halfway through the week I almost convinced myself to add an Android version. I didn't. That decision is one of the big reasons there's an iOS version live now.

Week 2: mobile shell and skin profile

Days 8 to 14 were when the product became a product. 4-tab navigation. The 8-screen onboarding flow that asks about your skin type, concerns, age, tone, gender, and location. AsyncStorage. EAS Development Build.

This was also the week I had to make my first stack-purity-vs-shipping trade. The original plan had Zustand for state, op-sqlite for local storage, and NativeWind for styling. What I actually shipped was React Context, Supabase as the source of truth, and raw StyleSheet. Less elegant. Faster to ship.

I made a note in my plan doc: "Decision: ship over purity." I've reread that line every time I've been tempted to redo something this month.

Week 3: the AI part

Days 15 to 21 were the part most people imagine when they think "AI app": getting the OCR to work, wiring up Gemini, turning a photo of a product label into a structured ingredient list, then turning that list into actual advice for a specific person's skin.

This took longer than I expected because the hard part wasn't the AI. It was the messy real-world inputs. Smudged labels. Korean ingredient names with subscript numbers. Sunscreens that printed everything in three columns of 6-point font.

The fix was unsexy: a custom validation step before every Gemini call, a 3-tier cache (memory, disk, Supabase) so the same product never gets re-scanned twice, and a fuzzy INCI matcher that knows "Niacinamide" and "NIACINAMIDE" and "nicotinamide" are the same thing.

This is also when I built the 7-day weekly routine engine: AM/PM, conflict detection, per-day locking. 80 conflict rules at the start. 150+ now.

Week 4: monetization and launch prep

Days 22 to 24 were the stretch.

RevenueCat. The paywall. The pricing page. The Pro tier ($3.99/mo, $29.99/yr). Nudge-gated paywall, the kind that appears after you've used the product, not before. Server-side rate limits so I don't accidentally pay Google to serve a stranger's free tier.

The marketing site rollout was behind a NEXT_PUBLIC_APP_LIVE env toggle so I could flip it on the moment Apple approved the build.

Then I hit Submit. Which is where the actual hard part started.

Apple App Review: where I lost almost two weeks

I left this part out of the timeline because it was the part I wanted to forget.

I submitted my first TestFlight build on April 7 at 7:57pm, full of confidence. Less than 24 hours later, App Review came back with one line that took the wind out of me:

Guideline 2.1(a) Performance App Completeness. We were unable to review the app because it crashed on launch.

They couldn't even open it.

The reviewer was on an iPhone 17 Pro Max running iOS 26.4, the latest beta. I'd been testing on slightly older versions. The crash logs (two of them, attached as raw .ips files) pointed to a code path that only ran on the iOS my reviewer happened to be using.

I sat with that email for about 20 minutes before I touched the code. There's a particular flavor of dread that comes with "we couldn't even open your app." It's not a missing feature. It's not a privacy oversight. It's "your thing doesn't work," in writing, from Apple.

I fixed the crash. Pushed a new build. Resubmitted.

The next rejection arrived hours later. Same guideline. Same exact reason. Crashed on launch.

That one hurt more than the first. My "fix" had only patched one of two crash paths. The reviewer's device hit the second one. I learned in real time that "it works on my phone" is meaningless when the reviewer is on the latest hardware running the latest OS.

So I bought a fresh test device, downloaded iOS 26.4, and cold-launched the app on it about a hundred times until I trusted the build.

The TestFlight crashes were just the warmup. The real App Store rejections came next.

Round one: I forgot to submit the IAP products themselves

April 14. I'd wired up the paywall, configured the in-app subscriptions in App Store Connect, hit Submit on the binary. Apple wrote back:

"The app includes references to subscriptions but the associated In-App Purchase products have not been submitted for review."

The IAP products and the app binary live in two separate "submit for review" queues in App Store Connect. I'd submitted the binary. I'd never submitted the IAP products. They sit in their own UI, attached to a specific app version, requiring their own metadata and an "App Review screenshot." Half a day lost to clicking through App Store Connect.

Same email also flagged a missing Terms of Use link in my App Description. My Pro tier UI mentioned subscription terms in-app, which I'd assumed was enough. It wasn't. Apple requires a functional link to the Terms of Use in the App Description AND in the EULA field on App Store Connect. Two more lines of metadata. Another 24 hours of waiting.

Round two: the third-party AI privacy disclosure

April 18. The rejection that every AI app builder should read carefully.

Guidelines 5.1.1(i) Privacy Data Collection and 5.1.2(i) Privacy Data Use. The app appears to share the user's personal data with a third-party AI service but the app does not clearly explain what data is sent, identify who the data is sent to, and ask the user's permission before sharing the data.

HadaBuddy uses Gemini for the routine generation logic. To Apple, that's a third-party AI service receiving user data. The app must:

1. Explain in-app what data is being sent
2. Name the recipient (Google, Gemini)
3. Ask for explicit consent before the first call
4. Update the privacy policy with the same details

I'd done some of this. I had a privacy policy mention. I did not have an in-app consent screen with an explicit "send my skin profile data to Google for AI processing" toggle that fired before the first Gemini call. The reviewer caught it.

If you are building anything that sends user data to OpenAI, Anthropic, Google, or anyone else's LLM API, expect this rejection. It is a relatively new App Review focus and it is getting stricter. Plan for an explicit consent screen in your onboarding flow from day one.

By the time the "Ready for Sale" email finally landed, I'd been through more rejections than I want to count. The four above are the ones I won't forget. The rest were the smaller stuff: a metadata field here, a screenshot caption there, a permission string the reviewer wanted spelled out more carefully. Each one cost me 24 hours of waiting and a small piece of confidence I had to find again before I hit Submit.

I screenshotted that "Ready for Sale" email. It's still on my desktop.

What I would tell my younger self

• Test on the latest iOS, not the version on your phone. Apple reviewers run current devices on current OS. Buy a test device or boot the latest iOS Simulator, and cold-launch your app there before every submission.
• Symbolicate your crash logs before you panic. Apple attaches the raw .ips files to the rejection. They look like garbage. You need to symbolicate them with your app's dSYMs before you can actually read what failed. The Xcode instructions aren't optional.
• If you have IAP, submit the IAP products too. Not just the binary. They live under their own "Submit for Review" button in App Store Connect, with their own required screenshot.
• Link your Terms of Use in the App Description. Even if you mention them in-app. Apple checks the metadata as a separate surface.
• Build an in-app AI consent screen on day one. If you're sending data to a third-party LLM, you need explicit consent BEFORE the first call. Don't bury it in the privacy policy and hope.
• Submit early in the week, not on a Friday. Reviews queue over the weekend, and you don't want to spend Saturday morning watching a status bar.

What I cut to ship in 24 days

The honest list:

• Android: deferred. iOS only.
• Credit-bundle billing: planned as Phases 10 to 13. Cut to a single subscription tier. Less ledger plumbing, less time spent on something users hadn't asked for yet.
• Database hardening: Phase 15 (proper Row-Level Security across the board) is still in progress. I shipped with permissive RLS and a plan to harden in the open.
• PostHog, Plausible, the full analytics stack: dropped. I use Vercel Web Analytics and that's it.

All of this was a trade. Speed-to-launch over completeness. I'd make the same trades again.

The lonely part

Building solo is lonely in a way nobody quite captures.

You ship a feature on a Saturday morning and the only feedback you get is your own coffee going cold. You hit a bug at 11pm and there's no one in a Slack channel to rubber-duck with. You learn how to do SEO from scratch by reading Reddit threads and feeling slightly stupid for three weeks.

There's a quiet army of people doing this every weekend. Most of us never tell anyone.

What's actually live now (day 30)

• iOS app, current version v1.13.1, on the App Store
• Marketing site at hadabuddy.com
• Blog with around 24 long-form skincare posts
• Ingredient hub, FAQ, about page
• In-house newsletter via Resend Broadcasts
• 47,000-ingredient reference database powering it all

You can download HadaBuddy on the App Store. It's free, with an optional Pro tier for the people who want unlimited routine regeneration.

If I were starting over today

Three things.

1. Pick a launch date first, then scope to fit. Not the other way around. I didn't add an Android version in week 1. That's one of the big reasons there's an iOS version live now.
2. The polish takes longer than the build. The MVP took a week. The actually-shippable version took three.
3. Ship over purity, every single time. Every "this should be done properly" instinct is just delay wearing a costume.

---

I'm writing more of these. Next up: what it actually costs to run a free iOS app as a solo founder.

If you're building something on the side too, send me a note. I'd rather know there are more of us out there than not.

---

Side project. Nights and weekends. Opinions mine.

Originally published on Medium.