An Internal Tool I Built in a Weekend That Would Have Taken a Month

A client's CRM and billing system didn't talk to each other, which meant someone was manually cross-checking a spreadsheet every week to find discrepancies. It wasn't an important enough problem to prioritize on anyone's roadmap, so it had sat unsolved for over a year.

I built a small reconciliation tool over a weekend: pull both systems' records via their APIs, normalize the fields, diff them, flag mismatches, post a summary to a Slack channel every morning. With an AI coding assistant doing most of the boilerplate — API client scaffolding, the diffing logic, the Slack formatting — what would have been a two-to-four-week side project became about fourteen hours of actual work spread across a Saturday and Sunday.

Where the time actually went

• About 20% of the time: letting the assistant generate boilerplate — API clients, config loading, the Slack webhook integration.
• About 50%: deciding what counts as a "real" mismatch versus acceptable noise, which required actually understanding both systems' quirks.
• About 30%: debugging a subtle bug where the assistant's generated diff logic treated two differently-formatted-but-equivalent phone numbers as a mismatch.

The AI didn't save me the thinking. It saved me the typing, and the typing was never the bottleneck I thought it was.

What I'd tell someone trying this

The weekend-build story only works because the problem was well-scoped and the stakes of a wrong diff were low — worst case, someone double-checks a false positive. I would not use this same speed on something touching billing writes or customer-facing data without a much slower, more adversarial review pass. Fast prototyping for internal tools with low blast radius is exactly where this shines; it's not a general argument that every project compresses this much.