Pre-launch page for a Solana project: what to publish before you have users

This guide is for a specific reader: you are building on Solana, you have a working demo or a devnet deployment, you have no users yet, and the landing page is the first thing that has to work without you in the room. You are not running a Superteam bounty and you do not have a marketing hire. The page has to do the job alone.

Most pre-launch pages fail for one reason. They are written as if the product already exists at scale, so they make claims a visitor cannot check, and a visitor who cannot check anything assumes the worst. The fix is not better adjectives. It is to publish only what is true today, say it plainly, and make the next step small.

What a pre-launch page can honestly claim

Before launch you have four things a stranger can verify. Use them.

• A problem statement the visitor recognises. Name the exact friction: "You cannot borrow against locked stake without unstaking and losing the epoch" is checkable against the visitor's own experience. "Unlocking the next generation of DeFi" is not.
• Something that runs. A devnet link, a public repository, a recorded thirty-second walkthrough. Any one of these beats a roadmap graphic.
• Who is building it. Names with links, or a stated reason for pseudonymity plus a track record that can be inspected (past programs, past audits, commits). Silence on this question is read as hiding.
• A date. When the next thing ships. A page with no dates looks abandoned even if you commit daily.

What to leave out until it is true

• TVL, volume or user counts you do not have. A counter showing 0 is worse than no counter, and an invented number is discovered fast.
• Audit logos without a linked report. A logo alone says "we want you to think we were audited".
• Partnership logos for conversations that have not closed. Solana is a small world; the partner's team will see the page.
• Token language before there is a token. If there is no token, say so in one line; it removes the question that otherwise dominates every reply.
• A second call to action. "Join Discord" next to "Join waitlist" next to "Read docs" is three ways to leave.

The one-line test

Cover your logo and the word Solana. Read the hero to someone outside crypto. If they cannot say in one sentence what it does and for whom, the page is not ready, whatever the design looks like. Write the sentence they should say, then put that sentence in the hero.

Collecting the first hundred without a waitlist nobody joins

A generic waitlist converts badly because it asks for trust and offers nothing. Three alternatives that work before launch:

• Ask for the wallet, not the email, and say what the wallet gets: early access on a named date, a capped allocation, a role in testing. Make the thing specific and true.
• Offer the demo now, gated behind nothing. The people who try a devnet demo and come back are your first hundred, and you can see them on-chain.
• Publish the changelog on the page. A visible weekly update is the strongest pre-launch signal there is, and it costs a paragraph a week.

The page order that works

• Hero: one sentence, one action, no wallet-connect required to read.
• Proof: what runs, who builds it, the next dated milestone.
• How it works: three steps, each one sentence, written from the user's seat, not the protocol's.
• Who it is not for: one honest paragraph. Excluding the wrong visitor makes the right one trust you.
• Risks and status: devnet, unaudited, what could go wrong. Founders fear this section; visitors reward it.
• The single action again.

Technical checks that take five minutes

• The tab title. If it reads "Vite App" or "React App", that is what appears in every shared link and search result.
• A meta description. Without one, the search snippet is whatever text the crawler finds first, often the cookie notice.
• Every footer link. A dead docs link or an empty Twitter profile is read as a signal about the product.
• Mobile, logged out, wallet disconnected, with a timer. That is how most first visits happen.

When a written teardown is worth paying for

If you fail the one-line test, fix the hero yourself; you do not need help for that. A teardown earns its price when the page passes the obvious checks and still does not convert, or when you cannot tell which of three possible positionings a stranger would understand. The teardown is a written document: what a sceptical first-time visitor concludes at each scroll depth, what to write instead and in what order, and how the page reads against the two or three alternatives that visitor is comparing you with. It is delivered by email within 24 hours of a matched USDC payment on Solana. Nothing is sent before payment, and nothing is charged before you accept the quote.