What a complete non-coder in Japan learned building, launching, and charging for a real product using only prompts — and an AI partner.
I am not an engineer.
Before this project, I had never built an app, never written production code, and honestly, never expected to ship anything that strangers could pay for.
In November 2026, I launched my first product anyway.
It's called Ippin Log — a food log that doesn't record restaurants with stars, but records a single dish by its taste.
Not "this place was 4.2 stars."
But: light vs. rich, thin noodles vs. thick noodles, crisp vs. chewy.
Every genre — ramen, curry, and seven others — gets its own two-axis taste chart. Over time, your logs become a map of your own palate.
I built it entirely by prompting an AI app builder (Bolt.new), with a second AI (Muse) acting as my strategist, editor, and memory. I was the product manager, the tester, and the only user researcher.
This is what that actually looked like — not the highlight reel.
1. The idea was smaller than I thought it needed to be
I didn't start with "an app."
I started with a frustration: star ratings tell you what other people liked. They don't help you remember what you liked, or why.
A bowl of ramen can be perfect for me because it's light and the noodles are thin — and terrible for someone who wants the opposite. A single number erases that.
So the core decision came first, and it never changed:
Record the dish, not the store. Record the taste, not the score.
Everything else — the forms, the charts, the nearby feature — had to serve that one sentence. When you can't code, that sentence is your most important tool. AI will happily build ten features in ten directions. Your job is to say no.
2. Prompting is not "one magic prompt"
The fantasy is: type an idea, get an app.
The reality is closer to managing a very fast, very literal junior builder who forgets context and sometimes confidently tells you something is fixed when it isn't.
What worked for me:
Bundle small fixes, split hard ones.
Small UI fixes work best when grouped by area and sent as one request. But the hardest item in a bundle will quietly get dropped. I learned to send difficult changes separately, one at a time, and verify each one on the live, published version — never on a preview, never on the AI's summary.
"I fixed it" means nothing. The live number means everything.
More than once, a summary said a change was done and the public version showed otherwise. My rule became embarrassingly simple: If I didn't see it on the published app, it didn't happen.
Publish is a step, not an afterthought.
I forgot to press Publish more than once and then wondered why nothing changed. Now it's a mantra: fix, publish, verify — in that order, every time.
None of this requires coding skill. It requires stubborn verification. That turned out to be the real job.
3. The parts nobody warns non-coders about
Building the screens was maybe 40% of the work.
The other 60% was everything around them:
- Setting up payments for real: switching Stripe to live mode, creating real prices (¥300/month, ¥3,000/year), connecting webhooks, and then making an actual payment myself to prove a real user could become a paying member.
- Writing the legal pages a paid service in Japan needs — and deciding not to print my home address and phone number publicly, using the "disclosed promptly on request" approach instead.
- Designing the free/paid line: I raised the free limit from 10 to 40 posts, because free users aren't just free users — in a local-discovery app, their logs are the data that makes the product valuable for everyone nearby.
- Creating accounts, icons, and a social presence under a developer name, so this first app wouldn't be the ceiling for the next ones.
AI helped draft almost all of it. But every decision — price, limits, what to disclose — was mine to make and mine to live with. That's the part that felt most like becoming a founder, not a prompter.
4. Launch day is quiet. Then the real work starts.
I launched on November 11.
No flood of users arrived. Of course they didn't — nobody knew it existed.
So I became my own seed data. My plan is to personally log 200+ dishes I've actually eaten, one by one. No fake entries, no restaurants I haven't been to. If the nearby chart is going to show real food from real visits, it has to start with honesty, even if it's slow.
That changed how I think about "building in public," too. I don't reveal the whole product at once. I share it in small pieces — one feature, one lesson, one screenshot (with store names blurred) at a time. It protects the idea while it's fragile, and honestly, it gives people a reason to keep following.
Distribution is now my biggest unknown. I can build the product. Getting strangers to try it, and keep using it, is a completely different skill — and I'm learning it from zero, just like I learned the building part.
5. What I'd tell another non-coder starting today
- Pick an idea you will personally use 200 times. You'll be your first and most important user for a long time. If you wouldn't seed it yourself, don't build it.
- Write your one-sentence core down and defend it. AI expands scope for free. Restraint is your paid feature.
- Verify on the live product, always. Summaries lie politely. Published numbers don't.
- Budget for the boring 60%. Payments, legal, accounts, pricing. That's what turns a demo into a business.
- Don't wait to feel like a "real developer." I still can't code. I have a live app, a live payment, and a paying customer — my first one was me, and it still counted, because the system worked end to end.
What's next
Ippin Log is live at ippinlog.bolt.host — but a fair warning: it's Japan-first and Japanese-only for now. The site opens anywhere in the world and Stripe accepts international cards, but the interface, taste axes, and legal pages are all in Japanese, and the nearby feature only has data where users actually are. An English version is on the roadmap, not in the app yet. For now, overseas readers will get more from following the build log than from trying to use the app itself. I'm focused on seeding real logs, improving it in small verified batches, and learning distribution in public.
And I'm already prototyping a second idea — a small puzzle game — this time working even more directly with AI on the code itself, because I learned exactly where a no-code builder helps and where it gets in the way.
If you're a non-coder sitting on an idea because you think the door is closed:
It isn't closed anymore. It's just a different door. You don't walk through it by learning to code first.
You walk through it by deciding clearly, prompting carefully, and checking everything yourself.
— suikeke, indie developer, Japan
X: @suikeke_dev / App: @ippinlog
