How we built one of the most popular dev tools in the world with Sergiy Korolov @Mailtrap

saas.unbound is a podcast for and about founders who are working on scaling inspiring products that people love, brought to you by https://saas.group/, a serial acquirer of B2B SaaS companies.

In episode #10 of season 6, Anna Nadeina talks with Sergiy Korolov, co-founder of Railsware and the brain behind Mailtrap.

From accidentally launching one of the most popular developer tools with zero marketing budget, to running the company with an all-engineer team — Sergiy’s journey is packed with lessons most founders learn the hard way.

How We Built One of the Most Popular Dev Tools in the World, and What It Taught Us About Products, Hiring, and AI

Mailtrap did not start as a grand startup thesis.

It started the way many useful products start: as an internal tool built to solve a real problem.

At Railsware, we needed a way to catch outbound SMTP traffic from staging environments so test emails would never accidentally reach real customers. We built that tool for ourselves, put it out into the world for free, and the developer community picked it up. People liked it, shared it, and over time Mailtrap grew to hundreds of thousands of users before we charged a cent.

That story sounds simple in retrospect. It was not. It was shaped by years of learning how to build products, how to hire the right people, how to operate as engineers without becoming trapped in an engineering-only mindset, and now, how to think clearly about AI without getting lost in hype.

Here is what that journey looked like and what I believe other founders can take from it.

Railsware Started in Services, But Never With a Pure Outsourcing Mindset

Railsware was founded in Ukraine, at a time when software outsourcing was booming across Ukraine, Poland, Russia, and the broader region. There was and still is a strong engineering culture there. Ukraine, in particular, has deep technical roots, including a serious aerospace and rocket engineering heritage. That kind of technical DNA matters.

But even in those early days, we were not trying to build a classic body-shop business.

We stayed small for a long time because we approached software from a product perspective. We were not interested in simply selling hours and scaling headcount as fast as possible. We were a boutique shop for startups. We hired carefully. Early on, we hired engineers only. We cared deeply about how products should be built, not just how code should be shipped.

That distinction shaped everything that came later.

What We Learned From Top US Product Consultancies

A major turning point came around 2011, when we started working with well-known US consultancies such as Thoughtbot and Pivotal Labs. These companies had worked with major names like Twitter and Square, and spending time with them changed the way we thought.

We learned a lot from those relationships:

• How to hire properly
• How to manage product development
• How to structure development processes
• How to think more systematically about teams and outcomes

Railsware has always been managed by engineers. I am an engineer. My co-founder is an engineer. Our top management team is made up of engineers. So our instinct has always been to bring an engineering mindset not only to software, but to the company itself.

We try to make a science out of what we do.

That means formalizing processes, defining systems, identifying skills, and understanding where quality comes from instead of leaving everything to intuition.

From Consultancy to Product Studio to Joint Venture Product Studio

Railsware evolved in stages.

First, we were a consultancy. Then we launched three products of our own. Over time, we moved again, this time toward a product studio model, and now further toward a joint venture product studio approach.

That means our core product is no longer just software. Our core product is building products.

Today, the model looks roughly like this:

1. We started by helping others build software.
2. We launched our own products, fully owned by Railsware.
3. We began co-founding products with domain experts in areas like finance, trading, and HR.

Some of these newer ventures are still not public, but our established products have already reached millions of users and are used by large companies around the world.

The biggest mindset shift in that transition was this:

A product is much more than software.

Early in tech, strong engineering could get you surprisingly far. You could build something useful, launch it into a relatively empty market, and grow on demand alone. But markets are crowded now. When a promising new category appears, multiple startups rush in immediately.

That changes the game.

Engineering is still essential, but it is no longer enough. A successful product now depends on many functions being covered well, especially marketing.

How Mailtrap Grew to Hundreds of Thousands of Users With Zero Marketing

There is a quote often associated with Mailtrap: zero marketing until 200,000 users.

That is true, but it needs context.

Mailtrap was free at the time.

It was not launched as a commercial SaaS product. It was simply a useful tool we had built internally and decided to share with the market. The same is true, by the way, for our other products as well. They emerged from problems we experienced ourselves.

Mailtrap solved a real pain point for developers. Because it was genuinely helpful, the community spread the word. That organic adoption created a large and loyal user base.

There was no big growth playbook behind it. No elaborate launch strategy. No giant paid acquisition engine.

Sometimes product success contains a bit of what I would call fairy dust. Your skill set, your timing, and your understanding of the problem happen to match what the market wants. It feels intentional afterward, but part of it is coincidence.

