When Fast Becomes Slow

I built a working coaching animation tool in hours. Then spent what felt liketwo weeks fixing what I broke trying to speed it up.

Here's the thing: both the breakthrough and the breakdown taught me something worth sharing.

The Requirement I Didn't Know I Had

The problem was simple: I wanted to share coaching ideas with my rugby team. Visual plays, movement patterns, session designs - stuff that's hard to explain in text.

My first instinct: build an offline app that creates animation files. Users make their animations, export a file, share via WhatsApp. Done.

Prototype worked. Problem solved.

Except - not really.

Turns out different systems handle different file types differently. What opens perfectly on my phone crashes someone else's. WhatsApp compresses things. File formats get messy.

An experienced developer would have seen this coming. I didn't.

But here's what I learned: I didn't actually want to share files. I wanted to share animations.

That shift - from "how do I make this file shareable?" to "how do I make this animation shareable?" - changed everything.

The solution: store animations online, share links instead. Clean, reliable, works everywhere.

The Detour: DataSphere

Quick detour: between concepts, I built a Learning Management System for a colleague with a data science background. The idea was to demonstrate what's possible with AI-assisted development - maybe inspire her to build her own tools.

DataSphere introduced me to Supabase (database as a service). Not a deep dive, but enough to understand the basics. Enough to know I'd need it for the Animator pivot.

Interesting project. Needs revisiting later to make more of it. But it gave me the database foundation I needed for what came next.

The Speed Trap

Here's where I got myself into trouble.

I was racing against Windsurf's trial token limit. Had a deadline, wanted to maximize usage. So I forced a massive replan: pivot from offline files to online storage, execute fast, ship it.

Sounds efficient, right?

It wasn't.

I entrusted planning and execution to Opus 4.5, then pushed through tasks at high speed with minimal testing or checkpoints. Went from a working prototype in dev to a buggy, semi-deployed mess.

The AI suddenly had a lot of interconnected problems to debug. And I started worrying about doom loops - was it stuck? Making progress? Should I intervene?

Turns out: the AI just needed time to work through the problems I'd created by racing ahead.

But I was right to intervene a couple of times.

When to Intervene (And When Not To)

I started a fresh chat twice when progress felt stuck. Good call - gave the AI a clean slate to reassess.

I also asked about logging after watching how the AI was fault-finding. This sparked a memory of a video from a software engineer explaining that logging helps track errors through a system.

The AI implemented logging. Suddenly I could see where things were breaking.

What I learned:

Break work into incremental steps where possible. Include logging as a first thought, not an afterthought. Ask the AI to explain its debugging approach - you might spot where it needs a nudge.

Doom loops are rare. Impatience is common.

The Current State

The deployment and database are stable now. There are bugs, potential vulnerabilities, and features I want to add. But I have something I could share as a demonstrator.

It's not "good enough to deploy and forget" yet. But it's good enough to get feedback and iterate.

What This Actually Taught Me

Two lessons here:

1. Take time to understand your requirements

I thought I wanted to share files. I wanted to share animations. That's not semantics - it's a fundamental difference in approach.

The clearer your requirements, the fewer pivots you'll need. And when you do pivot, you'll know why.

2. Don't be afraid to change course - but don't race through it

The pivot from files to online storage was the right call. Forcing it through at breakneck speed without checkpoints? That created compound debugging debt.

Changing direction is fine. Racing ahead without understanding the terrain is not.

I was fortunate to have learned enough about coding - through practice, discussions with LLMs, and credible software engineers on social media - to recognise when I needed to slow down.

For anyone else hitting this point: stay calm. Get the AI to explain what it's doing. Grab a summary and handoff prompt if progress stalls. Start fresh if needed.

But give it time to work.

What's Next

Coaching Animator needs a few more fixes before wider release. Security hardening, edge case handling, user testing with the team.

DataSphere sits waiting for attention - interesting potential, but needs revisiting when I have bandwidth.

And somewhere in there, I'll probably build something else. Because that's what happens when you realise you can actually ship stuff.

Just... maybe with a few more checkpoints next time.

---

Current projects:

• Coaching Animator: Visual training session builder (active development)
• DataSphere LMS: Learning management system experiment (on hold)

Lessons this month:

• Requirements clarity matters more than you think
• Pivots are fine; racing through them creates problems
• Logging is a first thought, not an afterthought
• Let the AI work - intervention is a scalpel, not a hammer

If you're building with AI and hit a moment where everything feels broken - check if you're debugging actual problems or debugging the chaos you created by moving too fast.

Sometimes the answer is: slow down, break it into steps, let the system breathe.

That's what I'm learning, anyway.