The pre-launch playbook for developer tools
A week by week plan for the eight weeks before you launch a developer tool, from building in public to launch day.
· 7 min read
Most developer tools do not fail on launch day. They fail in the eight weeks before it, when nobody outside the team knows the product exists. This playbook breaks that period into steps you can actually schedule.
Eight weeks out: define who it is for
Write a one sentence description of your first user. Not "developers", but something like "backend engineers at startups who run Postgres and ship preview deployments for every pull request."
That sentence decides where you post, what your teaser shows, and which features you mention first. Everything else in this playbook depends on it.
Seven weeks out: open a waitlist
Put up a simple page with:
- A tagline that names the problem
- One screenshot or short clip of the real product
- An email field
- An expected launch month
You do not need a finished product to start collecting interest. You need a clear promise and a way to keep in touch.
Six weeks out: start building in public
Share progress where your first users already spend time. Useful formats:
- Short clips of a feature working for the first time
- Honest notes on a hard technical problem you solved
- Benchmarks with the method explained, so people can reproduce them
Post consistently rather than loudly. Two specific updates a week beat one vague announcement a month.
Five weeks out: list your tool
Submit your tool to directories that developers browse for new products, including TeaserTrack. A listing with your teaser, launch date, and waitlist link works for you around the clock and gives early supporters somewhere to upvote.
Four weeks out: invite a small beta group
Pick 10 to 30 people from your waitlist who match your first user sentence. Talk to each of them. Watch at least three people use the product live. You will find onboarding problems in the first ten minutes that no internal test caught.
Three weeks out: fix the first hour
Use beta feedback to polish only the first hour of the experience:
- Signup and installation
- The first successful result
- The moment someone understands why the tool is better than what they use today
Features can wait. A confusing first hour cannot.
Two weeks out: prepare launch assets
Get these ready before launch week, not during it:
- An updated teaser video under 30 seconds
- A launch post that explains the problem, the approach, and what is next
- Documentation for installation and the three most common tasks
- Clear pricing, even if the answer is "free during beta"
One week out: line up your supporters
Email your waitlist with the exact launch date. Ask beta users if they are comfortable sharing honest feedback publicly on the day. Do not ask anyone to post fake enthusiasm. Developers can tell.
Launch day
Ship early in the day, post your launch in the places you have been building in public, and spend the rest of the day answering every question personally. Update your TeaserTrack listing status to launched so people arriving from search see the current state.
The launch is not the finish line. It is the first day your product has to earn attention without the novelty of being upcoming. The work you did in the previous eight weeks is what carries it.
Keep reading
· 6 min read
How to spot rising open source projects before everyone else
A repeatable routine for finding promising new GitHub projects early, telling real momentum from hype, and deciding which ones deserve your attention.
· 5 min read
Are GitHub stars a good signal? What they tell you and what they hide
Stars are the most visible number on GitHub and one of the easiest to misread. Here is how to interpret them, and which signals to check alongside them.
· 6 min read
The waitlist page essentials for developer tools
What a pre-launch waitlist page needs to convert developers: a sharp headline, a real product shot, a one field form, and a reason to come back.