Four out of nine
On September 3 we went through the nine apps published that day with wanno. It was a routine review: open each one, look at the first screen, note what worked and what didn't.
The colors varied nicely from one to the next. So did the typography. Border radius, spacing, the tone of the copy: all different. The header, no. Four of the nine showed exactly the same composition.
A rounded square on the left, filled with a green gradient and a white icon on top. Next to it, the app name in bold. Below, a gray subtitle. On the right, a button. A gym class booking app, a plant catalog, an expense tracker and a coffee shop website. Different products, different requests, the same start of page.
If you've used any AI app builder, you already know that composition. It's the header. The one in every demo, every Twitter screenshot, every landing page generated in thirty seconds. We were producing it too, and we weren't sure why.
The first suspect is the model
It's the comfortable explanation, and there's some truth to it. Models have habits. Ask for a header and you get that header, the same way you ask for a button and get a blue one with rounded-lg. Other builders produce the same composition for the same request, and that seemed to close the case: not our problem, it's the model.
But there was a signal pointing at us. The CSS class drawing that green gradient hadn't been invented by the model in each app. It showed up with the same name in all four, and that name came from our template.
That changed the question. It was no longer "why does the model always do the same thing" but "what are we handing it before it starts". And when we looked at that carefully, we found two things.
Two things we were handing it
When someone describes their app, wanno doesn't pass the message to the model as is. First there's a plan, which structures the request, and a template, the base project the agent writes on top of. Both exist for good reasons. Both were pushing toward the same header.
The plan was a menu. To help the model decide how to open the page, the plan offered it eight named header shapes: "hero with icon", "bar with logo and CTA", "centered title", and so on. The idea was to give it vocabulary. The effect was different. A list of options becomes a menu, and a model in front of a menu picks from the menu. Almost always the first option, or the one that looks most like what it has seen a thousand times.
The template had a finished look. Our base project wasn't a neutral skeleton. It shipped with a gradient defined as a class, two named shadows and an entrance animation marked "recommended" in a comment. All of that was there so apps would look good from the first second, and it worked: they looked good. But the model wasn't deciding how the app would look. It was assembling pieces that came with the decision already made.
Together, the two made the path of least resistance always the same: pick the header from the menu, fill it with the template's gradient, add the recommended shadow. Four out of nine.
What we changed
The rule we kept fits in two sentences:
The template delivers a substrate, never an aesthetic. Its comments describe mechanics, never preferences.
Put more simply: the base project has to give the model the tools to build, not the house already furnished. In practice it was three changes.
- We stripped the style out of the base project. Out went the gradient, the shadows, the entrance animation. What remained was a blank canvas with the rules for painting on it: where a color gets defined, how a typeface gets chosen. Which color and which typeface, the model decides for each app.
- We changed the tone of the internal notes. The base project has notes explaining to the model how each piece works. Several of them sounded like advice: "use this shadow for cards", "recommended animation for the hero". Advice written there, the model reads as an order. Now the notes only explain what each piece does, without an opinion.
- We stopped offering it a menu. The eight named header shapes disappeared. Instead we ask it to describe the first screen in the visitor's own words: what they see on arrival, what they understand first, what they can do. The design comes out of that description, not out of a list.
The third change was the one we argued about most. Without a menu, the model had to design on its own, and we didn't know whether it would do it well. The alternative was to keep handing it the menu and accept that every app would look alike. We chose to try it and measure.
What we measured afterwards
In the first four apps published after the change there were zero gradients, zero icon squares and three different header shapes. The fourth app simply had no header: it was a list of shifts that started at the list.
| Before (9 apps, Sep 3) | After (4 apps) | |
|---|---|---|
| Header with the repeated composition | 4 | 0 |
| Template gradient | 4 | 0 |
| Distinct header shapes | 6 | 3 (+1 with no header) |
The case we cared most about was the explicit request. When someone typed "add a header", nothing more, they got a thin line at the top, the app title and a link. No icon, no gray subtitle, no button on the right. The model, without a menu, chose the least that resolved the request.
Four apps aren't a sample; they're a signal. What we do know is that the repeated header hasn't come back in the weeks since, and that none of the new apps looks worse than the earlier ones. They look different from each other, which was the point.
The rule we kept
It applies to any system that gives a model context, not just app builders. Before adding a structure (a list of options, an example, a named default, a "recommended"), ask yourself whether it's scaffolding or a menu.
Scaffolding gives the model something to lean on without deciding for it: the token system, the way to declare a color, the contract it has to meet. A menu gives it closed options, and the model will pick one of them even if none is right for that request. The difference isn't in the intention you wrote it with; it's in whether the text describes a mechanism or expresses a preference.
AI-built websites look the same because they all start from the same menu. The model has its habits, yes, but most of the problem is in what we hand it before it writes a single line. And that, we can change.
