Skip to content
The Coach's Lab
The Scouting Report: Issue #14

Plan the build before you build it

October 11, 2026 5 minutes read
AI ToolsSystemsWorkflow

The first time I built something with AI

The first real project I built with an AI coding tool was the athlete management system I use with our program today. Version one is where I learned this lesson the hard way.

I had a rough idea of what I wanted, so I opened the coding tool, described it in a paragraph, and told it to start building. It did exactly that, and that was the problem. Every time it showed me something, I'd realize there was an important detail I never told it. So I'd explain what I actually meant, it would rebuild part of the system, and then I'd notice the next thing I forgot to mention.

That cycle went on for hours. I hit my usage limit for the session, then hit my weekly limit, and I still didn't have the thing I had pictured in my head.

The tool wasn't the issue. I had walked in with half a plan and was trying to finish the plan inside the most expensive place to do it.

The plan is the real work

Every coach already knows this from program design. You wouldn't sit down and write Monday's session before you knew what the training block was supposed to accomplish, who it was for, and what you had to work with. The needs analysis comes first, and the sessions come out of it.

Building with AI works the same way. Thinking something through in a regular chat is cheap and easy to change. Building it in a coding tool is where every change costs time and usage, because now the tool has to tear down and redo work instead of just rewriting a sentence. So the more of your thinking you finish before you start building, the less you pay for it later.

This applies whether you're building something big in a tool like Claude Code or a simple one-page tool in Claude's Artifacts or ChatGPT's Canvas. The size of the build changes. The order doesn't.

Inside the Lab: talk it through, then write the brief

Step one, talk the whole thing through in a regular chat. Not the coding tool, just a normal conversation. This is where I'd use voice input from Issue #7, because talking through what you want is faster and you'll include details you'd leave out if you were typing.

And don't stop at a rough version that would technically work. Describe the finished thing you actually want, every feature and exactly how it should function. Then let it ask the questions you haven't thought of yet:

"I want to build [describe the idea]. Before we plan anything, ask me questions one at a time until you understand exactly what the finished version needs to do, who's going to use it, what information goes into it, and what each person needs to see when they open it. Push back if anything I say is vague or if I'm making something more complicated than it needs to be."

The questions are the point. Every one it asks now is one the coding tool would have run into halfway through the build.

Step two, have it write the project brief and break it into phases. Once the idea is fully talked through, ask for a document you'll hand to your coding tool:

"Based on everything we just talked through, write a project brief I can hand to a coding tool. Include what this is for and who uses it, every feature and exactly how it should behave, what data goes in and where it comes from, and what each person sees when they open it. Then organize the full build into phases in the order they should be built, with what finished looks like for each phase."

The phases are what keep a big build organized. Instead of the coding tool trying to do everything at once, it has a sequence to work through, and you have a clear point at the end of each phase to check that it works before moving on.

Read the brief before you go anywhere with it. If something isn't what you meant, fix it here, where fixing it costs you one message.

Step three, hand it over and let it work through the phases. Give the brief to your coding tool at the start and let it get the major pieces built phase by phase. If you're in Claude Code, it keeps its own notes file on the project as it works, and I let it write that file itself from the brief. Once the big pieces are in place, that's when you go back and refine the finer details.

What it looks like in the real world

Since that first version, I've planned every major addition to the management system this way, and every other project I've built has started with this same process. I spend the planning time up front in a regular chat, walk out with a full brief broken into phases, and hand that to the coding tool. It gets the major chunks built without the constant back and forth, and I spend my time refining details instead of re-explaining the basics.

It's also very close to the planning process I go through with clients when I build systems for them. Most of the work happens before anyone writes a line of code, because that's where you figure out what the thing actually needs to do.

Where the coach stays in charge

A good plan doesn't mean nothing changes. Once you can actually click through what you built, you'll notice things you couldn't have seen on paper, and that's what the refinement at the end is for. The plan is there to get the foundation right so those changes are small adjustments instead of rebuilds.

The plan is also only as good as your thinking. The chat can ask good questions and organize everything, but it can't tell you what your program actually needs. That part is coaching, and it's the part you should be doing in step one.

And if what you're building will hold real athlete information, the rules from Issue #10 still apply. Figure out where that data is going to live and whether your school has rules about it before you build, not after.

The Coach's Scouting Report

  • Signal. Thinking is cheap in a chat and expensive in a coding tool, so finish the plan before you start the build.
  • Noise. Opening a coding tool with half an idea. Re-explaining the basics halfway through a build.
  • Next Rep. Pick one tool you wish existed for your program, even a small one. Open a regular chat, use the interview prompt above, and keep going until you have a full project brief broken into phases. Don't build anything yet. Just see how much of the plan you didn't have in your head.

From the Lab

If you or someone on your staff is just getting started with AI, the AI Starter Guide for Strength Coaches is a $20 ebook that covers where AI fits in your week and what to hand off first.

See you next Sunday.

Colin

The Coach's Lab | Less busywork. More coaching.