Not a hype piece. The actual account of building a production website with Claude. What worked, what broke, the rule we violated once and never again, and what it taught us about where AI earns its place.
This is not a piece about how AI is going to change everything.
It is a piece about building a real website. Our own. Using AI as the primary development tool, and what that experience actually looked like. The good parts, the broken parts, and the one rule we violated once that cost us an hour of work and is now written into how we operate.
If you are a founder trying to figure out how to use AI in your business without either ignoring it or letting it run the show, this is the closest thing to an honest account we can give you.
The straightforward answer: we build AI-integrated systems for other businesses. Using AI in our own build was eating our own cooking. If we couldn't figure out an effective workflow ourselves, we had no business recommending one to a client.
The less obvious answer: we wanted to test something. Not whether AI could write code. It clearly can. But whether it could maintain brand consistency across a large, evolving project without constant correction. Whether it could hold a design system in its head. Whether it knew when to ask and when to just ship.
The project was not small. A full Next.js 14 site. Custom CSS design system. Seven pages. API routes for email and subscriptions. An MDX-based blog. GDPR cookie consent. Sitemap, robots, og:images, favicons. Everything you would build for a real client.
Early in the build, we established one working rule: HTML preview before production code.
The logic was simple. An HTML file renders in a browser in seconds. You can see it, feel it, move things around with a comment in the chat. Production TSX takes longer to review, longer to correct, and if the design is wrong you have wasted everyone's time building something that needs to be rebuilt.
So the workflow was: design in HTML, confirm it looks right, then convert to Next.js components. Claude builds the HTML. Chu reviews it. Once it's approved, Claude converts. This order was non-negotiable.
Until it was negotiable. Once.
We were moving fast. A page needed to be built. The brief was clear. Claude skipped the HTML step and went straight to TSX. The code was technically correct. The design was wrong. It had drifted from the brand system in small ways that only became visible at the review stage. The page had to be rebuilt.
One hour of work. Not catastrophic. But the lesson was immediate and permanent: the rule existed for a reason, and "the brief is clear" is not a reason to skip it. We wrote it into the project handoff document that day. It has not been violated since.
Holding the design system. The Qann brand bible has specific rules. IBM Plex Mono, always. Background #F4F2EC, never pure white. No em dashes, ever, in body copy. Font-weight 600 for log keys, not 700. Blue #0000FF as signal, not decoration. These are the kinds of constraints that drift when a project runs long and attention shifts. Claude held them with more consistency than a human junior developer would have. When a violation appeared. And they did appear. It was usually in a first draft, caught at the HTML review stage, and corrected without friction.
Propagating changes globally. When a decision changed. The contact email shifted from info@ to support@, the blog became "thoughts," the nav order was updated. Every affected file needed updating. This kind of global consistency work is exactly where humans get tired and miss things. Claude did not miss things, or when it did, it was easy to catch because we could ask it to check.
Speed on well-defined problems. API routes, sitemap generation, MDX configuration, cookie banner logic, scroll reveal animations. Problems with clear specifications and clear success criteria. These went fast. Brief in, working code out, HTML review, ship. The velocity on these felt genuinely different from writing them by hand.
Documentation. The HANDOFF.md that lives in the project docs. The document that lets any AI tool or developer pick up the project without a briefing. Was written and maintained by Claude throughout the build. Updated whenever something significant changed. This kind of continuous documentation is the thing that always gets deprioritised in a human-led project. It did not get deprioritised here.
Strategy and positioning. Claude did not write the brand bible. It helped structure and word things once the positions were clear, but the positions themselves. Who Qann is for, what we will not do, how we talk about AI, what "operator" means and why it matters. These came from the founder. AI can reflect a position back clearly. It cannot have a position.
Copy on things that matter. The homepage headline. The CTA. The about page. The thoughts posts. Anything that carried the brand voice required a human first draft or heavy human editing. AI copy tends toward the complete. It fills all the space, rounds all the edges, resolves all the tension. Good brand copy often works because of what it leaves unresolved. That instinct is not something we found a way to delegate.
Knowing when something was technically right but brand wrong. This is the hardest thing to describe and the most important. Code can be syntactically correct and semantically accurate while still being slightly off. A spacing decision. A weight choice. A word that is accurate but too corporate. A component that works but does not feel like Qann. Catching these requires having an opinion about what Qann feels like. That opinion belongs to the founder.
The one moment where AI went sideways. Early in the project, we asked Claude to produce a page with a specific layout. It produced something that technically met the brief but had solved the layout problem in a way that would have been very difficult to extend later. It was not wrong. It was short-sighted in a way that only became visible when we thought about the next three pages that would need the same pattern. A senior developer would have spotted this. We spotted it at review. The HTML-first rule made it cheap to fix. Without that rule, it would have been expensive.
The metaphor we use with clients is: AI is a power tool. In skilled hands, it makes you faster and more precise. In unskilled hands, it makes mistakes faster and more consistently.
After building qann.co, we would add something to that: the skill required is not technical. It is editorial.
The developers who get the most out of AI are not the ones who write the best prompts. They are the ones who review output with genuine critical attention. Who can look at something that is mostly right and identify the 5% that is not, and why, and what to do about it. That is an editorial skill. It is also the skill that defines a good art director, a good editor, a good senior engineer. The job did not go away. It changed shape.
For Qann, this confirmed something we already believed: AI executes. Humans decide. The website we have is a product of both, in that order, in that hierarchy. The AI did not build qann.co. The AI helped us build qann.co. That distinction matters. Not for philosophical reasons, but for practical ones. The moment you stop making it is the moment quality starts drifting and nobody can tell you why.
A few things that would have helped us at the start:
Write the design system before you start building. Not a mood board. An actual document with hex values, font weights, spacing tokens, copy rules, and things you will never do. The more specific it is, the more useful it is as a brief. Vague briefs produce average output. Specific briefs produce good output.
Establish the review gate and do not negotiate it away under deadline pressure. The HTML-first rule existed because we knew the risk. We waived it once anyway because we were moving fast. The rule was right. The waiver was wrong.
Write the handoff document from day one, not at the end. Every decision, every change, every rule. If you are using AI across multiple sessions, continuity is the hardest problem. The document is what gives the next session context. Without it, you start again.
Do not use AI for the things that require an opinion. Use it for the things that require execution once the opinion exists. The line between those two things is the most important thing you will figure out in your first month.
qann.co was built in iterations over several weeks. it is still being built. that is the other thing about using AI in a real project: the speed changes what is possible, which changes the scope, which means you ship more than you planned. that is mostly a good thing. mostly.
— Qann Commerce · qann.co