Your business is a system. Draw it before anyone builds it.

Most projects I'm brought into start with a feature list. A client wants a booking page, a member area, a payment flow and something with AI in it. The list is usually right about what they want. It almost never says how those pieces talk to each other, who looks after them once they're live, or what happens when one of them fails at 2am.

So before anyone writes code, I draw the whole thing.

What goes on the drawing

The drawing is a single page with boxes and arrows, and it covers more than the software. If a lead comes in through a form, I draw the form, the CRM it lands in, the person who calls that lead back, and the email that goes out if nobody does. If a payment fails, I draw where that failure shows up and who sees it first.

People and tools sit on the same page as the code. The person who updates the menu every Friday is part of the system. So is the Zapier step someone set up three years ago that nobody remembers. When they're missing from the drawing, they're usually missing from the plan as well, and that's where projects get expensive.

I think of it as five floors. At the top is what people touch: screens, forms and the design system. Below that is the logic, the APIs and rules that decide what happens. Then memory, the databases and what they keep. Then the machine, where it all runs. At the bottom now there's a fifth floor for the AI steps and automations that learn or act on their own. Most clients only ever see the top floor, which is fair. My job is to make sure the four below it hold the weight.

Documents before development

On larger builds I won't start development until the documents exist. A requirements spec, a system architecture document, the database design, the user stories with acceptance criteria, the API contract, a data flow diagram, a testing plan and a deployment and handover note. It sounds like a lot of paper. In practice it's a few days of work that saves weeks, because every argument we would have had halfway through the build happens on paper first, where it's cheap.

The documents also make the work portable. If a developer leaves, or a client brings in their own team later, the system can be understood without me in the room. I count that as part of the job.

Where AI fits

I use AI every day, mostly Claude Code agents that build, review and test code, and automation workflows in tools like GoHighLevel, Make and n8n. It's fast, and it's very good at doing exactly what it's told. That's why the drawing matters even more now. An agent will happily build the wrong thing quickly if nobody has decided what the right thing is.

On the drawing, an AI step gets the same treatment as any other box. What goes in, what comes out, what it's allowed to touch, and who checks its work. When a client asks "can we add AI?", the honest answer starts with where it would sit on the page and what it would replace.

The drawing changes the conversation

The best thing about drawing first is the conversation it creates. A founder looks at the page and says "wait, who handles refunds?" and nobody in the room knows. That question would have surfaced eventually anyway, usually as an angry customer email after launch.

If you're planning a build and you can't draw it on one page yet, that's where I'd start. Grab a pen and draw every box, including the people. Then start asking where the arrows go.