We had another similar story with Smart Checklist for the Atlassian Marketplace. Again, it was built for ourselves first. Again, it was useful. Again, it started growing with very little marketing investment.

So yes, product quality matters. Taste matters. But timing and market fit matter too.

The Hard Part Was Not Growth. It Was Monetization.

Growing a free tool and building a paid business are not the same thing.

Once we decided to make Mailtrap paid, we entered a very different phase.

The initial monetization model was straightforward. We introduced usage limits:

• Number of messages
• Number of inboxes or projects
• Capacity-based limits that made sense for heavier users

That part was simple. The challenge was that most users were still perfectly happy with the free plan. In fact, around 99% of them had no strong reason to upgrade.

And once a previously free tool becomes paid, it starts competing not only with other paid tools, but with the entire category of free alternatives.

So Mailtrap had a loyal audience, and some people upgraded, but many users who hit limits simply considered switching to another free solution.

That tension remained for a long time, especially on the testing side of the product.

Why We Turned Mailtrap From a Tool Into an Email Platform

The real strategic shift came when we decided Mailtrap should not remain only a testing tool.

About four or five years ago, we started transitioning it into a broader email delivery platform. That meant moving into territory occupied by companies like SendGrid, Mailgun, and Postmark, and potentially, over time, closer to areas touched by Mailchimp as well.

The key insight was simple:

Developers did not just need a safe testing environment. They also needed a reliable production email setup.

So we built transactional email sending into Mailtrap.

That gave the product a much stronger position. Instead of covering only staging and QA, Mailtrap could now support the whole development flow:

• Staging and QA: prevent test emails from reaching customers
• Production: send transactional emails to real users

With just two configurations, a developer could cover both environments.

That was the move from “a useful dev tool” to “a platform.” And it created a much more meaningful commercial product.

Product Taste Is Real, but You Still Need a System

Founders often ask how to develop “taste” for products. How do you know what the market wants? How do you sense the pull before the metrics fully show it?

There is no perfect formula.

Some of it is hard to teach. It is similar to art. Some people create something that resonates deeply with the moment. Others build something excellent that the market is not ready for yet.

In software, this all moves much faster than in art, but the principle still holds. There is a layer of judgment that is difficult to reduce to a dashboard.

That said, even if taste itself is difficult to formalize, the surrounding skills can be formalized.

This is where our skill matrix approach became important.

How We Use Skill Matrices

At Railsware, we define the skills needed for roles, teams, and products. We map what capabilities are required, who has them, how strong those capabilities are, and where the gaps exist.

The matrix includes things like:

• The specific skills required for a role
• The level of knowledge or confidence for each skill
• Availability of people with those skills
• Coverage gaps across the product team

If taste is part of the equation, you can still put it in the matrix as a category, assess your confidence level, and ask a practical question: how do we close the gap?

Maybe that means hiring someone. Maybe it means bringing in a freelancer. Maybe it means borrowing expertise from another team.

The point is to stop operating only on vague feeling.

I often think of the Moneyball idea here. You do not need a team of stars. You need a star team, a combination of complementary strengths that covers the real needs of the product.

How to Hire When You Do Not Know Enough to Assess the Role

This is one of the hardest problems for early founders.

You know you need marketing, or finance, or HR, or support leadership. But how do you hire someone great if you are not an expert in that field yourself?

We faced that many times.

For example, when we needed to build marketing capability, we were engineers with essentially zero direct marketing experience. So I began by doing what founders often have to do: I started experimenting myself.

I learned enough to understand the basics. That first layer of knowledge helped us hire an execution-focused person who was proactive and strong in delivery, even if not yet a senior expert.

Later, once we reached the limits of our knowledge, we had two choices:

1. Try to hire a senior expert directly
2. Bring in an external expert first and use them to help assess and hire properly

In that situation, the second approach is often smarter.

If you lack the expertise to evaluate the role, you can easily be impressed by someone’s resume or by metrics that were driven mostly by external factors, not by that person’s actual contribution.

So what we recommend is this:

• Learn enough to ask better questions
• Use an external expert or agency when necessary
• Let that expert help you hire your first true specialist
• Then build the function internally from there

We used that model in marketing. In other areas, such as recruitment, we were able to build the expertise more internally, partly by learning from experienced companies we had worked with before.

Today our recruiting function handles around 10,000 applicants per year.

Early-Stage Hiring: Choose T-Shaped Executors

For early-stage founders, the hiring question is usually not “Should I hire a specialist or a generalist?” in the abstract.

