Checked Out

Checked Out is a weekly meal planner for households where nobody eats the same — GLP-1, gluten-free, bariatric, allergies, picky eaters — one plan, one shopping list, for the whole table, every week

Comment

Inspiration

Every week, I was the one carrying the mental load: figuring out next week's menu, building the grocery list, and doing it all with nobody else in the family sharing that weight — including accounting for every swap it took to make one dinner actually work for everyone. My son has Celiac, but we're not a gluten-free household; it's just him. My daughter's a picky eater. So a normal week might mean pulled pork with regular bulkie rolls for most of us, GF rolls added to the list for my son, and corn on the side because that's the one vegetable my daughter will actually eat. I wasn't cooking separate meals — it was one dinner with the swaps worked in — but keeping all of that straight, every single week, by myself, was the real burden. Not to mention, we were all getting bored with the same meals on repeat, because it was easier that way. Checked Out exists to carry that mental load instead of me: the swaps, the list, the "wait, did I account for everyone" — done automatically, not re-solved from scratch every Sunday. And, it give us the variety we have been lacking!

What it does

Checked Out is a weekly meal planner for households where not everyone eats the same — built around real per-person dietary profiles instead of one setting applied to the whole family. You tell it who's in your household and what each person needs: Celiac or gluten-free, GLP-1, bariatric, allergies, low-carb, or just a picky eater who won't touch certain foods. It generates one weekly meal plan — breakfast, lunch, dinner, and snacks, whichever meals and however many you choose — with each person's version of the meal worked in as a swap, not a separate dish: GF rolls added alongside the regular ones, corn instead of whatever vegetable someone won't eat, a GLP-1 household member's portion adjusted for lower fat and a smaller serving while everyone else's plate stays the same.

You can save your household's actual go-to meals so they show up regularly in your plans (and influence your tastes), ask for a specific dish, mark a night or a meal off for eating out or travel, and swap anything you don't like before committing to the week — including moving an already-planned dinner to a better night without touching the shopping list. Anyone who wants individual calorie or macro targets can set them and the app will account for those in the plan as well.

Every plan comes with one shopping list — organized by category and itemized down to the exact amount, covering every person's swap on the same list. Add anything else you need and it saves instantly, so when you get to the store, or your online cart, you've got everything you need at your fingertips.

How we built it

Checked Out is a solo build, from the backend up. The API is FastAPI with SQLAlchemy and Alembic on PostgreSQL, deployed on Railway. The web app is React, deployed on Vercel, with Clerk handling authentication and Stripe handling billing. The mobile app is Expo/React Native, live on Google Play, using Clerk for auth (email/password and Google sign-in), Firebase Cloud Messaging for push, and Sentry for error monitoring on both mobile and web.

The actual meal planning runs on Claude: claude-sonnet-5 generates the weekly plan itself — reading each household member's dietary profile and working their swaps into one shared plan. Generation also draws on a household's own history rather than starting from a static profile every week: accepted plans and swap patterns are recorded and read back in, so a household that's been using Checked Out for months shapes its own future weeks — not just its settings page.

Monetization runs through RevenueCat wrapping Google Play Billing on Android — two products, $9.99/mo and $99/yr, each with a 14-day trial — while the web app checks out through Stripe directly. Both surfaces report into a single, provider-agnostic entitlement model on the backend, keyed to the household rather than the individual, so a household can't end up with two free trials just by switching between the web app and the native app.

A B2B path came up along the way, too — a coach- and dietitian-facing version, with pitch materials, a coach portal spec, and a coach-facing rollup of client data. It's a dead end for now; no coach billing or dedicated coach product ever shipped. But the entitlement model still carries a source field built to support a coach granting access to client households, left in deliberately in case that path gets picked back up.

Challenges we ran into

The RevenueCat integration itself was the first real wall. Purchases.getOfferings() reliably resolved our offering but returned both subscription packages with storeProduct set to null — no error thrown, just unusable data, on every build and test condition we tried. We traced it down to real RevenueCat SDK logs showing a successful product fetch immediately followed by a ui_config remote-config resolution failure, timing-correlated every single time, filed a support ticket, and ultimately shipped a verified workaround — calling getProducts() directly against Google Play instead of going through RevenueCat's Offering/Package resolution — rather than let a launch blocker sit open while chasing the deeper cause.

Native Android also put us through a multi-week saga of users getting kicked back to the sign-in screen mid-session, with no backgrounding, no notification, nothing external triggering it. It took nine separate tracked fixes, several "found it, fixed it" claims that didn't hold, and a full rewrite of a custom auth-resilience layer onto Clerk's own documented pattern before we found the real mechanism: our own job-status polling frequency was manufacturing far more token-refresh race conditions than a typical integration would ever hit.

We also shipped an Android build signed with the wrong key — twice. It's invisible in the build log and only shows up as a Play Store rejection after the fact. That's now guarded by a mandatory signing-verification script that has to pass before any production upload.

