Quick Summary
- A web developer brought us a white-label client, then spent the project pushing us to make the website look more impressive; more sections, more images, borrowed layouts.
- We build websites as conversion assets, a means to an end, and the end is pipeline. He was treating the website as the product itself.
- The mechanism underneath it is the proxy trap: when the real outcome is hard to see, people optimise the visible stand-in for it. He couldn't show pipeline, so he showed polish.
Have you ever walked through a show home?
The kind a real estate developer builds to sell a housing project before it exists. Everything is perfect. The sofa is plump. The books on the shelf are colour-coordinated. There's a bowl of green apples on the kitchen counter.
So pick up an apple. It's plastic. Open a drawer, if it opens at all, and it's empty, or the handle comes away in your hand. The books are hollow.
Nobody has ever lived here, and nobody ever will. It was never built to be lived in. It was built to be looked at, so that someone would sign.
Most websites are show homes.
And not long ago, a web developer tried to get us to build one.
The revisions that didn't come from the client
A web developer we know brought us a client. White label; our work, his name on it. The client needed marketing and a website built, and the price on the table was fair. So we said yes.
My team built the site the way we build now: taking help from AI tools, fast and clean, structured around what the thing is actually supposed to do.
Then the revision rounds started.
And here's the strange part: the revisions weren't coming from the client. They were coming from the developer.
"Make this section look like this reference site." "Add more images here." "Change the colour of this block to match that other website." Round after round.
You get the idea. None of it was about whether the website worked. All of it was about whether the website looked like something.
Somewhere around the third or fourth "can you make it look more like this?" that my team dealt with, something clicked for me.
Two people, two definitions of the word "website"
Here's the thing: we don't think of a website as something you look at. We think of it as something that does a job.
To us, a website is a conversion asset. Conversion architecture. A means to an end, and the end is almost always pipeline. Leads. Revenue.
It's literally how we think about websites as a service. You build it, you put it to work, and if it isn't producing the outcome, you change it. The website serves the result, not the other way around.
The developer was working from a completely different definition.
In his world, the website is the product. The deliverable. The thing that justifies the invoice. And the way you prove a website is worth the money is to make it look expensive: more sections, more images, more visible craft.
Different game, different scoreboard. He wasn't asking us to make the website work. He was asking us to make it look like work, so he could walk into his client and show value for what he was charging.
A beautiful website that generates nothing isn't a success with a flaw. It's a failure wearing the costume of success.
The proxy trap
There's a mechanism underneath this, and it's worth naming, because once you have a name for it you'll see it everywhere.
When the real outcome is hard to see, the visible stand-in gets optimised instead.
Pipeline is slow, uncertain, and mostly invisible on the day you hand a website over. Polish is immediate, obvious, and easy to point at in a meeting. So polish becomes the proxy for value. And over enough repetitions, the proxy stops representing the outcome and quietly becomes the product.
That's what was happening, and I don't think it required any bad intent. He had no way to show his client the thing that actually mattered, so he showed the thing he could. The incentive structure did the rest.
Goodhart's law warns that a measure stops being a good measure once it becomes a target; this is the same failure one step earlier, where the proxy becomes the deliverable and stops pointing at anything at all.
You'll recognise it well outside web design. A dashboard full of activity standing in for revenue. Hours logged standing in for work done. Follower counts standing in for demand. Each proxy started as a reasonable signal, then swallowed the thing it was signalling.
| What you're looking at | Means-led (optimising the proxy) | Ends-led (optimising the outcome) |
|---|---|---|
| What "done" means | It looks the way we imagined it would. | It produced the result we agreed it was for. |
| When it ends | Never. There's always another reference site and another round. | At a checkpoint. It either worked or it didn't, and you act on the answer. |
| What it leaves behind | A deliverable that needs maintaining, and the next invoice. | An asset that keeps producing, and evidence of what works. |
| Who has to be satisfied | A person, by their taste. | A market, by its behaviour. |
That last row is the fastest tell there is. If satisfying the work means satisfying a person's taste, you're in means-led territory, and taste has no natural stopping point. If it means satisfying a market, you have an external referee, and the argument ends when the numbers speak.
The question that catches it early
So what do you actually do with this?
Most friction in client work isn't about quality. It's about definitions. When you and the person you're building for don't agree on what "done" means, every revision round becomes a quiet war over a question nobody said out loud.
Which gives you something to do before the work starts. Call it the "done" question:
Can both of us finish this sentence the same way? "This project is finished when ______."
Write your answer. Ask them for theirs. If yours says "the site is converting at a rate we're happy with" and theirs says "it looks as good as this reference site," you haven't found a small disagreement. You've found the entire project's future argument, on day one, while it still costs nothing to resolve.
Most people never ask, because at the start everyone is agreeable and the question feels almost rude. That's exactly why it's worth asking. The cheapest moment to discover a definition mismatch is before anyone has done any work.
You don't have a scope problem. You have two people quietly using the same word to mean two different things.
Who you work with compounds
And here's the part that matters for the long game.
A proxy has no terminal state. Looking good is not a condition you can satisfy, so means-led work resets with every round. You finish, and you're standing exactly where you started, only later. That's the treadmill: motion without distance.
An outcome behaves differently. It gets recorded. It becomes proof, which becomes the reason the next client says yes, which becomes a better client, which produces a better result. Nothing resets. Every round starts from higher ground than the last one.
Which is why the lesson from one small white-label project is bigger than the project. Work with people who can tell you what outcome they're buying, not what their homepage should resemble.
When you agree on the end, the means get simple, and you stop arguing about images and start measuring results.
We said yes to that project for a fair price, and I'd say yes again. Not for the money, but for the clarity. It told me, cleanly, which direction we walk from here.
Build for the end. Work with people who want the end.
And leave the plastic apples for the people who only ever wanted a show home.
