Tymbre runs a TypeScript API, PostgreSQL, and a separate Python analysis worker through Coolify on OVHcloud infrastructure in Warsaw; recordings use private OVHcloud Object Storage in Warsaw. The current iOS release candidate is configured to add optional Firebase Analytics, off until an explicit in-app choice. Product analytics and advertising measurement have separate controls, personalized advertising stays disabled, and the candidate excludes IDFA support and IDFV collection. Tymbre does not track people across third-party apps or websites. See the current Privacy Policy.
- 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 launch record is real: 1,116 commits and ~444,300 lines moved, followed by a maintained product with 29 screen components, payments, reports, playback, and multimodal analysis. Live in 175 countries.
- The current backend is explicit and operable: TypeScript API, PostgreSQL, a private Python worker, and private object storage on EU infrastructure.
- Quality now combines automated app, backend, worker, policy, and release checks with manual screen-by-screen and production verification. The launch audits used 30 agents and roughly 1.65 million tokens.
- 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 product: the file I touched 108 times, the operational work hidden behind the screens, the release checks outside the codebase, 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 what you say, how you say it, and how you stand: pace, tone, conviction, and body language. It scores you on five dimensions, then returns specific things to change. Core data and recordings stay in Warsaw, and bounded AI analysis uses Google Cloud’s European Union multi-region.
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 concrete coaching actions linked to audible or visible evidence from the recording.
It is not a simple recorder. Three presence modes cover Audio (voice only), Frame (face and eye contact), and Stage (full body). Q&A practice turns claims from the recorded transcript into realistic follow-up questions without inventing audience personas or facts. Solo starts with seven days free as Apple’s introductory offer: the whole plan, five Audio sessions, started from the app with an Apple ID and canceled anytime during the week at no charge. After that Solo costs $9.99 a month in the US and includes 5 Audio sessions, Speaker costs $19.99 and includes 10 Audio and 5 Frame sessions, and Master costs $29.99 and includes 20 Audio plus 10 video sessions shared across Frame and Stage. Every session lasts up to 10 minutes. Apple shows the local price in other storefronts. Limits are enforced server-side, with real payments behind them. And it is private by design: the current release candidate keeps optional Firebase Analytics off until an explicit in-app choice; product analytics and advertising measurement are separate controls, personalized advertising remains disabled, and the candidate excludes IDFA support and IDFV collection. Personally identifiable data is scrubbed before anything reaches the logs.
That is a full product: an iOS app, a public API, PostgreSQL, a private analysis worker, object storage, 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 maintained app now has 29 screen components and a shared design system spanning 36 production source files, 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 every claim has to remain visible to the next person who touches the product. The current repository keeps a short top-level README, focused app and backend runbooks, a stylebook, executable release assertions, and tests beside the behavior they protect. Product copy lives in one typed registry rather than being scattered through screens. Documentation describes the system that exists; compatibility code is labeled as compatibility code, not presented as architecture.
The architecture that can be operated
Tymbre has five operational layers with explicit ownership: the iOS client, a TypeScript API built with Hono, PostgreSQL managed through Drizzle migrations, a separate Python analysis worker, and private OVHcloud Object Storage. Coolify runs the API and worker as separate containers on OVHcloud infrastructure in Warsaw. Woodpecker builds every workspace from GitHub.
Uploading → processing → completed, recoverable failure, or permanent failure
The app cannot mark an analysis complete, reach the private worker, or sign arbitrary storage paths. The API owns identity, quotas, session state, deletion, push registration, and short-lived media access. The worker owns bounded analysis results. Idempotency keys make an ambiguous mobile retry resolve to one authoritative session.
The architecture is deliberately boring to describe. That is a feature. A production system is useful when a failed upload can be distinguished from a failed analysis, a scheduled job can be tied to a named container, a backup can be inspected as a real archive, and an account deletion has one server-owned path through every related row and object.
Analysis follows the same boundary. The worker extracts timestamped evidence from bounded audio, silent-video, and PDF chunks, computes objective signal metrics locally, produces one tier-independent CLEAR assessment, and only then composes plan-specific coaching from validated evidence. The final coaching call never receives the original recording or PDF. Suggestions need a matching audible or visible observation, Q&A needs a transcript claim, and an unsupported optional strength is omitted rather than padded into the result.
The code, in numbers
The launch month, counted from the git log, looks like this: 1,116 commits, 255,699 lines added and 188,620 removed, about 444,300 lines moved. 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 is a stack, too
Before launch, the codebase went through three adversarial AI audits: 30 agents and about 1.65 million tokens of analysis of the code and its production readiness. They found roughly 70 issues. Every critical finding was handled before submission. That process is no longer the only line of defense.
The maintained product has automated app, API, worker, policy, copy, and release-configuration checks. The app currently has 55 test files, while the TypeScript API and Python worker have their own suites and operational checks. Orientation coverage is fail-closed: a new screen is portrait unless it is explicitly one of the two capture surfaces allowed to rotate. Analytics coverage is also fail-closed: a new leaf screen must be added to the allowlist before it can be measured. The signed iOS product is scanned for privacy defaults, identifiers, tracking frameworks, the Firebase configuration, and its privacy manifest. Manual review still opens every screen state, button, alert, report, transcript, playback path, and failure recovery because compilation cannot prove those interactions make sense.
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 source | About 47,800 lines of TypeScript under apps/app/src |
| Screen components | 29 across onboarding, capture, results, playback, progress, subscription, and settings |
| Design system | 36 production TypeScript source files under the shared design components |
| Public API | About 5,700 lines of TypeScript, with PostgreSQL and Drizzle migrations |
| Python worker workspace | About 9,100 lines across the private worker, tests, and operational tools |
| Test surface | 55 app test files, plus API and worker suites and release scanners |
The product stack: explicit owners, one release
A solo build in 2026 is really an exercise in wiring. The hard part is not naming services; it is knowing which service owns each fact, which data leaves the European Union, and where a failure becomes visible.
| Layer | Services |
|---|---|
| Design and code | Claude Design (mockups), Claude Code (implementation) |
| Infrastructure | OVHcloud in Warsaw, Coolify for containers, Cloudflare for DNS, CDN, certificates, and perimeter controls |
| Backend and data | Hono TypeScript API, PostgreSQL, Drizzle migrations, and a private Python worker |
| Private media | OVHcloud Object Storage in Warsaw, reached through short-lived server-signed URLs |
| AI | Gemini 3.7 Flash on Google Vertex AI for bounded, evidence-first multimodal analysis |
| Build and shipping | GitHub, Woodpecker, Expo prebuild, local Xcode archive, and Apple App Store Connect |
| Monitoring | Self-hosted GlitchTip in the EU, with personal content scrubbed before capture |
| Payments and messaging | RevenueCat and StoreKit, APNs, and Resend |
| Measurement candidate | Optional Firebase Analytics and Google Ads measurement, default-off and consent-first, without IDFA or IDFV collection |
Where the off-the-shelf tools ran out, the project grew its own scripts and Expo plugins: App Store artwork generation, reviewer data, privacy-manifest generation, orientation assertions, configuration scans, and a local iOS path from deterministic prebuild through Xcode archive and upload. The goal is not to avoid Expo; it is to own the native product that Expo generates and verify the same configuration in CI and locally.
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.
The release now treats code, store configuration, and production infrastructure as separate evidence domains. App Store territories and products are checked in App Store Connect. Woodpecker builds each workspace. Coolify deployment and scheduled-task results are inspected after the webhook finishes. PostgreSQL backup archives are opened and listed rather than trusted by their filename. Public health and authenticated API paths are checked against the deployed revision.
That distinction matters because valid configuration is not proof of execution. During a rolling deployment, two generations of the same container briefly coexist; a scheduler that refuses to choose between them can skip one minute even though the task succeeds before and after the rollout. A GitHub webhook and a manual deployment trigger can overlap on the same commit even though either mechanism works alone. A backup can be green in a dashboard and still need a restore-level check. None of those failures lives in a React component, and none is fixed by increasing test coverage in the app.
The cost of hiring it out
The launch record contains roughly 200 hours across 86 working sessions. That is five full-time weeks compressed into four calendar weeks of evenings and weekends, before counting the product work that continued after approval.
The direct infrastructure bill is the small line. The real cost is operating the product: reviewing every state, checking the production boundary, keeping privacy copy aligned, verifying backups, and proving that the signed release matches the revision that passed CI. That work does not disappear when the App Store listing goes live.
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 on the App Store, free for the first seven days.
The Tymbre build, in full
The complete case study in one printable document: every launch-period number, the full product architecture, the verification system, 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 current backend, deployment path, privacy boundary, and operational checks
Sources
Every launch-period figure in this piece is first-party: taken from the project’s own git history, App Store Connect, and inbox. The production architecture and release process were verified against the running environment on August 18, 2026; candidate privacy controls and code-shape figures were verified against the release branch. It is the author’s own build, so it carries a single canonical reference rather than a research bibliography.
- Mikołaj Salecki · Tymbrethe official 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 what you say, 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. Core data and recordings stay in Warsaw, while bounded AI analysis uses the Google Cloud European Union multi-region.
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 launch-period git history backs the numbers: 1,116 commits and about 444,300 lines moved. The maintained product now contains 29 screen components, a TypeScript API, PostgreSQL, and a separate Python analysis worker.
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 is the app tested and verified?
The maintained product combines automated app, API, worker, policy, and release-configuration checks with manual review of every screen and interaction, production API checks, backup inspection, and a signed native-product scan. The launch sprint also used three adversarial AI audits across 30 agents, about 1.65 million tokens, and roughly 70 findings.
What was the biggest risk to finishing in 30 days?
Verification, not implementation. AI could generate code faster than one person could validate product decisions, native behavior, App Store configuration, privacy claims, and production infrastructure. The project finished because those responsibilities were made explicit and checked against the systems that owned them.
What is the CLEAR method?
CLEAR is the Tymbre 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 concrete coaching actions linked to evidence from the recording.
Is Tymbre private, and what does it cost?
Tymbre keeps core account data and recordings in Warsaw. Its current iOS release candidate is configured to add optional Firebase Analytics that stays off until the user makes an explicit in-app choice; product analytics and advertising measurement are separate controls, personalized advertising remains disabled, and the candidate excludes IDFA support and IDFV collection. Solo starts with seven days free as Apple’s introductory offer: the whole plan, five Audio sessions, started from the app with an Apple ID and canceled anytime during the week at no charge. After that Solo costs $9.99 a month in the US and includes 5 Audio sessions, Speaker costs $19.99 and includes 10 Audio and 5 Frame sessions, and Master costs $29.99 and includes 20 Audio plus 10 video sessions shared across Frame and Stage. Every session lasts up to 10 minutes. Apple shows the local price in other storefronts.
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.
