Thirty days. One person. From a clickable mockup to the App Store.
I am not a developer. I run a consultancy, I work with AI every day, and I had the same problem as most people in my position: a head full of ideas and a long record of talking about them instead of finishing them.
- So I set a constraint instead of a plan. Thirty days, from the first mockup to a submission on Apple's review queue. Alone, alongside a full-time job, with no team, no budget, and no second attempt.
- Tymbre reached Apple's review queue on day 30 and was approved eleven days later. It is live in 175 countries. This is the build log and the operating picture: product, architecture, privacy, release path, and the failures the audit exposed.
- Every number here comes from git history, App Store Connect, the current repository, or the running stack. Launch-period figures are labeled separately from the product that exists now.
The constraint did the work a roadmap never does. A deadline is a filter, and most of what it filters out is the work you would have enjoyed most.
A coach for how you land.
Most speaking tools grade the transcript. Tymbre reads the delivery: pace, range, conviction, and body language. It scores five dimensions of presence and returns specific actions tied to observed moments in the take.
Cadence
Your pacing and rhythm. Where you rush, where a pause would land.
Lift
Your vocal range. The melody that keeps a room leaning in.
Expression
Your energy and intonation. How much of you reaches the listener.
Authority
The congruence of body and voice. Conviction a room can see and hear.
Resonance
Your depth and projection. The weight that makes words carry.
Five axes, plotted as a pentagon, scored per take. 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 U.S. and includes five Audio sessions, Speaker costs $19.99 and includes 10 Audio and five 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 ten minutes. Apple shows the local price in other storefronts.
The room nobody was standing in.
A month is not enough time to discover the market while building for it, so the market came first: seven rivals, named, priced, and read down to their one-star reviews in June 2026. No claim entered the plan without a source I could open. It cost about a week of evenings and it is the cheapest week in the project.
- What Tymbre does not have. Real-time feedback while you speak, which three rivals do and this does not. Conversational roleplay. Live meetings, web, desktop, Android, a lesson ladder, an annual plan. Android is out of scope on purpose. The rest is a resourcing fact, not a philosophy.
- What nobody else had. Eye contact and body language, which no mobile rival offers at all. Deck awareness: upload the slides, get coverage scored against what you actually said. Stage mode, the whole body on a phone, where every mobile rival is audio only.
- The line that became the strategy. One rival went enterprise, another went to meetings, the mobile ones are drill apps. Nobody was building the app you open the week before something that matters. That gap was not a feature idea. It was the product.
- What the research could not do. Three assistants compressed a week of reading into an evening and priced the competition. None of them decided that presence is physical rather than psychological. That part has no shortcut, and it is exactly the part people mean when they say the machine cannot do their job.
What survived a month of evidence.
Each rule exists because it caught something real, not because it sounded wise. The rulebook shrank from 1,089 lines on day one to 115 by the end. The second half is about knowing when to stop, which is the hardest class of rule to write and the most expensive to omit.
- RULE/01
Think before coding
State assumptions aloud. Two readings of a request means surface both, not silently pick one.
- RULE/02
Simplicity first
The minimum that solves the problem. No abstractions for single-use code, no error handling for impossible states.
- RULE/03
Surgical changes
Every changed line should trace to the request. Anything else is unreviewable noise.
- RULE/04
Goal-driven execution
Not "add validation" but "write tests for invalid inputs, then make them pass." Strong criteria let the model run alone.
- RULE/05
Done means confirmed
Pushing is not evidence of working. This rule alone caught more false completions than any other.
- RULE/06
Look harder, not faster
A second hypothesis without new information is the same dice with a new label.
- RULE/07
Two failures, change approach
After two attempts with one strategy, stop. Persistence without a change of method is just volume.
- RULE/08
Destructive acts need forethought
Know exactly what disappears, get consent if it touches shared state, keep a path back.
- RULE/09
The report is a symptom
A bug report describes what someone saw, not what caused it. Verify against the actual state.
- RULE/10
Secrets stay secret
Never paste, log, or commit credentials, not even while debugging.
Thirty days, three phases.
The phases are what the launch-period git history contains: May 17 to June 16, with 29 of 30 days carrying commits and the longest gap between any two commits running 27 hours. The architecture below describes the product that operates now.
- Days 00-06 · Decide. Research, clickable mockups, the data contract, and the operational boundary. Account ownership, private media, analysis jobs, quotas, and deletion were fixed before the product surface expanded. Apple Developer Program enrollment went in on day three.
- Days 07-24 · Build. The full iOS surface, a TypeScript API and PostgreSQL schema, a private Python analysis worker, payments, notifications, server-side quotas, and the analysis pipeline. The middle was 413 fixes, one at a time. Record day: 99 commits.
- Days 25-30 · Ship. Three adversarial AI audits: 30 agents, 1.65 million tokens, roughly 70 findings, every critical one fixed before submission. The cloud build quota ran out hours before submission, so the local pipeline was rebuilt down to one command. 49 commits in 24 hours.
Day six: fix the boundary.
The decisive architecture choice was not a vendor name. It was ownership. The mobile client talks to one public TypeScript API. That API owns identity, quotas, purchases, session state, deletion, and short-lived media operations. PostgreSQL owns durable product state. A private Python worker extracts bounded audio, silent-video, and PDF evidence, computes signal metrics locally, scores CLEAR independently of the plan, and composes coaching from validated evidence. Recordings and presentation PDFs live in private OVHcloud Object Storage in Warsaw. Every state change has one owner, and the app holds no database, object-storage, or worker credentials.
Eight things that broke.
Named, dated, and mostly self-inflicted. The launch and the later full-system audit both contributed to this list. The failures that hurt are not always the ones that crash. They are the ones that quietly succeed at doing nothing.
Subscriptions sold in two countries out of 175
The app shipped to 175 territories. The subscriptions were configured for two. In 173 countries you could install it, reach the paywall, and find nothing to buy, while ads ran across the EU. Found nineteen days after launch.
Two containers, no scheduled-task target
During a rolling deployment, Coolify found two generations of the API container and correctly refused an ambiguous analysis-push task. The production API now owns dispatch under a PostgreSQL singleton lock, and the external minute task is disabled.
Two deployment triggers for one commit
A GitHub webhook and a manual API trigger could start overlapping deployments of the same revision. Healthy containers did not make that a healthy release process. The webhook is now the single deployment owner.
The build quota, twice
The cloud build allowance ran out on day nine and again on day thirty, the second time hours before submission. A dependency I never owned, failing exactly when it mattered. The fix was to stop renting it.
A launch-blocking bug found on the last day
Session delete and rename crashed against a cached list, in a flow used on every single session. Manual testing caught it hours before submission. Nothing else would have.
Sign-out coupled to notification cleanup
The app refused to sign out when the device could not safely detach its push token. Protecting notification state accidentally trapped the account session. The current release candidate preserves the cleanup signal without blocking sign-out.
Fourteen reverts
Fourteen commits exist purely to undo other commits. Not a failure of process, the process working. But it is the honest shape of the month.
One file, edited 108 times
The profile screen was touched 108 times across 30 days. Not a bug, a signal: the place a design keeps getting rewritten is the place the design was never actually decided.
Current release evidence combines automated app, API, worker, copy, policy, and signed-build checks with manual screen review, physical-device flows, API verification, backup inspection, and App Store Connect evidence. A passing test is one input, not proof of the whole system.
The month, in figures.
Pulled from git, App Store Connect, and the running stack. Roughly 200 hours across 86 working sessions, estimated by clustering commit timestamps rather than self-reported.
days, mockup to review queue
commits · one every 37 min
hours, alongside a full-time job
countries live
- Launch code. 1,116 commits: 413 fixes, 164 features, 120 documentation, 83 chores, 29 refactors, and 14 reverts. About 444,300 lines moved during the month, across 967 distinct files touched at some point.
- Current shape. 29 screen components, 36 production design-system source files, and about 47,800 lines of app TypeScript. The public TypeScript API is roughly 5,700 lines. The Python worker workspace is roughly 9,100 lines across the private worker, tests, and operational tools.
- Release system. GitHub is the source, Woodpecker runs checks, Coolify deploys the API and worker, Expo prebuild generates the native project, and local Xcode creates the signed archive. The current app tree contains 55 test files alongside backend and worker suites and release-policy scanners.
The bottleneck was never writing code.
The model wrote most of the lines. It did not decide anything that mattered: not the product boundary, not the privacy posture, not the day spent on mockups, and not which evidence was strong enough for a release. Typing got cheap. Judgment did not. Broken code announces itself. Plausible code compiles, reads well, and solves a problem adjacent to yours. Thirty days bought a product, and the product created a permanent verification job.
What it does not prove: that this scales or that it survives a second engineer. It proves one thing. The distance between an idea and a store listing is now made almost entirely of decisions, and the distance from a listing to a reliable product is made of verification.
24 pagesA4 · PDF45 min readingv1.0 · August 2026
The case study
The whole build,
in one PDF.
A 24-page A4 on shipping an iOS app in thirty days. Every number in it comes from git history or App Store Connect. Send it to your inbox.
- The research: seven rivals, the gaps, and where the product landed
- The ten rules that governed every build decision
- Thirty days in three phases, from product contract to App Store review
- The current architecture, privacy model, release path, and audit findings
Check your inbox.
The download link is on its way. If it doesn't arrive in 5 minutes, check spam, or email me at hi@salecki.digital.
You'll also get a separate email to confirm your newsletter subscription. Click the link inside to complete it.