The startup website: what to build before you have a product
Early-stage companies get websites wrong in two opposite directions. Either a single โcoming soonโ page that sits there for eight months collecting nothing, or a full platform built for a scale the business has not reached and may never need in that shape.
The useful question is not โwhat should our website have?โ It is โwhat is the one thing we need to learn next?โ
Stage 1: before you have a product
You need to find out whether anyone wants the thing. The website's only job is to explain the promise clearly and capture people who react to it.
- One page. The problem, your answer, who it is for, and one action.
- An email capture that goes somewhere you will actually read.
- Enough clarity that a stranger can repeat your value proposition back to you. If they cannot, no amount of design fixes it.
Skip: the blog, the team page, the pricing table for a product that does not exist, and the custom illustration set.
Stage 2: you have something to show
Now the job is conversion โ turning interest into trials, demos or first customers.
- A page per core use case, because different buyers arrive with different problems.
- Pricing, even if provisional. Hiding it filters out the serious buyers, not the tyre-kickers.
- Whatever proof you honestly have: a named pilot customer who agreed, a real screenshot, a number you can stand behind. Nothing invented โ an early-stage company caught fabricating traction never fully recovers.
- One obvious next step on every page.
Stage 3: you are growing
Now the site has to be found, and has to keep working while you change it weekly.
- Content that answers the questions your sales conversations keep repeating.
- A CMS, so marketing can publish without a developer in the loop.
- Analytics that tell you which pages produce pipeline, not which produce traffic.
- Internal tooling, once a manual process becomes the bottleneck โ see the software we build for what that usually looks like.
- Speed and accessibility done properly, because retrofitting both is more expensive than building them in.
Choose a stack you can leave
The most expensive early decision is not the platform โ it is a platform you cannot exit. Before you commit, ask: can we export the content? Can another developer pick this up? Is anything here locked to one supplier?
Everything we build is documented and handed over for exactly this reason. Work you cannot move is not worth buying.
The mistake that costs the most
Building for the company you hope to be in three years. Three-year plans change; the cost of the platform built for the old one does not. Build for the next six months, and build it so the six months after that are cheap.
What actually matters early
Clarity beats craft, speed beats features, and honesty beats polish. A plain page that says exactly what you do will out-convert a beautiful one that does not โ every time.
More on how we work with early-stage teams on the startups page, and the argument for working the whole stack rather than four suppliers is on why seven layers. When you want a figure, book a call.