Six days from an empty folder to a live App Store listing
Work started at 7:24 on a Wednesday evening, 10 June 2026. The following Tuesday the app was live on the App Store and anyone could download it. Six days, with AI agents doing the typing and a senior developer deciding what got built.
That means a real listing on the store, not a demo or a test link sent to a handful of people. GastroLog is a meal and symptom diary for people living with gastroparesis, and Apple reviewed it into the Medical category. By the time it was submitted it came to 27,044 lines of code across 80 files, plus another 11 files of automated checks.
Every date here comes from two places: the timestamped log our tools keep automatically each time work is saved, and Apple’s own record of when the app went on sale. Neither can be tidied up afterwards to make a story look better.
What six days actually delivers
The surprising part of that week is how little of it was writing the app.
The same six days produced the automated process that packages the app and sends it to Apple, screenshots rendered at two phone sizes, a short preview video for the store page, the words on the listing, a privacy policy, the security paperwork Apple requires before anything can ship, the keys Google requires for Android, and the Google Play page. Roughly half the work had nothing to do with the diary itself.
That half is where software projects usually stall. The app gets finished, then the artwork, the legal pages and the submission become someone else’s job, and a working app sits unreleased for a month. AI agents are good at precisely this kind of work, because it is repetitive, well documented and nobody’s favourite part.
What arrives at the end of the week is a page in the App Store with a download button on it.
Where the judgment went: cutting the plan back on day one
On the first evening, before a single screen existed, two things were cut from the plan. Photographing a meal to have it logged automatically, and the paid upgrades that would have sat behind that feature.
The note saved alongside that decision explains the thinking. Ship the diary people actually need, learn from how it gets used, and leave the payment machinery built but switched off, so turning it on later is a setting rather than a rebuild.
That call is the reason the build took three days of work, and no AI agent made it.
This is the part of the job that has become more valuable rather than less. AI agents will build whatever you point them at, quickly and capably, so an overloaded plan no longer announces itself as a six-month slog. It quietly eats a week and hands you something with more to maintain than you needed. Knowing what to leave out, while leaving the door open to add it later, is where an experienced developer’s time now goes.
How AI agents keep speed from costing quality
Every change was checked by an automated reviewer as it was made, and several entries in that first stretch exist only to fix what the review flagged. Nothing reached the store without going through it.
Alongside that, we wrote a profile of a realistic user: someone with good days, average days and bad days, plus eight awkward situations drawn from how the condition actually behaves. Those situations became repeatable test runs. They catch the kind of problem an automated check never sees, like a button sitting exactly where a real thumb needs to go.
Five further entries do nothing except write lessons back into the manual the AI agents read before they start work. A tool that leaves processes running, a setting that breaks the packaging step, an upload that quietly duplicates screenshots. Each cost an hour once. None has cost an hour since, and that manual carries into every build that follows.
The three days we could not compress
The last change was saved on Friday 12 June. The listing went live on Tuesday 16 June. In between, the app sat in Apple’s review queue as a medical app.
Review takes as long as it takes, and it is worth planning around. Once building takes days rather than months, that queue becomes a real share of the calendar. It is why we quote the whole path to a live listing instead of the coding alone. Six days is the door-to-door figure, and Apple’s turnaround is already inside it.
The same six days happened four more times
One fast build can be luck, so the fair question is whether it repeats.
Between 15 June and 10 July 2026 we put five iPhone apps into the App Store: a tracker for cats with kidney disease, this diary, a stress-habit checklist, a symptom tracker for PCOS, and a chess clock. Every one of those dates comes from Apple’s own listings. Each build ran through the same packaging process, the same review step and the same written-down lessons.
The shipping record has the full set, with build times measured the same way.
It kept shipping after launch
A quick build only counts for something if it survives real use.
The project has since grown to 119 recorded changes and version 1.1.5, with updates landing through July: measurements a specialist can read, clearer charts, a faster way to repeat a meal you eat often, and fixes that came from watching people use it. It was a starting point that took maintenance well, rather than a demo that had to be rebuilt properly later.
What this means if you are choosing who builds it
Six days is not a stunt, and it does not come from cutting corners. It is what happens when the packaging and submission work is automated, the lessons from earlier builds are written down where the AI agents will read them, and the decisions about what to build stay with someone who has shipped before.
That is the approach behind every product in our record, which is why what a build costs is a question about the whole life of the software rather than an hourly rate, and why an automation project is mostly not the prompt.
If you have an idea sitting in a document, the useful question is no longer whether it can be built this quarter. It is which parts deserve to exist in the first version.