I Got to $23K MRR Without Stripe and What That Taught Me About Starting Simple

When I started building EventCatalog, I had this picture in my head of what a “real” product looks like. Stripe integration. Hosted SaaS platform. Automated onboarding. Dashboards. The works. And I almost went down that road. But something stopped me. I looked at what I actually needed to prove and realized… none of that stuff mattered yet.

So I started simple. Really simple. A self-hosted tool with a license key server. No Stripe. No hosting. No SLAs. No data backups. I handled contracts manually. I sent invoices by hand. I enabled license keys directly in the database. It felt scrappy, and honestly, it felt a bit embarrassing at times. But it worked. I got to $23K MRR doing things that way.

The lesson I keep coming back to is this: most of us are building for a version of our product that doesn’t exist yet, for users we don’t have yet, solving problems we haven’t confirmed are real. Here’s what I’ve learned about keeping things simple and why it might be the most important thing you do early on.

You Don’t Need the Stack You Think You Need

• Start by asking what you actually need to prove. Is it that people will pay? That the product solves a real problem? You can validate both without Stripe, without a SaaS platform, without any of the “standard” infrastructure.
• Think about what your product looks like if you strip away everything except the core value. That’s your starting point. Everything else is a distraction until you’ve proven the core works.
• I ran without Stripe for the first $23K of MRR. Manual invoices. Manual license keys. It was slow, but it forced me to talk to every single customer. That was worth more than any payment integration.
• Something to consider: every piece of infrastructure you add is something you have to maintain. As a solo founder, your time is the scarcest resource you have. Spend it on the product, not the plumbing.
• Self-hosting can be a superpower. No servers to manage. No uptime guarantees. No data liability. Your users own their data, and you get to focus purely on making the tool better. There’s a huge market for self-hosted software, especially if you’re bootstrapping alone.

Do Things That Don’t Scale

• Handle things manually until it hurts. Contracts, invoicing, onboarding, license key provisioning. Do all of it by hand at first. You’ll learn things about your customers that no dashboard will ever tell you.
• Think about what you’d automate on day one if you were following the “standard” playbook. Now ask yourself: do I actually need that right now, or am I just building it because it feels professional?
• Every manual interaction is a chance to learn. When I was enabling license keys in the database myself, I knew exactly who my customers were, what they needed, and why they were paying. That’s invaluable early on.
• Something to consider: the things that don’t scale are often the things that build the deepest understanding of your market. Automation is great, but not before you understand what you’re automating.
• You can always add infrastructure later. I just added Stripe recently. The business didn’t suffer without it. If anything, the delay helped me understand my pricing and customers better before locking into a system.

Simple Is Enough (Until It Isn’t)

• Stop waiting for your product to feel “ready.” It won’t. Ship the simplest version that solves a real problem for real people. You can iterate from there.
• Think about the difference between “simple” and “incomplete.” A product with one well-solved use case is simple. A product with ten half-built features is incomplete. Aim for simple.
• Your first version doesn’t need to look like anyone else’s product. It doesn’t need a flashy homepage. It doesn’t need a polished onboarding flow. It needs to work, and it needs to solve a problem someone is willing to pay for.
• Something to consider: most people building products are learning on the fly. That’s normal. You don’t need to have it all figured out. You just need to start, and starting simple is the fastest way to learn what actually matters.
• The bar for “good enough” is lower than you think. Especially in developer tools, people care about whether your product solves their problem. They’ll forgive rough edges if the core value is there.

How to Know When to Add Complexity

• Add infrastructure when the manual version becomes a bottleneck, not before. If you’re spending more time on invoicing than building features, that’s when you automate invoicing. Not a day sooner.
• Think about what your customers are actually asking for. Are they asking for Stripe? Or are they asking for the product to do more? Build what they’re asking for, not what you think a product “should” have.
• Watch for the signals. When manual processes start eating into your product development time, when customers start expecting faster turnaround, when you’re dropping balls because there’s too much to juggle. Those are the signs.
• Something to consider: complexity is a one-way door. Once you add a hosted option, a SaaS tier, or an automated billing system, you’re maintaining it forever. Be really sure you need it before you build it.
• The best time to add complexity is when you have data, not opinions. After months of manual work, you’ll know exactly what to automate, what to skip, and what your customers actually value. That’s a much better position to build from than guessing on day one.