- One person, alongside a full-time job, took an AI iOS app from a clickable mockup to App Store submission in 30 days, roughly 200 hours of work.
- The whole thing is real: 1,116 commits, ~444,300 lines churned, 33 screens, 18 backend functions, a landing site, payments, and AI analysis. Live today in 175 countries.
- The backend was thrown out on day 6. That single pivot is probably the only reason 30 days was enough.
- There were zero automated tests. Quality assurance was three AI audits run by 30 agents burning about 1.65 million tokens, which surfaced ~70 issues before ship.
- The point is not that AI wrote an app. It is how much discipline it takes to make AI do unique, production work at scale. The bottleneck is decisions and verification, not code.
I am not a developer. I build apps and services with AI, and they work. But I had never shipped anything to an iPhone. Not a progressive web app, not a home-screen shortcut. A real app, the kind that has to pass Apple review.
A phone app was one of those things you talk about over coffee and never deliver. So I gave myself a rule and a clock: build it alone, after hours, in 30 days, and submit it to Apple. On June 16, 2026, I did. Eleven days later it was live.
This is the honest version of that build. Not the highlight reel, the whole thing: the pivot that nearly ate the month, the file I touched 108 times, the funnel hole that could have cost real money, and the reason the code was never the hard part.
What Tymbre actually is
Tymbre (say it TAM-ber) is an AI coach for public speaking. You record a short talk, and it reads not only what you say but how you say it and how you stand: pace, tone, conviction, body language. It scores you on five dimensions, then hands back specific things to change, private, on servers in the European Union.
The five dimensions are its own method, CLEAR: Cadence (your pacing and rhythm), Lift (energy and dynamics), Expression (tone and color), Authority (conviction and presence), and Resonance (how it lands). Instead of dry metrics, it gives somatic cues, actual physical moves to make, not just numbers to stare at.
It is not a simple recorder. Three presence modes cover Audio (voice only), Frame (face and eye contact), and Stage (full body). A question-and-answer simulator throws the personas of a hard audience at you. Monthly limits are enforced server-side across three tiers (Solo, Speaker, Master), with real payments behind them. And it is private by design: no trackers, no advertising identifier, no tracking-consent prompt at all, with personally identifiable data scrubbed before anything reaches the logs.
That is a full product: an iOS app, a serverless backend, a website, payments, push notifications, and AI analysis. Built solo, in a month. So how.
Day 0: the mockup was the spec
Before a single line of code, there were mockups. Not a description in a document but clickable screens, built in Claude Design. The design was the specification. When the picture is exact, the AI has far less room to invent, and you have something concrete to say yes or no to.
Day 1, those mockups went straight to code in Claude Code. The screens were built on a custom design system, 39 primitives across 4,263 lines, not a component library pulled off the shelf. That is why the brand looks like a brand and not a template. It is more work up front. It is the difference between a product and a demo.
The rules came before the product
The very first commit did not contain a single feature. It contained rules: a CLAUDE.md file, 1,089 lines of instructions for the AI, written before the product existed. Over the month those rules were distilled down to 115 lines, because short and enforced beats long and ignored.
1 · Think before coding: do not guess, do not hide doubt, ask.
2 · Simplicity first: minimum code, zero speculative abstractions.
3 · Surgical changes: touch only what the task needs.
4 · Goal-driven execution: define the success test, loop until it passes.
5 · Done means confirmed: "I pushed it" is not "it works."
6 · Look harder, do not guess faster: a new theory without new evidence is the same dead end.
7 · Change the approach after two failures: a third try with the same method is banned.
8 · Destruction needs deliberation: know the cost, get consent, keep a way back.
9 · A symptom is not a diagnosis: verify the cause against the real state.
10 · Secrets stay secrets: no keys in code, none in logs.
Rules alone are not enough, because the AI forgets between sessions. So the project ran on memory: a .remember system with nine logs holding context across sessions, a PROJECT.md knowledge base of 104 KB, and a STYLEBOOK.md of 16 KB that is the single source of truth for every string of text in the interface. Copy is not written ad hoc. It follows written rules: banned words, punctuation, how the tiers are named. That is the same discipline that keeps this very site consistent, applied to an app.
The pivot that saved the month
The project did not start on Appwrite. The first architecture was a hand-rolled backend: Hono and BullMQ, a Python sidecar for analysis, a database layer, migrations, a Dockerfile, two separate applications for the interface and the analysis engine.
"pivot backend from Hono/BullMQ/Python sidecar to Appwrite"
On May 23, all of it went in the bin. Instead of maintaining a queue and a database and a container by hand, the backend moved to a self-hosted Appwrite. Two applications that had lived for five days simply disappeared. It was the best decision in the whole project, and probably the only reason 30 days was enough.
That pivot is one of the main reasons for the ~444,300 churned lines below. Throwing out a week of work on day 6 feels like failure while you are doing it. It was the opposite. The willingness to delete is what kept the timeline honest.
The code, in numbers
The month, counted from the git log, looks like this: 1,116 commits, 255,699 lines added and 188,620 removed, about 444,300 lines churned through the life of the project. What is left in the repository today is 50,662 lines, which means the project was effectively rewritten about five times over. The average day carried 38.5 commits. The record day, June 2, carried 99. The single biggest commit was 45,832 lines, one large cleanup. One screen, the profile, was reopened and reworked 108 times, the most tortured file in the repo.
The shape of those commits tells the real story of how software gets finished:
| Commit type | Count | What it was |
|---|---|---|
| fix | 413 | The grind. Picking at it until it worked. |
| feat | 164 | New features. |
| docs | 120 | Writing down what was decided. |
| chore | 83 | Housekeeping. |
| refactor | 29 | Making it cleaner. |
| revert | 14 | Tried it, undid it, tried again. |
Four hundred and thirteen fixes. That is not a story of AI writing perfect code on the first pass. It is a story of relentless iteration, which is how anything actually ships.
Quality assurance without a single test
Here is the part that makes engineers wince: there were zero automated tests. There was something else instead. Before launch, the codebase went through three AI audits: 30 agents, about 1.65 million tokens of analysis of the code and its production readiness. They found roughly 70 issues. Every critical one was fixed before the app was submitted.
I work with AI professionally, so this was never about learning the tool. It was about scale: taking on something bigger than anything I had built and giving myself 30 days. And the lesson from that scale is the whole point of this piece. The bottleneck was never writing code. The bottleneck was decisions, verification, and not letting the AI walk me into a swamp. The entire methodology, the rules, the memory, the audits, exists so that one person can hold a team's quality bar.
What got built
Under those three screens is a full product, not a prototype:
| Piece | Size |
|---|---|
| iOS app (TypeScript) | 169 files, 34,286 lines |
| Screens in the app | 33 |
| Interface components | 58, including 39 custom design-system primitives (4,263 lines) |
| Backend functions (Appwrite) | 18 functions, 7,975 lines of Python |
| Landing site | 24 Astro files |
| Custom platform plugins | 3 |
| Files in the repo · file types | 347 · 25 |
Fifteen services, seven languages, one product
A solo build in 2026 is really an exercise in wiring. More than 15 external services had to become one working product, spanning seven programming languages.
| Layer | Services |
|---|---|
| Design and code | Claude Design (mockups), Claude Code (implementation) |
| Infrastructure | Hetzner Cloud, Coolify, Cloudflare (domain, content delivery, firewall), Cloudflare R2 storage |
| Backend and data | Appwrite, self-hosted |
| AI | A hosted multimodal model (one of several the product leans on) |
| Build and shipping | Expo and EAS, Apple App Store Connect |
| Monitoring | Sentry |
| Growth | Apple Search Ads |
| Also wired in | A payments layer, transactional email, product analytics, and social sign-in |
Where the off-the-shelf tools ran out, the project grew its own: 17 custom scripts and plugins. A screenshot pipeline that renders App Store artwork and uploads it through the store's API. A demo-data seeding toolkit that fills the App Review reviewer's account with realistic sessions. An iOS build pipeline with no Expo, written from scratch, one command from prebuild to upload, born the second time the hosted build limit ran out. Automation for the things that could not be done by hand.
Ship, and the messy part after
The 30 days ended at submission. What happened next matters just as much, because a launch is not a finish line.
Two things went quietly wrong after launch, and both are worth telling because they are the kind of thing a solo operator misses.
The first was a hole in the funnel that could have cost real money. The app was available in 175 countries, but subscriptions could only be bought in two: Poland and the United States. So in 173 countries a person could download the app, walk up to the paywall, and find nothing to buy. That gap was closed on July 16, the same day paid acquisition opened across the European Union, the United Kingdom, and Australia, so the Apple Search Ads budget never spent into a dead paywall. The gap is now zero.
The second was a bug that silently killed the scheduled jobs. Appwrite's scheduler has a delta-sync flaw: after the stack restarts, it only picks up schedules changed after its own start time, and ours carried the date of the last deploy. The result was that five scheduled jobs, the cleanups for recordings, exports, and unverified accounts plus the two reminder senders, had been sitting dead since about July 1. Found and fixed on July 15. You do not get a Sentry alert for a job that never runs. You get it by looking.
The cost of hiring it out
Price the same work at 2026 freelance rates, split by role, and it adds up fast: about 80 hours of iOS work, 40 of backend, 30 of design, plus graphics, infrastructure, and release management. Summed across roughly 200 hours, the labor alone lands near $10,000 at Central European rates and around $22,000 at United States rates, call it $17,000 in the middle.
The real cost to the person who built it was their own time, roughly 200 hours, and a few dozen dollars a month for infrastructure. Determination covered the rest. That is not a brag. It is the new math of what one motivated person plus AI can put into the world, and it is exactly why the discipline matters more than the tool.
The lesson, in one line
This is not a story about AI writing me a website or an app. I have shipped a few of those, and they work as expected. This is a story about how much work it takes to make AI do genuinely unique work. The writing of code got cheap. Everything around it, the decisions, the deletions, the verification, the taste, did not. That is where the month went, and that is the job now.
Tymbre is free on the App Store.
The Tymbre build, in full
The complete case study in one printable document: every number, the full timeline, the day-6 pivot, the whole stack, and the cost breakdown, laid out end to end.
- All the metrics, straight from git, App Store Connect, and the inbox
- The 10 AI rules and the multi-agent audit method in detail
- The backend pivot, the post-launch bugs, and what each one taught
Sources
Every figure in this piece is first-party: taken from the project's own git history, App Store Connect, and inbox, as of July 16, 2026. It is the author's own build, so it carries a single canonical reference rather than a research bibliography.
- Mikołaj Salecki · Tymbrethe app's home page and App Store listing
Frequently asked questions
What is Tymbre?
Tymbre is an AI coach for public speaking. You record a short talk and it analyzes not just what you say but how you say it and how you stand: pace, tone, conviction, and body language. It scores you on five dimensions and returns specific physical cues to change, with processing hosted in the European Union.
Was the app really built in 30 days by one person?
Yes. One person built it alone, after hours alongside a full-time job, in 30 calendar days, roughly 200 hours across 86 sessions. It went from a clickable mockup to App Store submission on June 16, 2026, and was approved 11 days later. The git history backs the numbers: 1,116 commits, about 444,300 lines churned, 33 screens, and 18 backend functions.
Do you need to be a developer to build an app this way?
No. The author is not a developer and had never shipped an app to an iPhone before. The work is done with AI, but the point is that writing code is not the hard part. The bottleneck is decisions and verification: choosing what to build, reviewing what the AI produces, and catching what is wrong before it ships.
How was the app tested if there were no automated tests?
There were zero automated tests. Quality assurance was three AI audits run by 30 agents, burning about 1.65 million tokens, which surfaced around 70 issues before launch. It is not a substitute for a real test suite, but it caught the problems that mattered before Apple review.
What was the biggest risk to finishing in 30 days?
The backend was thrown out and rebuilt on day 6. That single pivot was probably the only reason 30 days was enough. Catching an architectural mistake early, rather than carrying it for weeks, is what kept the timeline intact.
What is the CLEAR method?
CLEAR is Tymbre's own scoring method across five dimensions of presence: Cadence (pacing and rhythm), Lift (energy and dynamics), Expression (tone and color), Authority (conviction and presence), and Resonance (how it lands). Instead of dry metrics, it returns somatic cues, actual physical moves to make.
Is Tymbre private, and what does it cost?
Tymbre is private by design: no trackers, no advertising identifier, and no tracking-consent prompt, with personally identifiable data scrubbed before anything reaches the logs. Processing is hosted in the European Union. It has three tiers, Solo, Speaker, and Master, with monthly limits enforced server-side and real payments behind them.
Mikołaj Salecki
Writes about media, tech, and AI business for people who actually run digital. Former agency lead. Skeptic of frameworks that read better than they perform.
Get the next issue by email.
One letter, once a week. Sharp coverage of media, tech, and AI business. No filler.
