I spent about 12 months building a baby tracker solo and bootstrapped; it's been live on the App Store since June, and I taught myself React Native to build it. The part I want to share isn't the tracker - it's one design decision in the allergen scanner, because it's a "what do you do when your data is empty" problem.
Quick caveat up front, because it's safety-adjacent: this is not a medical device, it doesn't diagnose anything, and the failure mode it's built against is a false negative - telling you a food looks fine when it isn't. No tool catches everything; you still read the full label and talk to your pediatrician. I'd rather say that first than bury it.
Most barcode allergen scanners do the efficient thing: look up the product, read the ingredient list, check it against the allergens you care about. Fine when the product is in the database. But scan an imported product the database has never seen, and a lot of them just return "no allergens found." That's a silent failure: it reads like "safe" when it really means "no idea."
I went the other way. An empty or unreadable record is treated as a reason to look HARDER - including reading label text across several languages - never as an all-clear. It leans toward "double-check this" over "looks fine." It can over-flag, and I'll take that trade. The scan that proved it out: an imported product returned zero ingredient data from the open product database (Open Food Facts, 3M+ products), and instead of a green check the scanner flagged peanut against a profile that had peanut set as an allergen and hard-blocked with "DO NOT FEED." To be honest the product name literally said peanut butter, so a careful human catches this one too - the point isn't that it's clever, it's that it refused to fake confidence on missing data.
Two lessons from building this solo:
The problem that LOOKS hardest is usually the one you can buy. "Read foreign-language label text" sounds like the hard part - it isn't, that's a solved problem off the shelf. The genuinely hard part was the logic: what counts as a match, what counts as "safe," and what the app does when the data is incomplete. That's where the months went.
Build the safe failure mode FIRST. The most important behavior in the whole app is what happens when something goes wrong - sparse data, a timeout, an unreadable label. If you build the happy path first and bolt on error handling later, your "safety" feature is decorative.
Stack: Expo / React Native, Supabase (Postgres + RLS + Realtime), an LLM for the AI calls (server-proxied through an edge function - no API key in the client bundle, which I'll happily rant about because shipping paid-API keys in a mobile binary is depressingly common), StoreKit 2 via expo-iap, and Open Food Facts as the barcode database.
Happy to go deep on the allergen ontology, the empty-data design, the Supabase RLS for co-parent sharing, or the server-proxy-vs-client-key thing.
App Store: https://apps.apple.com/app/id6764412763
Site: https://babyledgerai.com?utm_source=devto&utm_medium=organic&utm_campaign=build-in-public
SOCIAL SHARE CARD GENERATOR