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
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?
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.
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.
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?