I just wanted to taste AI coding tools. A week passed.
Ten people spent a year shipping CJ ENM's voting app — bugs included. Three years later I opened Claude to taste an old meal-RPG idea. A week later: 544 repo files, docs, an app, a landing page.
I'm not a developer. I'm a generalist who sets direction; AI executes. Design is 6/10. The whole thing still moves.
The product is Foodbook — snap meals, climb from Vagabond to Lord. Not a diet app or social feed. Korean skin is Joseon; global skin is medieval. Same engine, different narrative.
What I'm still unsure about: whether people want the RPG loop or just the "non-dev ships with AI" story. Testing both angles in public.
Landing: https://foodbook.cc/en/
Full honest founder story (7 min read): https://medium.com/p/02e3d40868d7
Trending on Indie Hackers
This mirrors something we see constantly in client work: the first week with AI coding tools feels like a superpower, and it genuinely is. The challenge shows up at month two when the codebase is 500 files, and you need to make a structural change. The tools that got you there fast don't automatically help you understand what you built deeply enough to change it safely. The teams we work with at Ailoitte that get the best results treat AI coding as force multiplication on existing engineering judgment, not a replacement for it. The ex-PM building solo with Claude is a real story; the question is whether week 5 looks like week 1. What does your architecture look like for the meal RPG? Curious if you've hit any walls on the logic layer yet.
It’s definitely a superpower at the start, but long-term maintenance is where the real work happens. Treating AI as a tool to support engineering judgment rather than a complete replacement seems to be the key for complex projects.
Love the "force multiplication on judgment" framing — that's the shift I'm in right now.
Meal RPG: photo → verified meal slot → rank climb (Vagabond → Lord) → tier-gated boards. One rules engine, Joseon skin for Korea, medieval for global. The logic that actually bites: time windows, fortune-wheel thresholds, bowl inventory for community — AI scaffolded all of it; changing any of it without re-reading the plan docs is how you ship a bug at 2am.
Ex-PM solo with Claude is real. Week 5 ≠ week 1 for me — less velocity, more "what am I actually changing." Curious how your Ailoitte teams document comprehension so month two doesn't become archaeology.
Same boat — I'm a solo builder shipping with Cursor as my execution layer, no traditional dev background. Two things from further down the road that might help.
On comprehension debt: the fix that worked for me wasn't more docs, it was a hard architectural seam. I keep one state file at repo root as the single source of truth for what every piece does and why — when month-two breakage hits, I read that, not commit history. Your "same engine, multiple lores" instinct is right: let AI churn the lore skins freely, write the engine slowly and read it line by line.
On the RPG-vs-builder-story question — I'd watch that second-meal-log signal over signups, hard. I've shipped things that got curiosity traffic from the "how I built it" angle and almost none of it converted to actual use. Builder-story audience and product audience barely overlap. "Logs a second meal without a nudge" is the metric that tells you the loop is real. Rooting for it.
The distinction between curiosity traffic and real product adoption is a huge reality check. Tracking that unprompted repeat action is such a clean way to measure true value over initial hype.
This hit home — especially the second-meal point.
I'm getting waitlist signups from the builder-story angle right now, and I'm trying not to treat that as product signal. Your line about curiosity traffic that never converts is exactly the trap I'm watching for.
The architectural seam tip resonates too. I'm working toward one compiled state file at repo root that the agent reads first — lore and docs can churn elsewhere, but the engine gets written slowly and read line by line. I'll know if I did that well enough when month two hits.
"Logs a second meal without a nudge" — I'm using that as the beta metric. Thanks for pointing me at the right number. I'll report back.
Love it — and please do report back, I'm curious whether the second-meal signal holds once the cohort grows. That "observer vs player" split a couple comments down is worth baking into your form too; counting them separately early saves you from misreading a churn problem as a retention one later. Good luck with the beta — sounds like you're asking the right questions, which is most of the battle this early.
Will do — I'll report back once the beta cohort is big enough to mean something.
The observer/player split is a good catch. Q3 on my form is close but fuzzy ("founder story" vs "beta access") — I'll sharpen it so I can segment from day one instead of retro-tagging.
Thanks for sticking around on this thread. Most of the battle, maybe — now I need a few people to log meal #2.
The “non-dev ships with AI” angle is the real product right now — Foodbook is proof of concept for that story more than it is a meal app. That said, don’t pick one angle. The RPG loop is what makes someone open the app tomorrow. The builder story is what makes someone download it today. You need both working together. I’m in a similar position — building multiple products with Claude and Cursor as my technical layer, no traditional dev background. The hardest part isn’t shipping anymore. It’s figuring out which problem the product actually solves once it exists. What’s the retention looking like on the RPG loop in early testing?
Fair point on not picking one angle — that's where I landed too. The IH post is the front door; the RPG loop is what has to earn day two.
On retention: too early to call it. Closed beta just opened — one real user through onboarding so far, waitlist still tiny. What I'm watching first isn't D7 yet; it's whether someone logs a second meal without a nudge. If that doesn't happen, the builder story got us downloads but the loop didn't stick.
Curious how you're splitting "process audience" vs "product audience" across your products. Sounds like the same tension.
One thing I’d validate alongside the RPG-vs-builder-story split: where the AI coding process is creating ongoing maintenance risk. The week-one win is speed, but the month-two failure mode is not knowing which files are expensive to touch, which prompts are causing churn, or where the same bug keeps getting reintroduced. If you keep a tiny build ledger while you ship, repo area, model/tool used, why the change happened, and what broke later, you’ll learn faster than from commit history alone.
This resonates. Week-one speed hides month-two fragility — I've re-broken the same onboarding edge twice because I forgot why a guard existed.
I'm starting a tiny build ledger: area touched, model, intent, what regressed later. Not full docs — one line per risky change. Separately I'm dogfooding a "cockpit" in the repo so agent sessions patch SSOT instead of scattering notes across chats.
Would love to see what fields you actually keep in yours once the list gets long.
On your open question — what to validate first:
Since you've already worked out that the loop is the product and the AI story is just proof, the next question is whether your current signup list is capturing people who want the loop. IH signups arriving through the 'non-dev ships in a week' frame are mostly curious about your process — which is valuable for reach, but a different population than someone who wants to log meals and watch their rank climb.
The real validation bet: one qualifying question on the form ('what brought you here — the AI build process or the RPG mechanics?') tells you what mix you're actually collecting. If most answers are 'AI process,' the product hasn't found its channel yet — which is fine, but worth knowing before onboarding a beta cohort that may churn early.
Building Waitrocket, the question we keep returning to is whether early traffic represents target users or observers from the launch channel. You can have both on the same list — but they need to be counted separately to tell you anything.
This is the question I'm trying to answer before the next beta wave.
The form already has "What interests you most?" — beta access / meal RPG / founder-AI story / just curious — plus UTM by channel. Early read: IH skews toward the build story; Medium skews more mixed. Small N, so I'm not trusting the ratio yet.
Your framing is sharper though — observer vs player. I may tighten Q3 to force that split instead of letting "just curious" hide the difference.
How are you tagging Waitrocket signups today — one field, or channel + intent separately?
the comprehension-debt point in memolife23's comment above is the actually-important warning here, and i'd take it seriously. the month-2 'something breaks in code i didn't write' moment kills most ai-built side projects. for your specific case, having two narrative skins (korean joseon + medieval) sharing the same engine is the more interesting bet than the rpg-mechanic-vs-ai-narrative debate. lean into 'same engine, multiple lores' as your differentiator, that's what's actually hard to copy.
Thanks — this landed harder than the mechanic-vs-narrative thread.
The comprehension-debt warning is the one I'm taking seriously. Week 1 feels like magic; month 2 is when something breaks in code I didn't really write, and I can't trace why. That's the kill screen for most AI-built side projects, and I'm trying to design against it early — smaller surface area, one loop I can explain without the model, docs I actually re-read.
On the product bet: yes. Same engine, multiple lores — Joseon skin for Korea, medieval skin for global — is the part I'm leaning into. The meal-log → rank-up loop stays fixed; the worldbuilding swaps. Hard to copy as a vibe, easier to copy as a feature list.
Appreciate you naming the thing that actually matters.
Exactly — and "same engine, multiple lores" is also what keeps the comprehension debt survivable. The lore skins are cheap to regenerate, so let the AI churn those freely; the engine is the one piece you'll still be debugging at month two, so that's the part worth writing slowly and actually reading line by line. If you treat the engine/lore boundary as a hard architectural rule, the AI-built risk shrinks a lot. How cleanly is that seam separated in your current build?
I'd push back gently on one line: 544 files in a week is the easy half. The bill comes around month two, when something breaks in code you didn't write and can't yet read — as a solo dev I've lost whole evenings to AI-generated logic that looked fine until it wasn't. Not a reason to slow down, just budget for the comprehension debt early. And my bet on your real question: the "non-dev ships with AI" story will out-pull the RPG loop here — this crowd is builders, not eaters. The food game is your proof; the process is the hook.
Fair pushback — and you're probably right about month two. I haven't hit a full "lost evening" yet, but I can feel the comprehension debt stacking: 544 files I didn't type character by character. Budgeting for that early is the part I underplayed in the post.
Your bet lands for me. The meal RPG is the artifact; the "ex-PM who didn't mean to ship" thread is what people actually reply to. Builders over eaters — noted. I'll lean into the process hook and keep the game as proof, not the headline.
This is probably the most relatable AI-builder story I've read lately.
A lot of people think AI coding tools magically remove all the hard parts. In reality, they remove some coding friction, but they often create new challenges around architecture, debugging, and decision-making.
The biggest win isn't that AI writes code. It's that it lowers the cost of experimentation. You can test ideas in days instead of weeks.
The founders who win will likely be the ones who combine domain knowledge with AI, not the ones who rely on AI alone. Great write-up.
This resonates — a week in, the surprise wasn't "AI wrote the code" but how fast I could spin up experiments (and how quickly new problems showed up: architecture, debugging, what to build next).
Domain knowledge + AI feels like the real combo. Thanks for reading.
100% agree. That was my experience too while building my own SaaS. AI helped me move much faster, but the biggest challenges quickly shifted from writing code to architecture, debugging, and deciding what to build next.
The real superpower of AI isn't generating code—it's reducing the time and cost of experimentation. You can validate ideas incredibly fast, but product judgment and domain expertise still make the difference.
This matches what I'm seeing in week one. Velocity went up; the bottleneck moved to "what's worth building" and "why does this break." The experimentation tax dropped — the judgment tax didn't.
Glad it's not just me. Curious what you shipped and where architecture bit you hardest.
Same experience here.
I'm building AppLaunch, which helps local service businesses launch their own branded mobile apps without the typical agency cost. The coding part moved much faster with AI, but the harder questions quickly became product-related.
The biggest challenge wasn't building features—it was figuring out which businesses would actually change their workflow and get enough value from having an app. On the architecture side, keeping the platform flexible enough to support different service businesses without turning it into a mess has probably been the hardest part so far.
One thing I'd be careful with:
The interesting question may not be whether people want the RPG loop or the AI-builder story.
The harder decision could be which one deserves to carry the product when those two stop reinforcing each other.
That sounds subtle, but it can quietly shape everything that follows.
That's the sharper question — and yeah, I'm holding it deliberately.
Right now the two reinforce each other: the AI story gets attention, the RPG loop is what has to keep people. If they stop reinforcing, the loop wins. The builder narrative is proof I can ship, not the product.
Still early — waitlist and beta will tell me if "climb from Vagabond through meal logs" sticks without the "built in a week" frame.
Appreciate you naming it. Most replies stop at "cool AI project."
Possibly.
The reason I'd still be careful is that I don't think the interesting part is the waitlist or the beta itself.
I think there's a bigger decision sitting underneath that.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll send over the tighter version.
Happy to answer questions — especially from other non-technical founders trying AI coding tools. What would you validate first if you were in my shoes?