Why we build on Claude: what is under the hood

Most AI products do not tell you which model they run. They say “our advanced AI technology” and move on. We are going to do the opposite — because designers ask, and they are right to. You do not hand client work to a tool without knowing what is in its engine.

Which models?

Anthropic’s Claude family. Not a single model — different Claude models step in depending on the kind of work. Preparing a theme, applying a change the user asked for, and finding and fixing a bug are jobs of very different weight; running all of them on one model would be neither good nor sensible.

This is not a partnership or a sponsorship. It is a technical choice, and the reasoning is below.

Why Claude?

The answer is not “it is the smartest model” — that sentence is meaningless anyway, since the rankings move every month. The answer is in the shape of our work.

Because we work template-first, what we need from the model is not creativity: it is fidelity. We have a proven codebase, designed by human designers. When a user says “add a fourth card to the services section”, that is exactly what the model should do — no more. We do not want it rethinking the architecture, “improving” the styling system, or slipping in an unrequested flourish.

That is a harder job than it sounds, and it produces a real difference between models. We chose Claude because of how narrowly it interprets an instruction inside an existing codebase, how well it holds a long context together, and how low its tendency is to add things nobody asked for. We did not check who leads the blank-page generation contest — because we are not in that contest.

Why not one single model?

Running the heaviest model on every job is like taking a lorry everywhere: it works, but it is waste. The reverse is also true — giving heavy work to a light model looks cheap and gets expensive. The right setup recognises the job and picks the model that fits it.

There is no magic behind “costs are low”; there are engineering decisions like this one. The user sees none of it — only that the answer comes fast and the bill does not balloon. Which is exactly how it should be.

What we deliberately do not leave to AI

Being an AI product does not mean having AI do everything. There are areas we keep out of its reach on purpose:

• The design itself: templates are composed by human designers — section order, typographic scale, conversion flow
• Architectural decisions: folder structure, component system and styling approach are fixed in the template; the model does not revisit them
• Publishing infrastructure: build, hosting, certificates and domain connection are ordinary software work, with no model involved
• Technical SEO: canonical tags, sitemap, schema.org and meta tags come from the template rather than depending on the model remembering them

The common logic of that list: if something has to be identical every time, do not ask a model for it. Models are good at producing variation, not at giving guarantees. Everything that needed a guarantee, we wrote into code.

Static compilation: the part the model never sees

What is live on your site is not AI output — it is statically compiled HTML. When a visitor opens the page no model runs in the background and no request goes to a model provider. The model steps in only when you ask for a change, does its job and steps back.

That distinction closes two questions at once: your site’s speed does not depend on the model (it is a static file, as fast as a file can be), and even if the model changes one day, the site that is live keeps working exactly as it is.

A good AI product is not the one that puts the most expensive model everywhere. It is the one that knows which job deserves which model.

The model alone is not enough

Here is the most important part, and to be honest it applies to our competitors too: everyone has access to the same models. Anyone can connect to Claude over an API. So the model is not an advantage; it is an input.

What makes the difference is what surrounds the model. In our case that is the template: a skeleton composed by human designers, with section order and conversion flow already thought through. The model does not work on a blank page; it works inside a structure where the folder layout, component architecture and styling system are already settled. That shrinks the surface hallucination can grip and makes the output consistent every time.

And there is the invisible part: hosting, certificates, version history, domain connection, and technical SEO arriving by default. The model does none of that. Most of the work in an AI product is, in fact, not AI.

Why are we writing this?

It is unusual for a product to say which model it uses; the norm is “our proprietary technology”. We behave differently for two reasons.

First: there is no secret being protected. Everyone can reach the same models, so hiding it produces no competitive advantage — only vagueness. Second: a designer delivering client work has to know what is under the bonnet of their tool. When their client asks “what wrote this site?”, they need an answer. If we do not give ours, they cannot give theirs.

A simple test: ask every AI product you use which model it runs. If it cannot answer, wonder why — usually either the answer is embarrassing or nobody thought about the question. Both are information.

What if a better model appears tomorrow?

We switch. The model is a choice, not an identity. Our architecture is built independently of it — the template, the publishing infrastructure and the instruction layer stay in place while the engine underneath changes. We chose Claude for today’s workload; if something better arrives for that workload we will update the choice, and we will write about that too.

Should you actually care?

An honest closing: in day-to-day use, which model we run should not matter much to you. You write the instruction, the site changes, and the brand of the engine stays invisible. A good tool makes you forget about it.

There are two situations where you should care. First: you are delivering to a corporate client and need an answer when they ask “what wrote this site, and where does my data go?”. Second: you want to measure how honest a tool is — because a product that refuses to open the bonnet is usually not telling you other things either.

The rest is our problem. Your job is delivering a good site to your client; not having to think about which model took which task is the sign that we did ours.