Billing enforcement had its own hard problem: with two independent billing surfaces — Stripe on the web, RevenueCat and Play Billing on native — each platform's own one-trial-per-account protection only covers that platform. Nothing stopped a household from getting a second free trial just by switching between the web app and the native app. Fixing that meant building a backend-owned, deletion-proof trial ledger as the real source of truth, instead of trusting either store to enforce it alone.

And positioning turned out to be a moving target, not a one-time decision. Competitive research midway through turned up a direct competitor with nearly identical positioning and an identical $9.99/mo price, which forced a real rewrite of the store listing rather than shipping generic "family meal planner" copy that would've read as the same product to anyone comparing the two.

Accomplishments that we're proud of

Checked Out is real, not a demo — live on Google Play through actual store review, with two independent billing rails (Stripe on web, RevenueCat and Google Play Billing on native) reconciled into one backend entitlement model so a household's subscription status is consistent no matter which surface they're on. Built and shipped solo, that's not a small thing to have working end to end. Today that's seven paying households and $70 in monthly recurring revenue — small, and real, and growing one household at a time.

We're proud of how the hard bugs got solved, not just that they eventually went away. The RevenueCat storeProduct issue got root-caused with real SDK logs and a support ticket, not guessed at. The native "signed out mid-session" saga took nine tracked fixes and several wrong turns before we found the actual mechanism — our own polling frequency colliding with token refresh — and fixed the real cause instead of patching the symptom again.

But the accomplishment we're proudest of is what real people have said, unprompted, about what this actually solves. One user, after bariatric surgery, wrote: "I recently had bariatric surgery and was struggling to create weekly menu plans that supported my new life change yet appealing to my husband. The different features and options create amazing plans." Another wrote about planning for her own bariatric and low-sugar needs alongside a household member who "won't eat lamb or veal or anything that's a cute baby" and her own hard "no" on zucchini noodles: "In less time than it takes to make a cup of coffee, Checked Out planned my week, explained variations for my diet, and even built a whole shopping list. I didn't like one of the suggestions, and Checked Out swapped it out several times until I found something I liked." Neither person was asked for a quote — they posted this on their own.

The core differentiator held up under outside scrutiny, too. Competitive research into the meal-planning category confirmed that most listings treat "family" as a headcount, not a household of people with genuinely different needs — exactly the gap Checked Out's per-person dietary handling closes. Checked Out's PeerPush listing sits at 5.0/5 from real reviews, carries "Trending Now" and "Awarded" badges, and ranks #3 on PeerPush's "Best Meal Planning Tools in 2026," with additional roundup features in Grocery Management, Macro Tracking, Tools for Parents, and Tools for Coaches.

What we learned

A plausible explanation for a bug isn't the same as a confirmed one. The native "signed out mid-session" saga produced several rounds of fixes that were real, reasoned, and still didn't hold — the pattern only broke once we stopped shipping on inference and got hard evidence of the actual mechanism. That's now a written rule, not just a lesson: read the actual source, logs, or trace before shipping a fix.

Relatedly: check a third-party SDK's own documentation before writing a workaround around it. More than one bug in this project got chalked up to "the tool is flaky" when the real cause was our own integration driving RevenueCat or Clerk into an edge case a normal integration wouldn't hit.

Skipping architecture review to move faster doesn't actually save time on a solo project — it just moves the cost later and compounds it. Letting billing logic get bolted onto the wrong foundation instead of rebuilt properly is exactly what turned platform-agnostic entitlement enforcement into a multi-week problem instead of a flag flip. Every release now gets an explicit "look at what's already here before adding to it" pass, no exceptions for how small the change feels.

On the product side, we learned that a differentiator only counts if it's stated as a mechanism, not a category. "Family meal planner" reads identically to a competitor who doesn't actually track each person's needs separately — it only became a real differentiator once the copy said the specific thing nothing else in the market was saying plainly: each person's own diet, honored individually, in one shared plan.

And on the personal side: putting real, unscripted things out into the world — asking a friend if her own Facebook post could be reused, writing publicly about a stuck bug instead of only the wins — consistently outperformed anything polished or pre-written. One honest, unprompted testimonial did more for this project than any graphic we designed to look like one.

What's next

The most immediate work is finishing what's already underway: turning accepted plans and swap history into real personalization, so a household's plan actually reflects what they've kept, swapped, and requested over months of use — not just their settings page. That's the redesign already scoped in detail; the remaining work is shipping it.

iOS is the next open question, not yet a commitment. Checked Out is Android and web today; a number of current paying households are on Apple devices, using the web app in the meantime, and their existing ratings and goodwill would be the cheapest real signal for whether a native iOS app is worth building next — rather than guessing at a second platform before knowing if it moves anything.

Longer-term, there's a coach- and dietitian-facing version we explored and set aside — real pitch materials and a spec exist for it, even though it's not being built right now. It's a dead end for the moment, not a closed door.

And underneath all of it: growing past seven paying households, the same way every one of them showed up — one real household with a real, specific set of needs at a time.

Built With

Share this project:

Updates

Submission history