On Tuesday, Claude Code and I shipped a complete customer dashboard for Snapline, the missed-call text-back service we run ourselves: a login, an inbox that folds calls, texts, and website leads into conversations, and a reviews tab that sends requests through the API. 216 automated tests. Deployed, and signed in on a phone, before the end of the day. That is what AI-accelerated development speeds up: the code. It did not speed up a single thing that lives outside the repository. DNS propagation, a browser holding a stale certificate, a telephony provider's second webhook URL, a carrier registration queue, and a phone that rings for twenty seconds before anyone can call it missed. This is the list, with what each one cost, because a 30-day promise is only honest if you know which days no model can compress.
What did the AI actually speed up?
Everything with a test around it. The session started with a written plan: where authentication lives, how the dashboard reads the database, how the one write, sending a review request, stays inside the API's audited path. I approved the plan, then the build ran. Four auth tables and a migration. A session token handed from one service to the other as a bearer. Every tenant-scoped query taking the tenant id as its first argument, with an integration suite that seeds two tenants sharing a customer's phone number and asserts that neither can see the other's rows. Screens designed at 390 pixels wide first, screenshotted by a headless browser, and corrected before a human looked at them.
The count at the end of the day was 140 tests on the API and 76 on the dashboard, all running against a real Postgres inside the test process. A strong engineer does that work in a week. The tests are why one day is enough to trust it.
Where did the rest of the day go?
Six places. None of them was a code problem, and every one of them would have eaten the same hours with or without AI in the room.
The clock started in the wrong place. The inbox showed "Missed call, texted back in 21s." True, and wrong. The number counted from the moment the call arrived, but the phone rings for twenty seconds before the system is allowed to call it missed. The real gap was one second.
call arrives +0s
forward rings +0s to +20s
decided missed +20s
text sent +21s
shown: "texted back in 21s" true
meant: "texted back in 1s" also true
Fixing it took a new column, the moment the outcome was decided, because the database had never recorded that moment. The AI wrote exactly the measurement I specified. What "when" means for a missed call is domain knowledge, and only real traffic exposed that I had specified it wrong.
A failed text counted as a text back. The provider rejected a message, and the code treated anything not explicitly suppressed as sent. Twenty lines and a test to fix. A definition problem, not a typing problem.
The new domain refused every sign-in. We moved the dashboard to its own subdomain. The certificate was valid, the page loaded, and every login came back "Invalid origin". One environment variable on the host still named the old address. The AI found it from the outside in about a minute, by posting to the sign-in endpoint from both origins and comparing the answers. The fix was a person editing a variable in a hosting dashboard and waiting for a redeploy.
Chrome showed the wrong certificate for an hour. The server had been serving the right one the whole time. The browser was reusing a connection it had opened before the certificate existed. Nothing to ship. Quit the browser.
The second webhook URL. The telephony application has two: the one that answers a call, and the one that reports a call ended, which is how the most common missed call, a caller hanging up while it is still ringing, gets caught. Move the first and forget the second and nothing errors. Calls quietly stop being texted. That is not engineering. That is a checklist, and it now lives in the runbook.
Carrier registration. Any business that wants to text from a new number registers with the carriers first. It takes days to weeks, no vendor can skip it, and no model can shorten a queue. The entire text-back feature is waiting on it, and the dashboard shows the customer exactly where the registration stands, because the alternative is a customer asking every day.
What does this mean for a 30-day build?
Three rules we now run on every sprint.
- Queues go on day one. Developer accounts, domains and DNS, carrier or payment registrations, any third-party approval. Everything with a wait outside your control starts the morning of day one, in parallel with the code, because it is the only item on the schedule that cannot be accelerated.
- Definitions before code. "Missed", "delivered", "texted back": each is a business definition, and a test suite can only verify the definition it was given. We write them down with the client before the first line, and we read them again the first day real data arrives.
- Real traffic is a test tier. We ran the product on ourselves for a day before any customer touched it. That day found three things 216 tests did not. Tenant zero is not optional.
This is the shape of every sprint we run: the code compresses, the world does not, so the world goes first. To see where each of these lands, read how the 30-day sprint is scheduled week by week. The earlier note in this series is My test suite was green. Then I called the number.