It depends on your stage, your budget, and whether you are bootstrapped or heavily funded.

If you have millions in the bank, you can hire a senior head of marketing and let them build a team.

If you are bootstrapped, things look very different.

We were bootstrapped. We had no venture capital. That meant we had to grow iteratively and make careful decisions about every hire.

In that environment, your first hires usually need to be T-shaped people:

• They know one area well enough to own it
• They can also cover adjacent functions reasonably well
• They are willing to do a lot of hands-on work

In a tiny company, the work does not disappear just because you cannot afford a full team. Marketing still includes content, PR, ads, SEO, social, partnerships, and more. So the first person cannot be narrowly specialized in only one small slice unless the rest is already covered.

On early teams, execution matters a lot.

Culture Fit Matters, but So Does the Ability to Learn

If I had to prioritize, I would put two things at the top:

1. Culture fit
2. Ability to learn

Especially in a company with many moving parts, people who fit the culture and learn quickly can grow into the role with support from the team.

Of course, domain experience matters too. But not every role is the same. Some hires are primarily for execution. Others are for both execution and knowledge transfer. You need to know which type you are making.

That distinction prevents many mistakes.

Dogfooding Is Not a Buzzword. It Is How Good Products Are Found

I strongly believe many successful startups begin with founders who know a domain deeply enough to feel where something is missing.

You cannot sense that gap properly if you are not eating your own dog food.

When you use the tools, live in the workflow, and experience the frustration firsthand, you can identify unmet needs with much more precision. That is where many organic product opportunities come from.

When a category is empty or weakly served, and you build something genuinely useful, growth can happen naturally because people feel the missing piece has finally been created.

Once a market is mature, everything gets harder. You need stronger differentiation, stronger distribution, and a more complete go-to-market engine.

But dogfooding still matters, because it sharpens product judgment.

At Railsware, We Treat Everything as a Product

This idea has been surprisingly powerful for us: every process in the company is a product.

If you think abstractly, every process has:

• Consumers
• Needs
• Inputs and outputs
• Software, people, or systems processing those inputs
• Expected outcomes and quality standards

Once you start seeing internal processes this way, you can apply product thinking everywhere.

That means consumer-first thinking is not just for external users. It also applies to hiring, operations, support, finance, and internal collaboration.

A Recruitment Example

When we designed our recruitment process, we looked at it as a product with multiple user groups. Applicants are users. Recruiters are users too.

We mapped their needs, risks, and desired outcomes. We asked:

• What does a recruiter need to work efficiently?
• What does an applicant need to feel informed and respected?
• What should the flow of communication feel like?
• What are the moments where trust is gained or lost?

Instead of slapping an ugly generic form onto a careers page, we built a better experience. Back then, many recruitment tools offered interfaces that felt stuck in the 1990s. We cared enough to build something more modern and thoughtful.

The result was not only operationally effective. It also created a strong candidate experience. Even people who did not pass the process often reported being treated well and having a positive impression. Our applicant satisfaction has stayed above 90%.

That is what happens when you treat internal systems with the same respect you give external products.

How We Think About AI in Products and Operations

AI is now entering every function, and it should be taken seriously. There is certainly hype, but there is also real practical value.

The key is to distinguish between the two.

AI in HR and Operations

In HR, AI already helps with areas like:

• Pre-qualification
• Processing test tasks
• Assistance with validation workflows

But there are limits, and some of those limits are cultural.

For example, some companies now use AI-led first interviews where a candidate speaks to an AI agent rather than a human. That may be efficient, and in some contexts it is perfectly acceptable.

We still value human contact in key moments of the hiring process. If someone is having a culture call or interview call with us, there is a real person there. We may automate more later, but we are not ready to remove that human touch entirely.

AI in Engineering: The Hype Finally Became Useful

The engineering side is where I see especially meaningful progress.

A year ago, a lot of noise surrounded AI coding tools, but the actual output often was not that strong. That has changed quickly. In the last six months especially, the quality of AI-assisted coding has improved significantly.

But here is the important nuance:

AI is not a replacement for strong engineers. It is a force multiplier for strong engineers.

The most useful mode is not what people loosely call “vibe coding.” It is closer to prompt-driven engineering inside a disciplined development process.

A good engineer can:

• Describe clearly what should be built
• Handle edge cases
• Review and validate what the AI produces
• Iterate feature by feature
• Commit clean changes into a real codebase

In that setup, AI becomes a very powerful teammate.

It helps generate software faster, and increasingly, it can also help validate output through additional agents checking logic, gaps, and implementation details.

