Summarize with AI
Yes, founders should write their own website copy, but only the first draft. You are the one person who knows what the product takes in, what it hands back and what it replaces, so the facts have to come from you. You should never be the last person to read it, because you fill every vague line with knowledge the visitor does not have.
That split matters more than who holds the pen. A seed-stage founder usually writes the page alone, shows it to people who already know the pitch, and ships it when they nod. Every reviewer in that loop reads the page the way he does. The visitor from a search result cannot, and his reading is the one that decides the demos booked.
Homepage copy v6, and one comment on the word orchestration
Picture an AI tool for inbound sales, used here as an example and not a client. A visitor fills in the demo form on a software company's website. The tool looks up the visitor's company, checks it against the ideal customer list, picks the right sales rep by territory and existing account owner, and puts a meeting on that rep's calendar before the visitor has left the thank you page.
The founder keeps the homepage in a Google Doc called Homepage copy v6. The headline reads Context-aware orchestration for revenue workflows. The subhead reads Route, enrich and act on every signal across your go-to-market stack. One button sits under it: Book a demo. The words form, rep, calendar and meeting do not appear anywhere on the first screen.
The comment thread on the headline tells the story of how it got there. His cofounder wrote love v6. An angel who has heard the pitch four times wrote much tighter than v5. Then a support hire on her third day, asked to proofread for typos, left a comment on the word orchestration: Orchestration of what? Is this the thing that books the meeting? She had sat through onboarding the day before and still could not get from the headline to the product.
Why six drafts passed the founder's own read
Every word in the headline is accurate. That is the trap. When the founder reads context, he sees the enrichment lookup and the account owner field in the CRM. When he reads orchestration, he sees the routing rules he spent four months tuning. When he reads revenue workflows, he sees one specific workflow, the demo request. The sentence is a set of pointers, and he is the only reader who has the files they point to.
So each rewrite looked better to him. Version three swapped platform for orchestration because a prospect once called it a platform and he wanted to sound bigger. Version five added context-aware because the competitor in the next tab said AI-powered and he wanted a sharper phrase. None of the six versions said what goes in and what comes out. Each one was reviewed by people who could already answer that question, so nobody noticed it was missing.
You can hear it on his calls. A prospect from the homepage opens with some version of so what does it actually do? He spends the first ten minutes explaining the page, then gives the real demo.
The facts only the founder can write down
Nobody outside the company can write the first draft, and handing it to a copywriter on day one usually produces the opposite problem: clean sentences built on a guess. What the founder owns is not the wording. It is the facts the wording has to carry. Write them down as a plain list before anyone touches the hero.
- What goes in. The demo form submission, with the visitor's work email.
- What comes back. A booked meeting on the right rep's calendar, before the visitor leaves the page.
- What it replaces. A person who reads the form the next morning and forwards it, while the visitor books a call with someone else.
- Who it is for. Sales teams at software companies with more than one rep and more than one territory.
- What it does not do. It does not write emails or score deals. Saying so stops the wrong demos.
- The proof you can show. One real routing rule, one real calendar screen, one real time from form to booked call.
That list is dull on purpose, and no hired writer can invent it. You can see those facts reach a page intact in a real project. Armaku's founder is quoted on the Sawdust website case study, asking for a site that explains how fragmented music licensing is without making it only about that. The structural fact underneath, one owner for every layer of every track, is something only Sawdust could state. The page lays it out as seven rights, master recording, composition, performer rights and four more, each with a short line a brand can read, and puts the price on the page from the start.
Who should read it last, and what most advice gets wrong
Most advice on this question picks one side. One camp says the founder knows the product best, so he should write every word. The other says founders are too close, so hire a copywriter and stay out of it. Both make one person do two jobs. The founder is the right person to check that a line is true. He is the wrong person to check that a line is clear, and no amount of effort fixes that, because he cannot forget what he knows.
So split the sign-off. The founder signs for accuracy: is every claim on the page true, and is anything important missing? A stranger signs for clarity: after reading the first screen, can she say what goes in and what comes out? The page ships only when both say yes. The last reader before it goes live should be someone who has never heard the pitch, not the cofounder, not an investor and not a friend who has had the company explained over dinner.
The support hire was the most useful reviewer in that Google Doc, and she was only there by accident. Make it deliberate. If you want a structured way to run that read, the five second test for a SaaS homepage walks through it with five strangers and a scoring sheet. This post only argues that the test has to come last, after every internal round, so nobody who knows the answer gets the final word.
Where an AI draft helps, and why a briefed chatbot is not a stranger
Most founders now write the hero with a model open in the other tab. It is good at turning a messy fact list into ten candidate headlines in a minute. Use it for volume.
It is bad at being the last reader, and founders reach for it there more than anywhere else. You paste in the deck, the product docs and the old homepage, then ask whether the new headline is clear. The model says yes, because it now knows what orchestration means here. You gave it the files the pointers point to. A chatbot you briefed has the same blind spot you have, only faster. A model can stand in for a stranger only when it knows nothing but the page, and using ChatGPT to review a landing page shows how to set that up. Even then, a person who matches your buyer still reads last.
The best words come from your buyers, not a model. Pulling them out of recorded calls is covered in voice of customer copywriting from sales calls.
What a page only the founder can read costs
Every visitor on that homepage was paid for, in ads, in content, or in the founder's evenings on LinkedIn. A hero only he can decode does not lose those visitors loudly. It turns some of them into calls that start with what does it do, and lets the rest leave without a trace in the analytics beyond a short visit.
The calls are the expensive part. Ten minutes of each first call spent rebuilding the homepage out loud is time the founder is not spending on the buyers who were ready. Some of those calls should never have been booked, because the visitor wanted an email tool and the vague headline did not rule that out. At seed, the founder's calendar is the sales team.
Then there is the raise. With the Series A bar for AI startups around 3.5 million in ARR, up from roughly one million three years earlier (Carta, Q1 2026), and roughly 70 percent of seed companies never raising a Series A, a website that sends confused traffic into the founder's calendar is a slow drain on the one resource he cannot buy more of.
A two-signature routine you can run this week
This takes one afternoon and two short calls, whoever writes the final words.
- Write the fact list first. Six lines: what goes in, what comes back, what it replaces, who it is for, what it does not do, and the proof you can show. No adjectives. If a line needs one, the fact is not clear yet.
- Draft the hero from the list, yourself. Your own words, the way you say it in the first minute of a demo. It does not need to be good. It needs to carry every fact on the list.
- Sign for accuracy. Read the draft against the fact list. Every line on the first screen should trace to a line on the list. Cut anything that does not.
- Find one stranger. Someone who roughly matches your buyer and has never heard the pitch. A new hire counts once, in her first week.
- Let the stranger sign for clarity. Show only the first screen. Ask what the product takes in and what it hands back. Write down the answer word for word and do not explain anything.
- Fix only what the stranger missed. If she could not name the input, the input goes in the headline. Then find a new stranger for the next round, because the first one now knows.
When the fact list is solid but three rounds of strangers still cannot say what the product does, the problem is usually bigger than the headline: the product image, the section order and the button all point somewhere else. That is the point to hand the list to a website design team rather than write v7. Studio Maydit designs websites for AI founders in the US, UK and Europe and builds them in Framer, Webflow or custom code, as a fixed scope of three to four weeks that ends with a diagnosis of what is leaking in the product. Recent clients include Wave, PixelFlow and Mi-VAD. If you have the fact list and a hero only your team can read, book a 45 minute call and bring both.
