In this conversation, Oleksii Ianchuk, Product Lead at Railsware, shares his journey with Mailtrap, which transformed from a mishap into a thriving email tool. He discusses the challenges of expanding to Email API and SMTP services, highlighting the complexities of compliance and deliverability. Oleksii reflects on early mistakes like splitting products into different repositories and the lessons learned from costly operational choices. His insights emphasize the balance of innovation and reliability in product development and the importance of user education.
26:14
forum Ask episode
web_stories AI Snips
view_agenda Chapters
auto_awesome Transcript
info_circle Episode notes
question_answer ANECDOTE
From Accidental Emails To A Product
MailTrap began as an internal fix after developers accidentally sent test emails to real users in 2011.
Railsware turned that internal utility into a paid SaaS when they found the problem affected many other teams.
volunteer_activism ADVICE
Avoid Premature Product Splitting
Avoid splitting tightly related product codebases into separate repos and infra early on.
Start simple and don't over-engineer to prevent costly sync and delivery overheads.
question_answer ANECDOTE
Choosing To Host An MTA For Control
The team chose to run their own mail transfer agent instead of reselling AWS SES to gain control over sending.
Hosting and tuning MTA proved harder and slower but offered deeper control of delivery behavior.
Get the Snipd Podcast app to discover more snips from this episode
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"?
Code Story: Insights from Startup Tech Leaders