The Hard Truth About Vibe Coding

I am skeptical of vibe coding in its current form.

Many so-called AI-built applications are not really applications in a meaningful product sense. They are often little more than websites with a few forms and some automation attached.

That is not nothing, but it is also not new. We already had ways to build websites, forms, and no-code workflows using tools like Wix and Zapier.

The deeper problem appears when someone tries to evolve that initial output into a real product. Real software needs:

• Iterative upgrades
• Architecture decisions
• Security coverage
• Integrations
• Maintainability
• Understanding of how components interact

If you do not understand engineering, you may be able to produce a first version of something. But you will struggle when the complexity starts to compound.

That is why I do not believe there will suddenly be huge long-term demand for weak engineers whose job is to clean up AI-generated systems they barely understand. The people least equipped to validate AI output are often the same people who relied on it most heavily in the first place.

Meanwhile, AI itself is getting better at checking its own work through multi-agent workflows. So the more realistic future is not weak engineers supervising AI. It is strong engineers using AI to move much faster.

What COVID and AI Changed About Software Teams

The software labor market went through a strange cycle.

During COVID, demand for developers exploded. Many companies hired almost anyone who wanted to become a developer, and the market filled with people who lacked professional depth. Average engineering quality dropped.

Then came layoffs. Many of the least capable people were filtered out.

Now AI is accelerating another separation.

The value of low-skill engineering work is decreasing. The value of high-skill engineering work is increasing because good engineers can now accomplish much more with AI assistance.

That does not mean new engineers cannot enter the field. Of course they can. But the bar for being genuinely useful is moving upward, not downward.

The Biggest Win: Building an Exceptional Team

If I look back over more than 15 years, the biggest win is not a single product milestone.

It is the team.

Watching talented people work together at a high level is one of the great joys of building a company. There is elegance in it. Like dancers moving in sync, or a skilled craftsperson moving with precision. Great teams create software with that same kind of beauty.

And for a Ukrainian company, building and sustaining such a team through wave after wave of turbulence has meant even more. Crisis after crisis, war, instability, shifting markets, all of it tests what a company is really made of.

The fact that we still have this strong team is the thing I value most.

The Biggest Financial Mistake: The Calendly Story

As for mistakes, one stands out immediately.

Railsware worked with Calendly in its early days and helped deliver the product to market. At one point, we had the option to take stock. Instead, we chose cash.

At the time, that may have seemed perfectly reasonable. But in hindsight, that decision meant walking away from what would have become an enormous outcome, roughly the difference between a six-figure return and something closer to $200 million.

That is a painful story, but also a familiar one in entrepreneurship. It is easy to look backward and see missed opportunities with perfect clarity.

The more useful mindset is to remember that opportunities still exist now. History is full of “we should have bought Bitcoin” stories. The harder and more relevant question is what opportunity is in front of you today.

The Founder Hack That Matters Most Changes Over Time

People love founder hacks, but the truth is that the right hack depends on the stage you are in.

At the beginning, when a few people need to cover many roles, hard work matters enormously. There is no way around that. You may work very long hours. You may lose sleep. You do whatever is needed to survive and move forward.

But if you are still living that way once the company is large, something is probably wrong.

As the company grows, the job of the founder changes. The goal is not to personally carry more and more. The goal is to build a team and system that works well enough that you do not need constant sleepless nights.

I would even say this:

The fewer sleepless nights a CEO has in a mature company, the more likely it is that they have built the right structure around them.

If a company with hundreds of people still depends on the founder doing too much personally, that usually means functions are not properly covered by professionals.

My Personal Productivity Hack

For me, the biggest practical productivity lever today is exercise.

If I do not run or do physical exercise, I feel less productive. It changes the rhythm of the whole day. So while there is no universal trick, maintaining physical energy and recovery has become far more valuable than heroic overwork.

This is a marathon, not a sprint. A company is not built by exploding at the beginning and collapsing in the middle.

You need to know your pace, your energy level, and how to sustain performance for a very long time.

A Final Recommendation: Learn to Value the Present Moment

One recommendation I give often is the book The Power of Now, along with other books by the same author.

Not because founders should become passive. Quite the opposite.

The value of that perspective is that many founders live entirely in the future. More growth. More revenue. More milestones. More pressure. They stop appreciating the present moment and the actual process of creation.

That mindset creates frustration and eventually burnout.

If you do not enjoy the act of building, the chances of long-term success get worse, not better.

Appreciating the current moment is not laziness. It is a way to stay grounded enough to keep going.