Brief, Build, Break, Repeat

The part nobody puts in the project plan

The plan at the start of the build week looked reasonable on paper: research the tools, define the architecture, map out the features, then build. What actually happened was messier and more useful than that. The real shape of the week was plan, build, break something, learn something, replan, build again. Not as a failure of process — as the process working correctly.

That loop is the part nobody documents, but it’s where most of the actual decisions get made.

Execution got faster. Thinking mattered more

By week four, the toolchain was starting to feel familiar, which made it easier to see where the real work actually lived. As it turned out, the challenge wasn’t the technical setup. Once everything was connected and running, the harder part was figuring out what to tell the AI.

The first full website came together surprisingly quickly. Within a few hours there was a nine-page site complete with navigation, hero sections, and testimonials. The problem was that it looked like every other software company website on the internet. The copy sounded polished but generic, and while the colours technically matched the brand, the site didn’t communicate what made the company different. Instead of saying “this is the provider a cautious finance director would trust,” it simply said “we are a software company.”

That gap came down almost entirely to the brief. Early versions were too broad, with inputs like “cloud computing” for industry and “SMBs and enterprise” for the audience. Once the briefs became more specific, referencing real decision-makers, customer concerns, and tone preferences, the quality of the output improved dramatically. The difference between an average result and a useful one often came from spending an extra thirty or forty minutes thinking through the inputs.

The tools had their quirks too. Stitch regularly invented brand names for hero sections, while Firecrawl did a good job extracting content but often treated legal disclaimer text as the company description and rarely found the correct logo. None of these issues were difficult to fix, but they were enough to remind us that automation still needs oversight.

The biggest takeaway from week four was that AI doesn’t eliminate the thinking. What it really eliminates is much of the execution. The more effort that goes into defining what a website should communicate before generation starts, the less time gets spent correcting the output afterwards.

On the image tool side, the plan was half right

Image AI started with one properly fleshed-out architecture: layout JSON passed to a Fabric.js renderer, editable canvas elements, multi-brand kit context fed into every generation request. That one held up. The JSON-to-canvas pipeline worked. The brand intelligence schema worked. The logic of giving the model full context rather than a one-line prompt — that held up every time.

Everything after that wasn’t really planned upfront. It was figured out in rounds. A pre-check call to analyse reference image prompts before deciding whether they needed to go to the image generator at all came out of testing — seemed like a sensible optimisation, got built, then broke the flow in ways that were hard to trace and harder to justify keeping. It got cut. Outpainting got approached one way, failed consistently enough that it had to be rebuilt from a different angle using the same tools. The second approach worked. Some features — multi-channel reflow, the object inspector, generative fill — didn’t exist in any plan. They became obvious once something was actually running and you could see what was missing.

The same applied to showing the prototype to the people who would actually use it — the design and social teams. Getting that exposure early changed certain directions that would have been a lot more painful to unwind at the end. A feature that makes sense from a build perspective doesn’t always make sense to the person sitting in front of it. Better to find that out in week one than after everything is wired together.

Same lesson, two projects

The pattern across both projects was the same: build enough to test, test enough to learn something, then plan the next step. Whether that meant tightening a brief until a website actually communicated something, or scrapping a pipeline that looked clean until it ran — the useful decisions happened in the doing, not the planning. Research and planning matter. But some things you genuinely cannot know until you’ve built something and put it in front of the right people.