Splitting products: repo and infra costs

Today, we are dropping our final episode in the series "The Railsware Way", sponsored by our good friends at Railsware. Railsware is a leading product studio with two main focuses - services and products. They have created amazing products like Mailtrap, Coupler and TitanApps, while also partnering with teams like Calendly and Bright Bytes. They deliver amazing products, and have happy customers to prove it.

In this series, we are digging into the company's methods around product engineering and development. In particular, we will cover relevant topics to not only highlight their expertise, but to educate you on industry trends alongside their experience.

In today's episode, we are speaking with Oleksii Ianchuk, Product Lead at Railsware, specifically for Mailtrap. Thought he doesn't like to limit his activities to product development, Oleksii has spent six years in product and project management, and is keen on searching for insights and putting them to work, as well as gauging the effects of his input.

Questions:

• The story of Mailtrap starts with accidentally sending test emails to real users in 2011. How did Mailtrap evolve from an internal "fail" to a platform serving hundreds of thousands of users? How did that mistake spark the creation of Mailtrap, and what lessons did you learn about turning problems into opportunities?
• What made you decide to expand from email testing into Email API/SMTP delivery - and why was it harder than expected? What specific challenges around deliverability, spam fighting, and infrastructure caught you off guard?
• Can you walk us through the "splitting the product" mistake and its long-term consequences? Your team decided to separate testing and sending into different repositories and isolated VPC projects. What seemed like a good engineering decision at the time - how did this create problems as you scaled, and what would you do differently?
• You spent a year struggling with Redshift before switching to Elasticsearch - what did that teach you about technology decisions? You ran tests, evaluated alternatives, and still picked the wrong database for your use case. How do you balance thorough research with the reality that you can't always predict what will work until you're in production?
• When do you buy external expertise versus rely on your internal team? How do you decide when to hire outside knowledge, and how do you find the right consultants for niche problems?
• Why didn't existing Mailtrap users immediately adopt the Email API/SMTP feature, and what did that teach you?
• You expected current users to quickly transition to the new sending functionality. What did you learn about switching costs, user perception, and the challenge of changing how people think about your product?
• What business insights around deliverability, spam prevention, and compliance surprised you most?
• Email delivery isn't just about infrastructure - there's a whole ecosystem of postmasters, anti-spam systems, and compliance requirements. What aspects of this business were most unexpected, and how did they shape your product strategy?
• Looking at Mailtrap's 13-year journey, what's your philosophy on "failing fast" versus "building solid foundations"?

Links

• https://railsware.com/
• https://www.linkedin.com/in/yanch/