My First Sale and What I Learned About Turning Free Users Into Paying Customers

For months I had an open source project that people were using, but nobody was paying me for it. EventCatalog was free, it was growing, and I had no idea how to turn any of that into revenue. I’m a developer. I build things. I’d never sold anything in my life.

Then about two months after going full-time, someone bought a license key. A real person, at a real company, paying real money for something I built. The feeling was a mix of excitement, relief, and genuine imposter syndrome. I remember thinking, “Someone is actually buying the stuff I’m creating?” It hit different because as engineers, we’re so disconnected from the purchasing side of software. We build it. Someone else prices it and sells it.

That first sale changed how I saw everything. It wasn’t about the money (it was a small amount). It was proof that the problem I was solving was worth paying for. Here’s what I learned getting there, and what I’d tell anyone who’s sitting where I was.

Build Trust Before You Build a Checkout Page

• Give value away before you ever ask for money. Write blog posts, do talks, help people in the community. Every piece of free content is a deposit into a trust account you’ll withdraw from later.
• Think about how you feel when someone tries to sell you a developer tool. You hate it. Your customers feel the same way. Earn attention through usefulness, not promotion.
• Focus on the problem, not your project. I talk about complexity in event-driven architectures because I genuinely believe it’s a problem worth solving. EventCatalog happens to help with that. Lead with the problem and people will find your solution.
• The person who bought my first license key already knew me from my content and talks. That’s not a coincidence. Your content flywheel is your sales engine. It just works on a longer timeline than you’d like.
• Something to consider: if nobody in your community knows what you’re building or why, a checkout page won’t fix that. Build the audience first, even if it feels slow.

What to Actually Sell (and When)

• Start with the simplest possible paid thing. For me it was license keys that unlock specific features. No complex billing system, no enterprise sales team. Just a key that gates a feature.
• Stop waiting for the perfect pricing page. Your first version of “paid” can be ugly. It just needs to exist. You can refine it after someone actually buys.
• Think about which features your power users depend on most. Those are your candidates for the paid tier. Gate the features that solve pain for teams, not individuals. Teams have budgets. Individuals don’t.
• Don’t try to figure out pricing in a vacuum. Talk to the people using your project. Ask what problems it solves for them. Ask what they’d pay to keep solving that problem. Their answers will surprise you.
• Something to consider: you don’t need to monetize everything. Keep the core open source. Keep the community goodwill. Just find the one or two things that are worth paying for and start there.

The Moment Someone Pays You

• Let the first sale validate the problem, not your ego. It’s tempting to celebrate the revenue. The real signal is that someone has a problem painful enough to pay for a solution. That’s what you’re building on.
• Expect a cocktail of feelings. Excitement, relief, and imposter syndrome all at once. That’s normal. Every founder I’ve talked to felt the same way about their first sale.
• Think about what that first customer actually bought. They didn’t buy your code. They bought a solution to a problem they couldn’t solve themselves. Remember that when you’re pricing, positioning, and building.
• Reach out to your first customer and ask them why they bought. Not in a survey. In a real conversation. What they tell you will shape everything that comes after.
• The first sale is tiny in dollar terms but enormous in what it unlocks. It proves the model works. It proves people will pay. Everything after that is just doing it again.

The Developer Pricing Disconnect

• As developers, we’re terrible at pricing our own work. We think in terms of “hours spent building” instead of “value delivered to the customer.” Unlearn that as fast as you can.
• Think about what companies pay for other tools in your space. Enterprise software pricing would shock most engineers. Your tool is probably worth more than you think, especially if it saves a team time or reduces risk.
• Sell to the problem, not the project. Nobody pays for “an open source documentation tool.” They pay for “a way to reduce onboarding time and prevent production incidents.” Same product, completely different value.
• Don’t be afraid to charge. Seriously. Free users who would never pay are not the audience for your paid tier. The people who need what you’ve built will pay for it if you ask.
• Something to consider: pricing is its own skill and it’s one most of us never learned. Read about how other open source founders price their products. I went with open-core (free core, paid features behind license keys) and it’s been a good fit… but it took me a while to get comfortable with it.