How a Solo Dev Hit 10K MRR With a CLI Tool and No UI

Lucas: So there's this story about a solo developer who built a command-line tool that does one thing - PostgreSQL database migrations - and he hit ten thousand dollars in monthly recurring revenue without ever building a user interface. Luna: No UI at all? Like, not even a web dashboard? Lucas: Not even a settings page.

The entire product is a single binary you run in your terminal. You type a command, it migrates your database schema forward or backward. That's it. Luna: I mean, database migrations are a solved problem in a lot of ways.

There's Alembic for Python, Flyway for Java, plenty of options. What made his different? Lucas: Right, but those tools are language-specific or require configuration files. His tool is language-agnostic - a single binary that works with any tech stack.

You define your migration in SQL, and it runs them. He focused on something developers hate: the friction of setting up migration tooling in a new project. Luna: So he removed the setup friction. How did he get the word out?

Lucas: He posted the tool on Hacker News and GitHub. That's it. No ads, no outbound sales. The GitHub repo got some traction, and within a few weeks, he had a few dozen developers using it for free.

Then he added a paid tier - essentially a license for commercial use - and started charging fifty dollars per developer per month. Luna: Fifty dollars per developer per month for a CLI tool? That's steep for something that doesn't have a UI. Lucas: It sounds steep, but here's the thing: his customers are engineering teams who spend hours debugging migration scripts.

The tool automates that and prevents data loss. For a team of ten, that's five hundred dollars a month. Compared to the cost of a database outage, it's cheap. Luna: Okay, so he's selling to teams.

How did he get his first paying customer? Lucas: His first paying customer was a startup that had a production database go down because of a botched migration. The CTO found his tool on GitHub, tried it on a staging environment, and bought licenses for the whole engineering team within a week. Luna: That's a perfect use case.

So the revenue came from teams that had already felt the pain. Lucas: Exactly. And that's a key pattern in a lot of these indie hacker stories - the product solves a problem the customer has already experienced, not one they need to be educated about. Luna: Let's talk about the pricing structure.

Was it just per-developer licensing, or were there other tiers? Lucas: He started with a single paid tier: fifty dollars per developer per month, includes priority support and access to private beta features. But he also kept a free tier for open-source projects and individual developers. That free tier actually drove a lot of adoption because developers would use it on personal projects, then advocate for it at work.

Luna: So the free tier acted as a sales funnel. That's smart. But I wonder - did he ever face pressure from customers to build a UI? Lucas: He did.

Some customers, especially less technical ones, asked for a dashboard to visualize migration history. But he held firm. His reasoning was that building and maintaining a UI would multiply his workload by at least three times, and he was a solo developer. He couldn't afford the distraction.

Luna: And yet he kept growing. How long did it take him to hit ten thousand MRR? Lucas: It took about eight months from first commit. He hit two thousand MRR in month three, then five thousand by month six, then ten thousand by month eight.

The growth was fairly linear, not exponential, but it was consistent. Luna: That's impressive. What was the churn like? Lucas: Very low.

Around two percent monthly. Once teams integrated his tool into their deployment pipeline, switching costs were high. Plus, the tool was genuinely good - it rarely broke, and when it did, he responded within hours. Luna: That's the benefit of a focused product.

Fewer features means fewer bugs. But also more pressure to make those features rock solid. Lucas: Exactly. He spent most of his time on reliability and documentation.

He wrote extensive docs with examples for different database setups, and that became his main customer support channel. People would read the docs and solve their own problems. Luna: I think that's a lesson a lot of founders miss: good documentation is a growth lever. Especially for developer tools.

Lucas: Yeah, and he treated it as such. Every time a customer asked a question, he would improve the docs rather than just answering the email. Over time, the docs became a comprehensive resource that attracted organic traffic from search. Luna: Let's talk about the broader implications.

A lot of indie hackers feel pressured to build a full SaaS product with a web app, authentication, billing, a dashboard. This story suggests that for certain niches, a CLI tool can be enough. Lucas: Absolutely. If your target customer is a developer who lives in the terminal, they might prefer a CLI over yet another web app to log into.

The key is understanding your audience deeply. Luna: But it's a risky bet. If you're wrong, you've built a product that's hard to expand beyond that niche. Lucas: True, but the counterpoint is that by keeping it simple, you validate the core value proposition faster.

If people pay for a CLI tool, you know the problem is real. Then you can decide whether to build a UI later. Luna: And in his case, he never needed to. He's still at ten thousand MRR, and he's thinking about adding a UI, but only as an optional layer.

Lucas: If today's tech conversation gave you something usable, we want to mention that this show stays ad-free because of listener support. If you'd like to keep it that way, you can find us at buy me a coffee dot com slash fexingo. Luna: Yeah, we really believe in keeping the content clean and focused on what matters. No sponsors, no interruptions.

Lucas: Right. So back to the story - the developer recently shared his revenue breakdown on a podcast. At ten thousand MRR, he had about two hundred paying seats, with an average of five seats per customer account. Luna: That's forty customers.

Not a huge number. But each customer is relatively sticky. Lucas: Exactly. And his customer acquisition cost was essentially zero.

He didn't run ads, didn't hire a salesperson. The only cost was his time. Luna: What about the competitive landscape? I imagine since he launched, there've been copycats.

Lucas: There have been a few, but none have gained significant traction. Partly because he built a strong brand around reliability and documentation, and partly because the switching costs are high once you've configured the tool for your pipeline. Luna: So he's got a defensible niche. That's the dream for a solo developer.

Lucas: It really is. And it shows that you don't need a massive team or a complex product to build a sustainable business. You just need a clear problem, a focused solution, and a deep understanding of who you're building for. Luna: What's next for him?

Is he planning to stay solo or eventually hire? Lucas: He's mentioned that he's thinking about hiring a part-time support person to free up his time for building new features. But he's in no rush. The business is profitable, he enjoys the work, and the customers are happy.

Luna: It's a nice counter-narrative to the vc funded growth-at-all-costs story. Lucas: Absolutely. And I think that's why stories like this resonate with our listeners. It's proof that you can build a real business on your own terms.

Luna: So if you're a developer listening and you've been thinking about building a tool for a pain point you've experienced, maybe this is the nudge you needed. Lucas: Exactly. Start small, ship fast, and listen to your users. You might just build something that people will pay for without ever building a UI.

Luna: Thanks for the story, Lucas. That was really inspiring. Lucas: Glad you liked it. That's all for today.

Catch you next time.