From Zero to Launch: The Content Playbook We Used for dumMySQL
The Problem: Another Tool Nobody Would Find
In mid-July 2026, Patrick came to us with a problem that every developer founder recognizes. dumMySQL was functionally complete. The code was clean. The README didn’t make people cry. But the landing page was a placeholder, the GitHub repo was still private, and the only people who knew the tool existed were the three people who built it.
The developer tool graveyard is full of repos like this. Technically ready. Narratively invisible.
We had seven days until the first launch window. Not seven weeks. Not seven months. Seven actual days. And the stakes were specific: if dumMySQL didn’t generate traction in its first week, it would compete for attention against a crowded field of database management tools — phpMyAdmin, Adminer, TablePlus, QueryGlow — without the brand recognition to stand out.
The challenge wasn’t building more features. It was building a launch story that developers would actually read, share, and remember.
Our Approach: Treat Content as a Launch-Critical System
Most teams treat launch content as a marketing afterthought. They write a landing page, post once on Twitter, and wonder why GitHub stars flatline. We took the opposite approach: we treated content as a product discipline with the same urgency as shipping code.
Our philosophy was simple. Every launch channel requires a different story angle. Same product. Same positioning. Different wrapper. Hacker News wants technical architecture and honest limitations. Product Hunt wants visual storytelling and maker transparency. Reddit wants personal frustration and genuine conversation. One post cross-posted to all three gets roasted on HN, ignored on PH, and removed on Reddit.
We also committed to transparency over polish. Developers distrust marketing gloss. A post that admits “our Product Hunt thumbnail was wrong” or “we emailed too late” earns more trust than a polished case study that smells like agency work.
With that framework in mind, we gave ourselves one week and a clear sequence.
The Timeline: Seven Days from Repo to Launch-Ready
Day 1–2: Positioning and Asset Creation
Hour 1–3: Write the positioning doc.
This was the single most important document in the entire launch. It was one page:
- Problem statement: phpMyAdmin terrifies non-technical team members, and the alternatives are either overpriced or overengineered.
- Target user: Developers tired of being the only person on their team who can safely open phpMyAdmin.
- Differentiation: Your content manager can use this without a safety briefing.
- Voice and tone: Humble, technical, playful.
- Proof points: Beta testers from three companies already using it daily.
The key insight was emotional, not technical. The target user wasn’t “developers who manage databases.” It was “developers tired of being the only person on their team who can safely open phpMyAdmin.” That reframing unlocked everything.
Hour 4–8: Build the three-channel narrative.
Each channel got its own draft:
| Channel | Audience | Angle | Tone |
|---|---|---|---|
| Product Hunt | Makers, founders, early adopters | “The tool I wish existed” — personal founder story, gallery-first, pricing transparency | Conversational, visual, honest about limitations |
| Hacker News | Senior developers, technical leads | “Show HN” — vanilla-JS architecture, self-hosting, open-source ethos, genuine technical question | Humble, self-critical, no marketing language |
| Reddit (r/SideProject, r/webdev) | Indie hackers, bootstrappers | “I built this because I was frustrated” — personal problem, honest state of product, invitation to break it | Casual, authentic, self-deprecating |
For Product Hunt, the narrative led with the CHF 1.- pricing as a statement against subscription fatigue. For Hacker News, it led with the vanilla-JS architecture and an honest admission that the backend was PHP. For Reddit, it led with the origin story: Patrick watched our content manager close phpMyAdmin and ask him to “just pull the user table” for the 47th time.
Day 2 evening: Create the comparison table and FAQ.
Developers evaluate tools comparatively. We built a five-column comparison — phpMyAdmin, Adminer, TablePlus, QueryGlow, and dumMySQL — that didn’t claim superiority. It claimed specificity.
The FAQ addressed the objections we knew we’d see in comments: “Why PHP?”, “Why so cheap?”, and “Is this just phpMyAdmin with lipstick?”
Day 3–4: Asset Production
We built the full asset stack in forty-eight hours:
- 7 Product Hunt gallery images: hero screenshot, feature highlight, before/after comparison, social proof, pricing card, demo GIF, maker photo
- Hacker News “Show HN” post with live demo link and honest limitations list
- Reddit r/SideProject post with personal origin story and direct ask for feedback
- 3-email launch sequence for our warmest audience
- 10-tweet thread covering the origin problem, the “why PHP” confession, pricing philosophy, and a direct ask for feedback
- Pre-written first comments for each channel
- Response playbook with tone guidelines for HN (technical depth), PH (maker transparency), and Reddit (casual helpfulness)
Day 5–6: Technical Prep and Soft Launch
Pavel rebuilt the landing page with visual-first design. We verified SSL, checked all CTAs, and staged the GitHub repo for public release. Rick seeded the Product Hunt support squad and scouted Hacker News for the optimal posting window.
We ran a soft launch on Reddit and Indie Hackers to test messaging and gather early feedback. The Reddit post drove beta signups and recruited PH support squad members. The feedback was immediate and unfiltered — exactly what we needed.
Day 7: Launch Day
The Hacker News post went live at 09:00 CET on a Tuesday — historically the highest-engagement window for “Show HN” posts. We had a 4-hour on-call rotation because the first 4 hours determine the first 24.
The Channels: What We Posted Where
Hacker News
Title: Show HN: dumMySQL — A team-friendly database manager that won’t scare your content manager
Approach: Led with technical architecture (vanilla JS frontend, PHP backend), included a live demo with no signup required, and asked a genuine technical question about self-hosting security patterns.
Result: 50+ upvotes and genuine technical discussion. No front-page, but sustained engagement for 6+ hours with substantive comments about PHP performance and self-hosting workflows.
Subreddit: r/SideProject and r/webdev
Approach: Personal origin story, honest state of product, invitation to break it.
Result: Drove beta signups and recruited 15+ Product Hunt support squad members. The most valuable feedback came from critical comments about the UI flow — feedback we incorporated before the Product Hunt launch.
Product Hunt
Status: Scheduled for early August with full gallery, briefed support squad of 50+ users, and a first comment that tells a human story.
Approach: Gallery-first, pricing transparency, maker reply with honest state of features.
Email Sequence
Three emails to our warmest audience:
– Email 1 (launch day): “It’s live. Here’s where to find us.”
– Email 2 (launch day + 4 hours): “Here’s what’s happening.” — early traction, social proof
– Email 3 (day after): “Thank you + what’s next.” — metrics summary, roadmap tease
The Results: Raw Numbers Beat Vague Superlatives
Here is what happened in the first 72 hours after the Hacker News and Reddit launches:
| Metric | Result |
|---|---|
| Hacker News upvotes | 50+ |
| Hacker News comments | 18 substantive technical discussions |
| Reddit r/SideProject upvotes | 120+ |
| Reddit comments | 34 (mix of feedback, criticism, and encouragement) |
| Beta signups (24h) | 47 |
| Beta signups (72h) | 83 |
| Product Hunt support squad | 50+ users briefed and ready |
| GitHub stars (first week) | 34 |
| Landing page sessions (72h) | 1,247 |
| Top referral source | Hacker News (38% of traffic) |
| Second referral source | Reddit (29% of traffic) |
| Email open rate | 62% |
| Email click-through rate | 24% |
These are not unicorn numbers. They are honest numbers. And that is exactly the point.
What Went Wrong: Three Misfires
A launch retrospective without honest audit is just a brag sheet. Here are three things that did not go according to plan.
Misfire 1: The Product Hunt thumbnail was wrong.
Our first hero image for Product Hunt used a screenshot with dummy data that included a fake email address ending in “@example.com.” Three beta testers pointed out that it looked unprofessional. We replaced it with a real database schema screenshot from our own content management system.
Misfire 2: We emailed too late.
Email 1 of our launch sequence went out at 11:00 CET instead of 09:00 CET. By the time it hit inboxes, the Hacker News post had already peaked. Open rates were solid (62%), but click-through rates were 8 percentage points lower than our benchmark. The lesson: email should lead the launch, not follow it.
Misfire 3: The GitHub repo went public without a CONTRIBUTING.md.
We flipped the repo to public in the excitement of launch day and forgot to add contribution guidelines. Two developers opened issues asking how to contribute before we caught it. A small oversight, but it made us look less organized than we were.
The Playbook: A Replicable Checklist
Here is the distilled checklist we used for dumMySQL. You can adapt it to any developer tool launch.
Pre-Launch (Days 1–2)
- [ ] Write the one-page positioning doc (problem, user, differentiation, voice, proof)
- [ ] Draft channel-specific narratives for HN, PH, and Reddit — do not cross-post the same text
- [ ] Build competitive comparison table and FAQ
- [ ] Create response playbook with tone guidelines per channel
Asset Production (Days 3–4)
- [ ] 5–7 Product Hunt gallery images (hero, feature, comparison, social proof, pricing, demo, maker)
- [ ] Hacker News post with live demo link and honest limitations
- [ ] Reddit post with personal origin story and direct feedback ask
- [ ] 3-email launch sequence
- [ ] 10-tweet social thread
- [ ] Pre-written first comments for each channel
Technical Prep (Days 5–6)
- [ ] Landing page live with all CTAs tested
- [ ] GitHub repo public with README, CONTRIBUTING.md, and license
- [ ] Demo environment stable and signup-free
- [ ] Support squad briefed (aim for 30+ users who will upvote and comment)
Launch Day
- [ ] Post HN at 09:00 CET Tuesday for maximum engagement
- [ ] Send Email 1 at 08:30 CET (before HN post)
- [ ] Execute 4-hour on-call rotation for comment responses
- [ ] Post Reddit 2 hours after HN to ride momentum without overlap
- [ ] Track metrics in real-time spreadsheet
Post-Launch (Days 2–7)
- [ ] Respond to every comment with substance
- [ ] Send Email 2 (traction update) at +4 hours
- [ ] Send Email 3 (thank you + roadmap) next day
- [ ] Document lessons learned for next launch cycle
What We Learned: Integration Beats Perfection
The dumMySQL launch taught us something that contradicts most startup advice. You do not need six months of content planning. You do not need a marketing agency. You do not need perfect assets.
What you need is 48 focused hours, a positioning doc, and the discipline to tell three different true stories to three different communities.
The teams that sustain momentum after launch do four things differently:
They respond to every comment with substance. On HN, technical depth. On PH, maker transparency. On Reddit, casual helpfulness.
They ship content after launch. “Building in Public” updates, technical deep-dives, and honest post-mortems build long-term community reputation.
They optimize for the future. In 2026, AI agents consume APIs and documentation before humans do. Content must be structured for Generative Engine Optimization — clear headings, explicit FAQs, quotable stats.
They measure the right things. GitHub stars are vanity. Track qualified traffic from each channel, time-to-first-issue, and whether people who discovered you on HN are still using you three months later.
What’s Next for dumMySQL
The early-August Product Hunt launch is the next critical window. We have a full gallery, a briefed support squad of 50+ users, and a first comment that tells a human story. After that, the focus shifts to sustained community building: technical deep-dives, open-source contributions, and the next feature release.
If you’re launching a developer tool in the next quarter, steal this playbook. Adapt it. Improve it. And then tell us what you learned — because the best launch content is the content that keeps launching.
The best developer tools fail without distribution. A technical product — no matter how good — is invisible without a content strategy that speaks to developers, decision-makers, and the communities they trust.