
Anti Noise Feynman
Read it later, Flashcards, Feynman technique, Learning
FYI: I'm not a developer. Before this, I'd never once opened Xcode, RevenueCat, or Neon... like, ever. For real.
You've seen the tweets: "I built a full app in 3 hours with AI." Cool story. Here's what actually shipping one looks like — and it wasn't 3 hours.
Here's my scoreboard, and I still can't quite believe it:
11 days from empty folder to App Store submission
47 commits, 9,109 lines of Swift, 123 files
~55 hours at the keyboard... which was basically me yapping at an AI
12 different AI agents (planner, coder, debugger, code-reviewer, designer, doc-writer, and a whole squad more)
4 Apple rejections, 1 human, 0 lines of Swift written by hand
And yet — here we are.
https://apps.apple.com/us/app/anti-noise-feynman/id6770808616
About
We live in a feed designed to make us consume endlessly and retain nothing. I wanted a small, healthy hit of dopamine each day—the kind that comes from actually learning something simple using the Feynman technique.

64 Comments
That scoreboard is useful because it separates "AI can generate code" from "a real app has trust boundaries."
For a first iOS app, the next pass I would do is pretty mechanical: make sure RevenueCat is the only source of truth for entitlements, no API keys or Neon connection strings are sitting in the app bundle, deletion/export behavior is clear for saved notes and flashcards, and any AI-generated summaries or cards are treated as user data rather than disposable cache.
Also worth keeping a one-page release checklist for each Apple rejection: what changed, what data path it touched, and what you re-tested. That tends to catch the boring issues AI agents miss while you are moving fast.
What jumps out isn't the 11 days, it's "0 lines of Swift written by hand" sitting next to "4 Apple rejections." That combo is the real headline: building got cheap, the gatekeeping and the last mile did not. As more non-developers ship the way you just did, the thing that used to be scarce, the ability to build at all, stops being the moat. What's left is distribution and taste: deciding what's worth building and getting it in front of people who care. I back early founders and I'm already seeing this shift. A working app is table stakes now, the hard part is everything after approval. You cleared the build wall most people never get past. The next wall is getting anyone to know it exists. Congrats on actually shipping, that alone puts you ahead of most of the tweets.
55 hours sounds right. i've been tracking this on my own builds and the 'define what done looks like' step alone eats 3-4 hours before a line of code. nobody screenshots the briefing work.
The honest scoreboard is the useful part here. I’d add one more line next time: cost and context per milestone, like first green build, first TestFlight, first rejection, and first live user. That makes it much easier to see where Claude actually compressed the work and where the founder judgment still had to carry the product.
I NEED A TRUSTED CRYPTO HACKER THAT CAN RESTORE LOST OR SCAMMED FUNDS.
Are you struggling to get back the money you lost? Every day, countless individuals face the devastating impact of scam operations that drain their hard-earned savings. But there’s good news – GEO COORDINATES RECOVERY HACKER are here to help you recover what’s rightfully yours. I lost my entire savings to a fake crypto investment scam while I was looking for a way to double my savings. After many weeks of trying to find a way to get my money back with no success, I finally came across a crypto recovery company GEO COORDINATES RECOVERY HACKER, a reliable and trustworthy crypto recovery company. I'm immensely grateful for his dedication, professionalism, and unwavering support. You can get in touch with them through below contact details
WhatsApp ; +1 ( 318 ) 203-3657
I had to send out my review also. They are indeed recommendable.
AI tools have evened the playing field in launching software products.
I think the next hurdle you may face is in maintainability and scalability. I'm curious how the software will grow as your customer base does
The 11-day timeline rings true. The hidden cost people underestimate is context management — when you're working with AI agents across 47 commits, keeping each agent grounded in the current state of the codebase becomes its own full-time job. The 4 Apple rejections probably had more to do with that drift than with Swift itself. Curious what your debugging agent's system prompt looked like — did it have access to the full file tree or just the failing test output?
The useful number here is 55 hours, not 11 days. AI makes the first draft cheap, but the real work shifts to orchestration: keeping context clean, testing every handoff, and building a rejection/debug loop. For non-dev builders, I'd budget twice as much time for review and platform edge cases as for prompting the initial code.
Mucha razón es un horror, yo llevo codificando dash (un asistente de IA que hace trabajos por mi) mas de 2 meses y aunque e terminado ya el MVP he tenido un montón de imprevistos como que cursor no guardo muchos cambios que izo en el código y lo revise y faltaban muchísimas cosas. Todo lo que he aprendido por si os sirve de algo lo documento en mi cuenta de X: @dash_ia
"0 lines of Swift written by hand" is the line I'm stealing. I'm 35 days into building a partnership OS for indie hackers — same Claude Code workflow, TypeScript side. Yesterday I shipped 4 PRs in one day. Today's first hour was spent un-breaking 2 of them because GitHub silently merged into wrong branches in a 4-deep stacked-PR cascade. The "3 hours with AI" tweets never include the morning-after cleanup. Congrats on the ship.
11 days is amazing time for someone who isn't a developer. I am also not a software developer, zero experience with VS Code, etc. Yet, I am interested in building an app of my own. I'm a solo builder and have spent the last 8 months working toward a finance app. So your 11 days is a great time record and congratulations. I am definitely in the 3 digits for commits. Good luck with your launch!
11 days is actually fast for a non-dev's first shipped app. I've spent longer on weekend features for my PM tools that had way less complexity. the '3 hours' guys built hello world, you shipped a product.
11 days is actually fast for a non-dev's first shipped app. I've spent longer on weekend features for my PM tools that had way less complexity. the '3 hours' guys built hello world, you shipped a product.
I thought submitting to the App Store was painful. Then we got an account over on Microsoft Store. I was so young, so naive.
Resonate hard with this — just shipped a Claude-built MCP myself. The "vibe coding in 3 hours" myth glosses over the long tail: edge cases, distribution, documentation, the 8 directory submissions, license file getting GitHub to detect it. The core product comes fast; the surrounding work doesn't. Curious — what surprised you most about the time sink?
The number that matters here is not 11 days or 3 hours. It is 4 rejections and 0 quits. I have watched a lot of people start building with AI this past year, and the ones who ship are not the ones who code fastest. They are the ones who treat a rejection as a step instead of a verdict. The tools collapsed the cost of building. They did not touch the cost of finishing.
One question since you ran 12 agents: did you ever hit a point where coordinating them cost more time than just doing the task in a single thread? I see a lot of people add agents well past the point of return.
The whole thing — the app, the website, SEO, the store images, all of it — came in at under $80 total. For everything I got out of it, that feels pretty reasonable.
I'm also looking at bringing in Codex and a few other models alongside Claude to push that cost down even further — matching the right model to the right task instead of leaning on one for everything.
The "11 days vs 3 hours" gap is so real. I think the viral "build an app in X hours with AI" content is genuinely harmful to new developers because it hides all the invisible work — understanding the domain, making product decisions, debugging edge cases that AI gets confidently wrong.
I'm in the middle of validating an idea right now (Chrome extension for AI users) and what's taking the most time isn't coding at all. It's figuring out the right problem to solve and who exactly has it. AI is incredibly fast at execution once the thinking is done, but it can't do the thinking for you.
How much of those 11 days was product/design thinking vs actual development? Curious if the ratio surprised you.
You nailed it on all fronts.
On the "3 hours" content — yeah, it's genuinely harmful. It manufactures FOMO feeling.
And I completely agree on the thinking being the hard part. Figuring out what problem you're actually solving, whether the audience is big enough to matter, how you'll grow, how you'll hit product-market fit — that's the stuff that deserves the most focus, and it's exactly what AI can't do for you. It's lightning-fast at execution once the thinking is done, but it can't do the thinking.
To answer your ratio question honestly: for me a lot of the early time wasn't even product/design thinking in the polished sense — it was just proving to myself that a non-tech person like me could even get an app onto the store with AI. I didn't believe it was possible at first. So I deliberately picked a fast, simple idea I already had in my head, just to test whether the whole path was real. Once I saw it was, the thinking-vs-building ratio made a lot more sense.
That reframe really lands — it wasn't "design thinking" in the formal sense, it was just overcoming the internal skepticism that it was even possible. That's a real phase of the work that nobody talks about.
And the deliberate choice of a simple first idea to prove the path is smart. Reduces the variables so you can actually learn something. Thanks for being honest about it — that's the part that's actually useful to someone starting out.
This is so real. And the part nobody talks about — shipping fast also means shipping with bugs. I'm a QA engineer and the number of launched products with broken forms, mobile issues, and checkout errors is wild. Great honest post.
This is very encouraging. It took me 2 months to build a special kind of document. I'm actually an author and don't know much about coding. Now the big challenge... to get my idea into a phone and put it on Google Play
Come on buddy, you can do it
Thank you, just what I needed to hear today! At least the code is written for the laptop. At least it's a start
genuinely curious what the hardest part was that no AI could just solve for you. because 55 hours at the keyboard with 12 agents still means a lot of decisions that required a human to make a call. was it the product decisions, the Apple review back and forth, debugging something the AI kept getting wrong, or something else entirely. that's the part of these stories that would actually help someone attempting the same thing
I understand your point
Its truly a great journey, from being a vibe-coder to the person who launched an app.
could you share your story of how you got here?
You can check more details here bro https://x.com/HuyTM11/status/2060000078707003638
Damn, got the exact answer i needed. Thank you.
the 12 different AI agents thing is underrated here. most people open one chat window and expect it to do everything. the fact that you broke the work into distinct roles — planner, coder, reviewer, debugger — that's not just "using AI," that's workflow architecture. and it's a skill that has basically zero formal training out there.
also 11 days from zero Xcode experience to App Store is wild regardless of tooling. the 55 hours and 4 rejections are the honest version of what "vibe coding" actually looks like in practice.
The 55 hours number is the most honest thing in this post — and it's the part everyone glosses over. Building with AI is fast until it isn't, and the skill gap isn't learning to code, it's learning to recognize when Claude is confidently wrong and knowing how to course-correct without blowing up the whole context. The 4 Apple rejections also resonated hard; provisioning profiles and guideline 4.3 issues are basically invisible until you hit them, and no AI can fully prepare you for that. Congrats on shipping — 11 days non-developer to App Store is genuinely impressive regardless of the tooling.
gfr
4 Apple rejections hit different lol. People see the "built an app with AI" headline and think it's a smooth ride. The rejections, the debugging, the 55 hours of just figuring things out, that's the real story. Congrats on shipping it, that's genuinely impressive for someone who'd never opened Xcode before.
Yes. I create site minimum in 2 weeks, no 3 hours. But this is very interesting! I wait for Google to index it!😅
Gud luck bro
I think the "built in 3 hours" stories often skip the hardest part: getting something production-ready.
The coding itself may be fast with AI, but debugging, handling edge cases, App Store reviews, user testing, and polishing the experience still take real time.
I'm seeing something similar in the website space. AI can generate a website quickly, but making it maintainable, portable, and ready for real users is where most of the work happens.
Out of curiosity, what was the biggest bottleneck during those 11 days? Was it the AI-generated code quality, Apple approvals, or figuring out the overall architecture?
with 12 agents and 0 lines by hand, curious how you sanity-checked the security side. the obvious traps in a paid iOS app are how the RevenueCat webhook verifies its signature and whether any keys got bundled into the binary. claude tends to write code that works on day 1, but doesn't always get those bits right. they're invisible until something goes wrong months later. did any of the 12 agents own that lane?
This resonates completely. I'm building Anthilia — a personal finance app for tracking recurring fixed expenses — with Claude as my primary coding agent. No CS background, just a problem I needed to solve.
The "3 hours" narrative is damaging because it sets the wrong expectations. What AI actually gives you is the ability to ship something you couldn't have built at all before — but the decisions, the debugging, the "why is this broken at 1am" — that's still 100% on you.
How did you handle the moments where Claude gave you confidently wrong answers? That's been my biggest learning curve.
On the confidently-wrong-answers problem — that was my biggest learning curve too. A few things that helped me:
Break the work into small chunks. The smaller the piece I let the AI work on, the easier it was to spot when something was off. Big sweeping changes are where the confident garbage hides.
QC everything yourself. I never just hit enter to accept every command the AI suggested. I'd stop and ask it to explain what it was doing — is this actually following the rules I set? Why this approach? Treating it like a junior dev whose work I have to review, not an oracle.
Keep a plan and a daily journal. Having a clear plan to check against meant I could catch when the AI drifted off course, and the journal let me review what happened each day.
That whole "question everything" habit is honestly why I ended up asking the AI something like 200 questions over the build. It felt slow in the moment, but it's exactly what kept the confidently-wrong stuff from making it into the final product.
Good luck with Anthilia — recurring expense tracking is a real problem worth solving.
The "junior dev whose work I have to review" framing is exactly right — and it took me longer than it should have to internalize it. Early on I was accepting outputs too quickly, then spending twice as long debugging something I could have caught in 30 seconds if I'd just asked "why this approach?"
The journal idea is interesting. I ended up solving the drift problem differently — I maintain three source-of-truth documents that travel with every session: project context, agent specs, and a running status file. Each agent (I use a multi-agent setup — frontend, backend, QA, legal, etc.) gets briefed from those files at the start of every session. It's more overhead upfront but it means the AI never loses context across sessions, which is where a lot of the confident drift happens.
"Recurring expense tracking is a real problem worth solving" — that's what I'm trying to confirm. The product exists, the waitlist is open, now I need to find out if it's just my problem or everyone's problem. That's the honest answer at this stage.
The 12 agents part caught my eye. We run a portfolio of 10+ apps and the non-obvious lesson we learned is that agent count multiplies cost non-linearly. Most multi-agent setups default every agent to the same model tier regardless of what it's actually doing. Your debugger agent and your doc-writer agent have wildly different complexity requirements, but they're probably both burning frontier-tier tokens. Matching model to task cut our AI spend by about 60% with zero quality regression on the output that actually mattered. The other real thing nobody tweets about: Apple rejections. We had apps rejected 3-4 times each across our portfolio. 90% of first-time rejections come from three things — missing Sign in with Apple, inadequate privacy nutrition labels, and guideline 4.3. All fixable, all completely invisible until you've been through them once. 11 days as a non-developer is genuinely impressive. The "3 hours" posts are engagement bait — real shipping has friction that AI can't abstract away yet.
Thanks so much for this — genuinely one of the most useful replies in the thread.
The point about agent count multiplying cost non-linearly really lands. I built 100% with Claude initially, but you've articulated exactly the direction I'm heading: diversifying across models so each task runs on the right tier. Two reasons — first to control cost, and second for better performance, since not every task needs frontier-level horsepower anyway.
Really appreciate you.
the 55 hours number is the honest part that most "I built X with AI" posts leave out. the real skill here isn't getting Claude to write Swift — it's knowing what to tell it, catching when it writes garbage, and handling the 4 Apple rejections. that's 55 hours of product management and quality control, not coding. most people miss that distinction.
Yeah, that's the truth right there. FYI I ended up asking the AI something like 200 questions to get everything done.
Crazy what AI can do nowadays!
Congratulations on completing the app. Shipping a fully functional app does take its time at present conditions, even if AI is being used. You have to iterate, reiterate and tweak the app features until you get what you want in the app. I am wondering what were the Apple store rejections were about? How did you finally get accepted? I would like to know your process since I myself would like to build apps in the near future.
Thanks, and good luck with your own build — it's a fun process once you get into it. For me, the two things that mattered most when dealing with rejections came down to:
1. Fix exactly what Apple flagged — don't try to cheat it. It's tempting to look for a workaround or a clever way around the rule, but their reviewers test on real devices and walk through your actual flows. The fastest path to approval is just addressing the specific guideline they cited, honestly and completely. Trying to sneak past it usually just earns you another rejection and more lost days.
2. Write detailed review notes. This one's underrated. In the notes section, I explain each feature clearly and give step-by-step instructions so the Apple tester can actually understand what the app does and how to use it. If anything needs a login, I include demo credentials. The reviewer only has a few minutes with your app — the easier you make it for them to "get it," the smoother the review goes.
Honest post, respect for shipping it.
The flip side: I'm a developer and it still took me 6 months to ship OwnAutoCare (iOS + macOS + Android with Flutter). The "3 hours" myth hurts both sides.
@Eva — the context drift problem is real. What solved it for me was structured agents with specific domain knowledge baked in (architecture, implementation, testing, security) instead of bouncing between generic agents. Each agent only sees what it needs. Less drift, fewer tokens, more predictable output.
On Apple rejections: I had 1 — for including Google login without adding Sign in with Apple. Apple requires it if you offer any third-party login. Painful because no tutorial mentions it.
I went the same route you did for the drift problem — structured agents with specific domain knowledge instead of bouncing between generic ones. Made a big difference.
One other thing I ran into: I try to keep sessions from running too long now. Anything past 4–5 hours and the AI seems to start losing the thread — context just degrades the longer a single session goes. Wrapping up and starting fresh (with the docs/journal to get back up to speed) ended up being more reliable than pushing through one marathon session.
Also — congrats on getting the app shipped! That's the hard part done, now comes the fun part: growth. Feel free to drop the app link here, I'd be happy to support with a review on the App Store if it helps.
Thanks! Totally agree on the session length. My fix: I treat each command as a fresh conversation — I clear the context between commands so each one starts clean. Combined with a common errors doc and a technical debt doc that agents consult at the start, there's no drift and picking up where you left off is fast.
App is OwnAutoCare — free car maintenance tracker where your data lives in your own Google Drive or iCloud, no backend servers. Just search "OwnAutoCare" on the App Store if you want to check it out.
A review would mean a lot, genuinely — still early days. Thanks!
4 apple rejections is the realest milestone on that list lol. those 'built a full saas in 3 hours with ai' engagement bait tweets completely skip the absolute integration hell of configuring bundle ids, provisioning profiles, and debugging custom revenuecat webhooks for the first time.
shipping 9k lines of functional swift code as a non-developer in 11 days is still a massive velocity win though. how did you manage the context window drift when bouncing between 12 different agents during deep debugging loops?
Haha yeah, the 4 Apple rejections are the realest part of that whole list.
For the context window drift, my fix was honestly pretty low-tech: I always brainstorm & planned features out ahead of time and kept clear docs, so I had something solid to point each agent back to instead of relying on it to "remember." And at the end of every session I'd have the AI write a quick journal entry — what we did, where we left off, what was breaking — so the next day I could feed that back in and get the agent up to speed fast instead of re-explaining everything from scratch.
Wasn't perfect, but having that paper trail kept the agents (and me) from drifting too far.
having the ai draft its own micro-journal entry at the end of a session is an elite move for fighting context drift. it saves so much cognitive load the next morning.
relying on agent memory during heavy debugging loops is a losing battle, but that quick paper trail keeps the logic boundaries tight. definitely stealing this workflow rule for my next micro-utility build.
I just tried to build a landing page with lovable. and still its not able to add a waitlist
I love how product owner is now product dev and VS. Exiting times
Me too
This is a much healthier framing than the usual “I built this in 3 hours” screenshots.
The first demo can be fast with AI tools, but the real work is usually the messy part: App Store rejections, edge cases, auth, billing, cleanup, and making it reliable enough for someone else to use.
The “4 Apple rejections” part is especially useful because people rarely include that part of the story.
What took the most time across the 11 days?
The biggest time sink across the 11 days was learning to control and understand the AI — knowing what it's actually good at and where it falls short. Early on I let it lead too much and it'd run off building stuff I never asked for or skip my rule. The real lesson was not letting the AI take me too far off course. The human still has to play a big role in the loop — steering, deciding, cleaning up — not just handing over the wheel
“Build an app in 3 hours” is usually marketing, not reality. While AI tools like can dramatically speed up coding, building a real app involves much more than generating code: refining requirements, debugging unexpected issues, handling edge cases, integrating services, testing, deployment, and countless small decisions that only appear once you start building. If it took you 11 days, that doesn’t mean you failed or used the tool poorly—it likely means you were building something real rather than a polished demo. AI can compress parts of development from weeks to days, but turning an idea into a working, reliable product still takes time, iteration, and human judgment.
Yeah Totally agree on that
Recognizing this timeline. I'm a maxillofacial surgeon who shipped an AI-powered reading app and a medical edtech platform out of Ouagadougou —both AI-paired with Claude, all the boring infra decisions included. The 3-hour narrative does real damage. It set me up to feel like I was failing when I was actually just... building. The part nobody tweets: each Apple rejection (or in my case, each Gumroad config that wiped my product files) is an education you can only get by doing it. 47 commits is honest. That's what shipping looks like.
What was your biggest time sink — the 4 rejections, or something earlier in the build?
This really resonates, thanks for sharing. Honestly, my biggest early time sink wasn't the rejections — it was that I had no clue what the right order of operations was for getting the AI to build what was in my head. So I just kept throwing questions at it. Like 200 of them, no joke.
By the 5th Apple submission I was pretty over it, not gonna lie. But that's actually where it clicked. I started getting a feel for how to work with the AI and a more realistic sense of what it can and can't do — it's not magic, it's got real limits. Once I stopped expecting it to read my mind and built an actual workflow around it, updates started flying out way faster.
That shift — from throwing questions at it to having a workflow — is the actual unlock, and you're right that it takes getting burned to find it. The AI can't give you the order. You have to earn that. What got me was realizing the AI is a very good executor and a very bad planner. The moment I stopped asking it what to build next and started telling it exactly what I'd already decided, the whole thing started moving. I ended up writing down that order of operations just so I didn't have to rediscover it on the next project. Turns out the structure is the hardest part to carry over.
Did your workflow survive intact into the next project, or did you have to rebuild it from scratch?