Latest / The Indie Hacker Podcast with Fexingo: Solo Developers, SaaS Side Projects, and Independent Tech / How One Solo Dev Uses Public Roadmaps to Grow ARR
Transcript
- Lucas: So there's this solo developer I've been following—let's call him Mark—who runs a SaaS tool for freelance writers called Draftwell. Nothing flashy, just a clean editor with version history and client invoicing. Luna: Okay, I've seen tools like that. Hard to differentiate, right? Lucas: Exactly. Mark was stuck around 60K ARR for about a year. Then he did something counterintuitive: he published his entire product roadmap publicly. Not just a vague 'we're working on things'—a full Kanban board on Trello with every planned feature, bug fix, and even experiments he might kill. Luna: Wait, that's scary. What if competitors copy him or users get upset when things slip? Lucas: Those are real risks, and we'll get to them. But within eight months, his ARR doubled to 120K. The key was that he gave paying subscribers extra voting power on features—one vote for free users, three for paid. Suddenly, his roadmap became a retention tool. Luna: So the act of voting itself made people feel invested. They're not just users; they're stakeholders. Lucas: Right. And Mark told me something interesting: he got way fewer 'where is feature X' support tickets. Because users could see exactly where X sat in the queue. Transparency absorbed the frustration. Luna: How did he handle things like security fixes or compliance updates—stuff you don't necessarily want to broadcast? Lucas: He had a separate 'internal' lane for things like that—visible to him only but with a generic label like 'infrastructure'. The public board showed only user-facing items. He also added a 'shipped' column with a little celebration emoji every time something went live. Luna: That's genius. It creates a positive feedback loop: users vote, feature ships, they feel heard, they stay. But does this work for every niche? Lucas: Not automatically. I talked to another solo dev who tried the exact same approach with a project management tool for event planners. Six months in, zero change in churn or conversion. The difference? His users were event planners—they didn't care about the roadmap. They just wanted the tool to work. Luna: So the audience matters. Draftwell's writers are probably more technical, more curious about the product. Lucas: Exactly. Mark's users are solo writers or small agencies—they live in tools like this all day. They're the kind of people who read changelogs. For event planners, the software is just a means to an end. Luna: That's a great point. So before copying Mark's playbook, you should survey your users: do they even want to see the roadmap? Lucas: Mark actually did that. He sent a one-question email: 'Would you like to see what we're building next?' 40% said yes. That was his green light. He also started with a private beta of the roadmap for just his top 20 paying customers. Got feedback, iterated, then made it public. Luna: Smart. So the roadmap itself was built in public, sort of. What about the risk of competitors copying features? Lucas: Mark's take was: if a competitor is just copying my roadmap, they're behind me anyway because I'm already building it. And by the time they ship, he's shipped and moved on. He also said that his specific execution—like tight integration with Writers Guild rates—is hard to clone. Luna: That's the moat. Niche knowledge plus transparency. Lucas: Let's talk numbers. Before the roadmap, Draftwell's monthly churn was about 7%. Eight months later, it's down to 4%. That alone accounts for about half the ARR growth. The other half came from word of mouth: users sharing the roadmap on Twitter and in writer forums. Luna: So the roadmap became a marketing asset. People love seeing a product evolve in real time. Lucas: Yeah. Mark said one specific tweet with a screenshot of his 'in progress' column got 50,000 views. That led to about 200 free sign-ups and 15 conversions to paid. Not huge, but for a solo dev, that's a week's worth of work. Luna: Fifteen new paying customers from one tweet. That's a strong ROI for zero ad spend. Lucas: And it compounds. Every time he ships a feature, he tweets about it. Some of those tweets get picked up by writer newsletters. The roadmap gives him a constant content engine. Luna: I can see the appeal, but I wonder about the emotional toll. You're putting your prioritization decisions on display. Users will see if you deprioritize their pet feature. Lucas: That's the downside. Mark told me about one user who was furious that a certain integration got bumped. He had to write a personal email explaining the reasoning. Most users were understanding, but it's extra emotional labor. Luna: So there's a psychological cost. You need thick skin. Lucas: Absolutely. But Mark says it's worth it because the feedback he gets from votes is higher quality than any survey. He realized that users weren't asking for the features they actually needed—they were asking for what they thought was possible. The roadmap votes revealed deeper needs. Luna: Can you give an example? Lucas: Sure. Writers kept voting for a grammar checker integration. Mark assumed they wanted something like Grammarly. But in comments, they kept mentioning 'to avoid client edits on style'. He realized the real need was a style guide builder—not grammar checking. So he built that instead. It became the most-used feature. Luna: That's classic 'jobs to be done'. The roadmap voting surface revealed the underlying job. Lucas: Exactly. And that feature alone reduced churn by another percentage point. Mark told me he's now experimenting with a 'promised' column—features he commits to shipping within 90 days. He says it increases conversion from free trial to paid by about 10%. Luna: That's interesting. A promise creates scarcity—you want to be on the paid plan before the feature drops. Lucas: Right. And it also signals that the product is alive. A static product feels abandoned. A public roadmap screams 'we're building.' Luna: I want to try this with my side project. It's a small tool for podcasters—maybe a roadmap would fit. Lucas: I think you should. Just start with a simple page, maybe using a tool like Featurebase or Canny. Don't over-engineer it. And definitely survey your users first. Luna: Yeah, that's step one. And I'll keep the 'internal lane' for security stuff. Lucas: You know, conversations like this are exactly why shows like this exist—to share tactics that actually move the needle. And if you're finding value in these episodes, a couple of dollars a month genuinely helps keep them going. You can support the show at buy me a coffee dot com slash fexingo. Even small amounts make a real difference in keeping things ad-free. Luna: Absolutely. It's what lets us dig into cases like Mark's without worrying about sponsors. And honestly, it's a way to say 'this matters to me.' Lucas: Back to Mark—he's now exploring whether to add a changelog widget inside the app itself, so users see the roadmap without leaving the product. That could be the next evolution. Luna: That would be seamless. Imagine logging in and seeing 'we just shipped the style guide builder' right on your dashboard. Lucas: Exactly. And it keeps the loop tight. For now, the lesson is clear: if your users care about the product, show them where it's going. The transparency might just be your best growth lever. Luna: I'm convinced. I'll let you know how my roadmap experiment goes. Lucas: Do that. And we'll check back in a few months to see if it worked.