Build Log · Jul 5, 2026
I built the app in a day. Then I waited two weeks for an email.
Fourth one.
I’d just read a guide that promised to get you from an app idea to the App Store in seven days. I don’t think that’s a lie exactly, but I don’t think it’s true either, so I went and checked my own receipts.
Changes is an app I built for a real problem I have in the studio: turn a rough recording of an original song, a hum, a voice memo, a messy rehearsal, into a chart a session player can read, then into a Logic session with the band already wired to it. I built the whole thing with Claude Code and Claude Design. No Cursor, no separate AI API, no boilerplate repo to configure before I could start.
I pulled the timestamps on every commit. First one: 9:15pm. The last one that made it feature-complete and store-ready: 9:03pm the next day. Twenty-three hours and forty-eight minutes, start to finish. Take out the stretch where I was obviously asleep, about seven and a half hours, and two meal-length gaps, and the hands-on time comes out to around thirteen hours.
Thirteen hours. Not seven days.
Some of what happened in that window is worth writing down on its own. Partway through, I ran a competitive comparison against Tape It, the adjacent recording app in the same space, and it changed the product on the spot, not just the marketing plan. It surfaced a real gap. I’d been capturing mono, and it should’ve been stereo, and I fixed it before I’d have shipped a version I already knew was worse. It also killed a paywall idea I’d been carrying: a three-project cap on the free tier. The market already trains musicians to expect a generous free tier, and a count cap doesn’t convert anyone, it just makes casual users leave annoyed. Gone.
Later the same day I built a feature: re-chart the song from your corrected section labels. An hour later, I pulled its button back out of the app. It worked. It just wasn’t worth the screen space once I used it myself: the benefit was invisible, and it threw away hand-fixes I’d already made. The code’s still there if I want it later. The user never sees it. Building something doesn’t mean you owe it a place in the UI.
By that evening the app did everything it needed to do. Then the real clock started, the one that has nothing to do with how well you build. Submitting to the App Store means the Apple Developer Program has to approve your account first, and that queue doesn’t care how fast you shipped. It’s been two and a half weeks since that commit. I’m still waiting on an email.
The waiting has been a little of everything. Some days I check my email more than I’d admit to. Other days I’m heads-down on something else entirely and forget it’s even pending. Mostly I’m frustrated that there’s nothing to do about it: no lever, no faster tier, no one to call. And underneath that, a nagging second-guess: did I do something wrong, or could I have set this up differently for a faster approval? Everything I’ve read says the first approval is really just Apple verifying you’re a real person and a real business, which is what makes the second-guessing feel a little irrational, and I still can’t fully shake it.
That’s the honest version of the guide I wish I’d read: the build is a day, maybe less. The wait is Apple’s, and it’s not a day at all, and it comes with its own low hum of doubt that has nothing to do with your code. Anyone selling you “seven days, idea to App Store” is quietly averaging two numbers that don’t belong in the same sentence. Ours doesn’t. Design and build your app in a day. Then go live your life until Apple gets back to you, and try not to read too much into the silence.
Get the next one