How to build a bootstrapped product: From one engineer to over 150,000 active monthly users

Building a product is only half the battle. If you don’t have a strategy to reach and convert customers, you lose. That’s the mindset any indie hacker or bootstrapped founder needs to adopt from day one.

Many of us obsess over product features and technology. That’s not a bad thing. Yet, the real wins often come from strategic marketing, distribution, and addressing a niche where you have a fighting chance.

That’s why in this article, I’ll share:

• How we turned a simple internal tool into a product with organic growth
• When splitting a product helps (and when it hurts)
• Why distribution strategy matters more than just good features
• How to know when you need outside help

The journey below is from my experience working on Mailtrap, an email delivery platform. However, the lessons are universal to most indie projects — especially if you want to carve out a foothold in a competitive space, stand out to the right market segment, and turn an early-stage product into a trusted solution.

From side project to split product

Mailtrap started as a small side project, an email testing sandbox. The only team it had was one engineer (or rather a half-engineer, since he was working on it part-time). Yet, this sandbox gained early traction purely through word of mouth. Although that organic growth was exciting, we only later realised how critical structured marketing and distribution could have been. More on that later.

Then, several years later, with nearly a million users, we decided to expand into email sending (Email API/SMTP), because:

• Our fake SMTP credentials were being used in development environments, where emails were intercepted and reviewed manually or through our API.
• Companies using our testing tool also needed reliable email delivery for their production environments.

To keep costs low and focus on speed, we opted for a lesser-known but flexible Mail Transport Agent (MTA) solution instead of developing our own from scratch. Yet, we still faced challenges.

We decided to split our email testing and sending into separate repositories and isolated projects. Initially, it seemed like a solid engineering decision (spoiler: it wasn’t). It added complexity to scaling and made it harder to deliver a consistent user experience.

Takeaway: spend more time on the big picture before making decisions, especially for a product that spans multiple areas like tech, marketing, and user experience. Yet, it may be a challenge for those who want to pursue a fail-fast mindset.

Also, learn the value of using frameworks and tools to better analyze possible outcomes. If you're scaling a product, don't skip the hard conversations. Take the time to think holistically, ask more questions, and use the right tools to get a clearer view of all possible outcomes.

How we lost time because of the database

When we started using Redshift, we thought we had all the information we needed: we conducted tests on scaling, cost, and performance. It seemed like the best option for our product. However, we missed a crucial factor – real-world experience.

That’s why, over time, we faced delays in log processing, which is critical for Mailtrap as email logs need to appear instantly (and with a 10-minute lag). We spent countless hours optimizing, but the delays never truly disappeared. As data volume grew, it became clear that Redshift wasn’t the right fit for us.

Takeaway: Don’t waste time endlessly optimizing a solution that isn’t working. The moment you realize it’s not viable, it’s time to pivot. From that point of view, the time spent isn’t wasted. It’s the cost of learning.

Why you shouldn’t rely only on your expertise

When you're bootstrapping, you try to figure things out on your own. Yet, some challenges, such as Redshift optimization, high-load systems, or email deliverability (which we’re tackling at Mailtrap), have too many nuances to solve through trial and error.

As your product grows, gaps in expertise become more obvious. For instance, we didn’t have a dedicated DevOps for a long time. Our engineers have just handled it. But at some point, it became obvious that we needed a full-time specialist. Instead of wasting time reinventing the wheel, we started bringing in external experts who had already solved similar problems.

Takeaway: Hiring specialists doesn’t mean hiring full-time. A few well-placed consultations can save months of struggle. The key is knowing exactly what you need before reaching out. We align internally first, then look for the right people (usually through LinkedIn) and have quick intro calls to see if they’re a fit. Simple, but effective.

When to move fast VS when to slow down

Product reliability builds trust. For Mailtrap.io, engineers were recommending us on Twitter (now X) long before we even started marketing our Email API/SMTP. We didn’t want to lose that. A single bad review could undermine years of work.

So, when doing beta testing, we hit a snag — emails weren’t sent for ten minutes after deployment. We decided to wait even though everything was ready for the marketing launch.

Some of us wanted to take the risk — previous tests had gone well. But looking back, holding off was the right call. In email services, reliability is everything. A single issue can shake user trust, and in a billion-dollar industry, that’s not a risk worth taking.

So, over the next 7-8 months, we focused on stability:

• Implemented blue-green deployment.

• Expanded monitoring systems.

• Strengthened our DevOps support.

• Improved on-duty engineer alerts.

Takeaway: “Move fast and break things” doesn’t apply to critical infrastructure or features. If reliability is your core promise, do not let marketing outrun your product readiness. That said, build marketing momentum in parallel. Have an email list ready or a waitlist signup. As soon as you’re stable, you can flip the switch and bring in real users.

Why changing user perceptions is harder than it seems

When we launched Email API/SMTP, we thought users would jump on it. Yet, they didn’t. Our product was still seen as an email testing tool, and that perception stuck.

We considered rebranding, but quickly dropped the idea. Our name shouldn’t box us in. Instead, we focused on why users weren’t making the switch:

1. No urgent reason to change – Users only look for alternatives when they hit real problems: pricing, missing features, delivery issues, bad support, or sudden account blocks.

2. High switching costs – Even with better pricing, moving a team to a new tool takes time, effort, and money. That alone keeps users where they are.

Competing on price was also not our choice. Instead, we leaned into education and visibility:

• Created content explaining the new features and benefits.

• Used conferences and direct user conversations to shift perceptions.

• Made the website more informative and user-friendly.

• Added features that ease the transition.

Takeaway: engage with real users at every stage through newsletters, social media, or platforms like Indie Hackers. This way, you can find out what your audience needs and how they see your product.

Moreover, create specific onboarding flows for new features, showing users how easy (and beneficial) it is to use them.

Summing up

Thirteen years of building Mailtrap have taught us that mistakes are part of the process. The key isn’t to avoid them, but to move through them faster and smarter. As a bootstrapped founder, your edge is in clarity, speed, and adaptability.