What Six Weeks Actually Builds

Six weeks in

There’s a point in any build where the question stops being “will this work” and starts being “what does this actually become.” That’s where both projects are sitting at the halfway mark.

The tools exist. They’ve been tested, broken, rebuilt, and tested again. The pipelines that looked good on paper have been through enough real usage to know which parts held up and which parts needed a different approach entirely. What’s left isn’t building from scratch — it’s the harder work of taking something that functions and turning it into something that’s ready for real clients, real workflows, and real production conditions.

This week was about taking stock of where both tools are, and starting to think seriously about what the path forward looks like.

What the image tool can do now

The image tool has been running long enough now that it’s easy to forget what the first generations actually looked like. Going back to them is a good reminder of how much has changed — early outputs were a starting point at best.

The feature set has grown well past the original scope. On the generation side, users can apply universal style extensions — things like watercolour, comic page, pixel art — or brand-specific styles. Brand assets like logos and images get pulled into the design automatically. Reference images are built into the prompt intentionally.

The layout system is where a lot of the nuance lives. Editable elements can be toggled on or off. Fully baked generations produce a single static image — useful for high complexity designs. The Layout Decomposer goes the other direction: it reads an existing design and breaks it back out into editable components, which makes migrating current templates into the tool a lot faster than rebuilding them from scratch.

Templates are probably the feature that changed the workflow the most. They store the layout structure, styles, text, and images as a reusable starting point — but more than that, they store context about what they’re actually for. So a reprompt doesn’t need to re-explain the whole design. It just needs to say what’s different this time. A product ID, a new name, a location. The system fills in the rest.

For multiple aspect ratios, Reflow recomposes the full design — text, logos, hero image, in a way that’s content aware.

Over the next few weeks, we will ramp up the real client testing across more clients, and image types to identify the remaining weak points of the system. Once the tool is polished, we will turn our attention to integrating the tool with current internal systems, and bringing the tool to production.

What Web AI can do right now

WebAI has moved well beyond generating a decent-looking website. The platform now uses a structured intake wizard that collects the information needed for a build, including business goals, target audience, brand identity, design preferences, and technical requirements. For existing websites, brand data can be pulled automatically from a URL, reducing manual setup and improving consistency.

Before a build begins, the system scores the brief for completeness and identifies missing information. This ensures the AI is working from a validated source of truth rather than trying to fill in gaps on its own.

The output is a complete handoff package containing prompts, configuration files, and supporting assets required to generate the site. Every build includes accessibility standards, responsive layouts, SEO fundamentals, security headers, structured data, and sitemap generation by default. Hero video workflows are also integrated, with brand-specific prompts generated as part of the process.

A key focus has been design quality. Instead of relying on open-ended prompts, WebAI uses predefined Layout DNA systems that define structure and visual direction for different styles. This helps generated websites feel distinct rather than variations of the same template.

The workflow has been tested end-to-end using Concero Cloud Desktops, an existing WordPress site in the cloud and managed IT space. The system successfully extracted brand colours, typography, logos, and business information from the live site before generating a complete handoff package. Testing also exposed several issues, including navigation inconsistencies between pages, accessibility contrast problems, and broken local links. These have since been resolved and the fixes now apply across all future builds.

The remaining work is focused on deployment and content migration. Developers can currently generate a complete website from the handoff package, but deployment to GitHub and Cloudflare Pages is still manual. The next phase is a one-click deployment workflow that creates repositories, connects hosting, and streamlines publishing. Content migration is also planned, allowing copy from existing WordPress sites to be automatically mapped into the new website structure.

What comes next

Getting a tool into production isn’t just a technical problem. It’s a workflow problem. How does it fit into what the team is already doing? Where does it hand off to a human? What does the output need to look like for someone to actually use it without starting over?

Both projects are starting to work through those questions now. The builds are far enough along that the conversation has shifted from whether it can do something to how it actually gets used day to day.

The second half looks different from the first. Less building from zero, more figuring out what it takes to make something that actually ships.