Pelumi Fatoye See the work
The build doc

My website is just a document.

Or: why every AI website looks the same, and the seven answers that fixed mine.

Pelumi Fatoye  ·  8 min read

I agreed with them.

For a long time I thought AI genuinely could not design. Every AI site I had seen looked like the same site. Purple gradient. Three feature cards. A headline about elevating your digital presence. Something that looked finished and felt like nothing.

Then I built mine with AI, and it came out looking like none of that.

So I went back to work out what was different, expecting the answer to be a clever prompt.

It wasn't a prompt. It was a document I wrote before I opened the model at all.


01The slop is not the model's fault.

Here is what happens when you type build me a modern portfolio site.

Modern is not a decision. It's a mood.

The model has no idea what you mean, so it does the only thing it can do. It gives you the average of every website it has ever seen. The middle of everything.

That middle is the purple gradient. That middle is Inter. That middle is "Elevate Your Digital Presence."

You didn't get a generic website because AI can't design.

You got one because you never decided anything, so it decided for you. And its decision is, by definition, the most average one available.

The fix isn't a better prompt. It's deciding first, in writing, before the model gets a vote.

02Seven answers, and the site builds itself.

I answered these before I built mine. Not in my head. On the page, in a file, in words a stranger could enforce.

01Who lands here, and what did they do thirty seconds ago?

Not a demographic. The action. Someone who clicked your link in a DM after you pitched them needs a different page from someone who found you in search. Mine: people who want me to build them something, arriving already knowing my name.

02What is the one thing they should do?

One. Not book a call or download the guide or follow me. Every extra option you add costs you the main one.

03What do they have to believe before they'll do it?

Write the objections in order. That order is your page. Mine went: can he actually build, is he fast, does the quality hold up. So the work sits near the top and the proof is specific instead of adjectival.

04What must this never look like?

The most useful question here, and the one everybody skips.

Mine: never an AI hype guru, never a course seller, never a beginner apologising for not being a developer.

Give the model that list word for word. It is far better at avoiding a named thing than at inventing an unnamed one. Most of my document is what the site is not.

05What are the actual words?

Write your headline and your first line yourself. Do not delegate this.

The model can write a hundred versions of your line. It cannot find your line, because your line comes from things it has never had access to.

Then write your banned words. Mine include delve, unlock, elevate, seamless, and anything ending in "-ify".

06What proof do you have, exactly?

Numbers you could defend if a stranger checked them. "Very productive" means nothing. "Eleven hundred lines in one sitting" means something, and it is either true or it isn't.

No numbers? Say what you did instead of how well you did it. Vague self praise reads as a lie even when it's true.

07What are the constraints?

Fonts, colour, motion, stack, page weight. Anything the model would otherwise pick at random.

I ban Inter, Roboto and Arial outright. Default fonts are the fastest way for a page to announce that a machine made it and nobody looked.

03Steal the prompt.

You will not enjoy writing this document. It's easier to type "make it modern" and hope.

So make the model do the extraction. Paste this into Claude and answer honestly.

Paste into Claude
You are interviewing me before I build a website with you. Do not write any code, copy, or design ideas yet. Your only job in this conversation is to get decisions out of me. Ask me these seven questions, one at a time, waiting for my answer before moving on: 1. Who lands on this page, and what did they do in the thirty seconds before they arrived? 2. What is the single action I want them to take? Only one is allowed. 3. What do they have to believe before they will take it? List the objections in the order they occur. 4. What must this site never look like? Three things, specific enough that a stranger could enforce them. 5. What is the headline and the first line, in my own words? Also: which words are banned? 6. What proof do I have that I could defend if someone checked it? 7. What are the hard constraints? Fonts, colour, motion, stack, page weight. Rules: ask one question at a time. Refuse vague answers. If I say "clean and modern", ask me what clean looks like and what it excludes. If I contradict something I said earlier, tell me. Do not move to the next question until the current answer is specific enough that you could hand it to a stranger and get the same result. When all seven are answered, write it up as BUILD.md. Structure it as: who it's for, the one action, the objections in order, the three nevers, the words, the proof, the constraints. Preserve my exact phrasing. Do not summarise me and do not improve my sentences. Then stop. Do not start building.

That last line matters. The model will want to start building at question three. Let it, and you are back to the middle of everything.

04Then, and only then, build.

Save the file. Every session after this starts the same way:

Every session
Read BUILD.md first. Then [what you want].

Three habits do most of the work after that.

Ask for the structure before the design. Sections in order, one sentence on why each exists. Argue with that list until it's right. A wrong section costs one line now and a rebuild later.

Build one section at a time. Ask for a whole page and you get a whole page of things to fix at once, and you will accept choices you don't like because rejecting them means starting over.

Keep every word in one file. On my site the copy lives in a single file, separate from the layout. Changing a sentence never means touching the design. This sounds like a technical detail. It is the difference between a site you edit and a site you leave broken.

05The part that stings.

The document took longer to write than the website took to build.

That was uncomfortable, until I understood it was the point.

The building was always the part that could be automated. Nobody was ever going to pay me for typing angle brackets. The deciding was never automatable, and now that the building is close to free, the deciding is the entire job.

Which means the skill is no longer "can you build a website".

It's whether you can say what you want with enough precision that a machine cannot get it wrong.

Most people can't. That's the whole gap. It has nothing to do with code.

I'm not a developer. I have never written a line of production code by hand. Everything I've shipped came out of documents like this one, and you can see all of it here.

Write yourself down first.

The site is the easy part.

One build, taken apart, every week.

What I wrote before I started, what broke in the middle, and the parts AI genuinely could not do. No hype, no tool lists.

Read the newsletter

Want one built for you? See the work