On this page9
- Why most startup whitepapers don't work
- What's included in the Whitepaper Sprint
- Writing for three readers at once
- Week-by-week: how the 4 weeks run
- The outline you approve in week 1
- The launch comms plan: why the paper doesn't sit on your site
- Who the Whitepaper Sprint fits
- Objections founders raise
- Getting started
Whitepaper Sprint: A Launch-Ready Whitepaper in 4 Weeks
The Whitepaper Sprint is my whitepaper writing service for Web3 and AI startups: $9,500 for an 8,000 to 15,000 word whitepaper delivered in 4 weeks. It includes positioning work, two technical interviews with your team, a glossary and full citations, two revision rounds, and a launch comms plan so the paper actually gets read. Design is billed separately. You get a document your engineers will sign off on and your investors, partners and reporters can understand.
Most whitepapers fail one of those two audiences. The sprint is built to serve both.
Why most startup whitepapers don't work
I read a lot of whitepapers in six years of placing Web3 and AI founders in CoinDesk, Cointelegraph, Decrypt, The Block and Forbes. They tend to fail in one of three ways.
The engineer's draft. Technically correct, 40 pages, no argument. A reporter skims page one, finds no claim, closes the tab.
The marketer's draft. Readable, full of adjectives, light on mechanism. Technical readers stop trusting it by page three, and once they stop trusting it, they say so in public.
The never-finished draft. Started six months ago, three authors, four versions in a shared folder, and a launch date that keeps moving because the paper isn't ready.
A whitepaper is a positioning document wearing a technical costume. It should make one clear argument about why your approach is right, then prove it with enough mechanism that a skeptical expert can check the work.
What's included in the Whitepaper Sprint
| Deliverable | Detail |
|---|---|
| Positioning session | Agree the core argument, the audiences, and what the paper must make a reader believe |
| Two technical interviews | Usually your CTO or lead researcher plus one other technical owner, recorded and transcribed |
| Full manuscript | 8,000 to 15,000 words, structured for both skimmers and experts |
| Glossary | Every term a non-specialist reader might trip on, defined once |
| Citations | Sourced claims, references to prior work, and clear separation of your claims from established fact |
| Two revision rounds | Consolidated feedback from your team each round |
| Launch comms plan | How the paper gets announced, who gets it under embargo, and what derivative content comes out of it |
| Price | $9,500 total, 4 weeks, design billed separately |
What's not included: visual design and layout, diagrams beyond rough sketches for your designer, legal review, and token economic modelling. If you have a tokenomics section, I'll write it from the model your team or economist provides. I won't invent the numbers.
Writing for three readers at once
Every whitepaper I write is checked against three readers before it ships. If any one of them gives up, the paper has a hole.
| Reader | What they read | What they need to walk away with |
|---|---|---|
| The skeptical engineer | Architecture, security assumptions, comparisons | Confidence the design holds up and the trade-offs are stated honestly |
| The investor or partner | Abstract, problem, design goals, roadmap | A clear thesis and a reason this team will win |
| The reporter or analyst | Abstract, first two pages, glossary | One quotable claim and enough context to explain it to their readers |
This is why the abstract matters more than any other 150 words in the document. Reporters, analysts and AI assistants all lean on it. If it reads like a list of features, the paper gets summarised as a list of features. If it states an argument, the paper gets summarised as an argument.
It's also why the glossary isn't an afterthought. A term your team uses daily, like "intent solver" or "inference routing", can lose a non-specialist reader in a single sentence. Defining it once, plainly, keeps the investor and the reporter reading long enough to reach your actual point.
Week-by-week: how the 4 weeks run
| Week | What I do | What you do | Output |
|---|---|---|---|
| 1 | Positioning session, read everything you have (docs, repos, decks, prior drafts), first technical interview | 90-minute positioning call, 60-minute interview, share materials | One-page argument and outline you approve |
| 2 | Second technical interview, full first draft | 60-minute interview, answer follow-up questions in writing | Complete first draft with glossary and citation placeholders |
| 3 | Revision round one, citations completed, technical gaps closed | Consolidated team feedback within 3 working days | Second draft |
| 4 | Revision round two, final polish, launch comms plan | Final feedback, sign-off | Final manuscript ready for design, plus comms plan |
The schedule depends on one thing more than anything else: consolidated feedback. If five people each send separate comments at different times, week 3 turns into week 5. I ask for one owner on your side who merges comments before they come back.
The outline you approve in week 1
Before a word of the draft gets written, you sign off on a structure like this. It's the cheapest point to change direction.
WHITEPAPER OUTLINE (illustrative)
1. Abstract (150 words, the whole argument in plain language)
2. The problem, with evidence (why current approaches fall short)
3. Design goals (what a good solution must do)
4. Architecture (how the system works, component by component)
5. Security and trust assumptions (what you rely on, what breaks if it fails)
6. Economics or business model (only what the team has modelled)
7. Comparison with alternatives (fair, specific, no strawmen)
8. Roadmap (dated where you are confident, undated where not)
9. Glossary
10. ReferencesThe launch comms plan: why the paper doesn't sit on your site
A whitepaper that launches with a single tweet gets read by your existing followers and nobody else. The comms plan in week 4 maps how the paper becomes press and content.
- Which two or three reporters get the paper early, under embargo, with a short briefing note
- The one-paragraph news angle a reporter could actually write up
- A founder op-ed that argues the paper's thesis in 900 words
- A thread and a LinkedIn post for launch day
- Three to five standalone explainers cut from the paper's sections
- FAQ copy for your docs or site, written so AI assistants can quote it cleanly
If you want me to run the launch itself rather than just plan it, that's a separate engagement: a token launch PR program for a TGE, or an AI product launch PR plan for a product release.
Who the Whitepaper Sprint fits
Good fit:
- A Web3 protocol, L1, L2 or infrastructure project heading toward mainnet or TGE
- An AI infrastructure or research-led startup that needs a technical document investors and enterprise buyers will read
- A team with a working system or a detailed design, not just an idea
- A CTO or lead researcher who can give two hours of interviews
Poor fit:
- You need a paper in under two weeks
- The architecture isn't decided yet (write the design doc first, then the whitepaper)
- You want a sales brochure called a whitepaper
- You need academic peer-review-grade research written from scratch
Objections founders raise
"Our engineers could write this." They could write the technical sections, and they'll be accurate. The interviews exist to capture exactly that accuracy. What engineers usually don't have is the time, or the habit of writing for a reader who isn't an engineer. The sprint frees them to review rather than draft.
"$9,500 seems like a lot for writing." You're paying for a positioning argument, two rounds of technical revision, citations a skeptical reader can check, and a launch plan. Compare it to the cost of your CTO spending six weeks on a draft that still isn't finished.
"Can you write the tokenomics?" I'll write the section clearly from your model. I won't design the model or project prices. That's for your economists and lawyers.
"What about AI startups that don't need a whitepaper?" Many don't. A technical blog post or a research note may do the job. I'll say so on the first call. There's more on that decision in the AI startup whitepaper playbook.
Getting started
Send me whatever you have: a deck, a design doc, a half-finished draft, a repo. In a 30-minute call I'll tell you whether the 4-week sprint is realistic for your timeline, what the core argument looks like from the outside, and what's missing. Scope details live on the content writing service page, and there's a crypto-specific overview at crypto whitepaper writing service.
A whitepaper is the one document every serious reader of your project will eventually open. It should be the best thing you've published.
Launching in the next quarter? Book a 30-minute whitepaper scoping call.