A Launch Delayed an Hour by an Undisclosed Implementation Choice

Ahead of a SaaS launch for an international client, I asked a backend developer to build a single API route that would pull the admin dashboard's data from multiple tables in one call. What shipped instead was several separate API calls on the same page. [NEEDS INPUT: how the gap between what was asked and what was built came to light: testing, or the client noticing the slow page] The admin user was the client themselves, which is exactly the account where a slow internal page gets noticed and remembered. I was running several teams and projects at the same time this happened.

The dependency I actually had to manage here was not another team's: it was one developer's choice not matching what I had asked for, and not telling me. A slow page is a symptom. An undisclosed implementation choice is the real risk, because it means the next problem is also invisible until someone happens to find it.

The fix was not a mystery once I looked at what had actually shipped: the page was making several separate calls where one indexed query would do, so every load paid for all of them in sequence. I did not spend time deciding whether to have the developer rebuild the approach from scratch: a rebuild this close to launch risked a new set of untested code, and the actual defect was narrow enough to fix directly.

I chose to fix the query layer myself rather than hand it back to the developer who had built it, because the launch clock did not have room for a second round of the same gap between instruction and implementation. That cost the hour the launch slipped by. I also chose to tell the client the launch would be late and why, rather than quietly absorb the hour and say nothing: a slow admin page they would have noticed themselves was a worse conversation to have after the fact than before it.

I rewrote the dashboard's data access with proper SQL indexing and a single query in place of the several separate calls, tested it against the load the admin page would actually see, and shipped it as part of the launch rather than as a follow-up patch. In parallel, I told the client the launch was moving by about an hour and why, before they had a chance to notice the delay on their own.

The launch went out about an hour late. Nothing was cut or deferred to make that true: the fix shipped complete, in the original release. An hour late with a clear reason cost less than an unexplained slow admin page would have cost with a client who was going to be using it directly.

The real risk in this one was never the implementation gap: it was that it went undisclosed. I now ask directly, before a launch, whether anything shipped differently from what was scoped, not because I distrust the team, but because a gap that surfaces on its own always surfaces at a worse time than a gap someone tells me about first.