← The SaaS Podcast - Growing Profitable AI SaaS & AI Agents
The SaaS Podcast - Growing Profitable AI SaaS & AI Agents
456: Mailtrap: From 20,000 Email Disaster to 7-Figure SaaS - with Sergiy Korolov
00:58:35
Loading summary
Transcript74 lines
- [00:00]
A
Foreign.
- [00:10]
B
Welcome to another episode of the SaaS podcast. I'm your host Omar Khan and this is a show where I interview proven founders and industry experts who share their stories, strategies and insights to help you build, launch and grow your SaaS business. In this episode I talk to Sergey Kurolov, the co CEO of Railsware, a product studio that helps companies design, build and scale successful software products. He's also the co founder of Mailtrap, an email testing and delivery platform trusted by developers worldwide. Back in 2011, Sergey's team made a massive mistake. They accidentally sent 20,000 test billing emails from their staging environment straight to real customers. The chaos was immediate. Customers were confused and upset, wondering if they'd actually been charged or not. So to make sure it never happened again, they built a small internal tool to stop test emails reaching real inboxes. When they shared it with the Ruby on Rails community, something unexpected happened. Developers loved it, and Mailtrap spread purely through word of mouth, eventually attracting more than 200,000 users. For the next five years, Mailtrap stayed free. It was a side project until 2016, when Sergey finally decided to turn it into a real business. But instead of guessing, his team ran over a hundred customer interviews and dug into usage data to guide pricing and their product decisions. It took another four years to reach the first million in ARR. Growth was slow and steady, not the overnight success story people imagine. And just as things started to pick up, a new challenge appeared. Customers wanted Mailtrap to handle production email sending too. That meant turning a product built to avoid sending emails into one that had to deliver them flawlessly. It was a risky move, and the shift created a whole new set of problems, from dealing with spam attacks and deliverability issues to fighting brand confusion about what Mailtrap actually did. Suddenly, a product known for blocking emails had to prove it could deliver them reliably. Sergey and his team spent months rebuilding their infrastructure, tightening security and designing tools that gave developers more visibility and control. It wasn't glamorous work, but it paid off. Mailtrap evolved into a trusted full stack email platform used by teams around the world. Today, Mailtrap generates seven figures in ARR with a 40 person team and more than 100,000 monthly active users. In this episode, you'll learn how making a signup survey mandatory gave the team deep insights about their customer base without hurting conversion, how a fake email campaigns button helped them test demand and validate new product idea before building it, why simplifying onboarding didn't increase conversions, and what that revealed about how developers actually think. We talk about how they navigated the risky shift from blocking emails to sending them and rebuilt trust along the way. And how community trust and slow deliberate growth created an advantage that competitors couldn't match. So I hope you enjoy it. Compliance isn't optional anymore, but it also doesn't have to slow you down. If you've ever wrestled with SOC2, ISO 27001 or GDPR, you you know how painful and time consuming it can be. Sprinto automates the entire compliance process, from evidence collection to vendor risk across more than 300 tools. You stay audit ready, secure and focused on building your product. Trusted by over 3,000 companies worldwide, Sprinto helps SaaS teams breeze through audits and keep customer trust strong. Book your demo@sprinto.com that's Sprinto. Sergey, welcome to the show.
- [03:46]
A
Hi Omer, nice to meet you and I'm glad to be here.
- [03:50]
B
Do you have a favorite quote? Something that inspires or motivates you?
- [03:54]
A
So I have one which is which sounds like master your craft every day. So we consider ourselves as a craftsman, me, myself and my partner Yaroslav and all the team that we have. So master your craft every day.
- [04:09]
B
Great. So you are the co CEO of Railsware and then also the co founder of Mailtrap as well as some other products. We're going to spend most of the conversation today talking about Mailtrap and how you built that business, but tell us a little bit about how things fit in with Railsware and all the other products that you work on.
- [04:30]
A
Yeah, so Railsware is the product studio. It's a very interesting hybrid concept which you do not find many of such examples on the market. That's why investors we're talking to sometimes are confused. So they do not understand like how to assess the valuation of our company properly. So we started as a service company, but then we built a product expertise and start to deliver our own products. And right now those two wings of the businesses live together. So we have products Mailtrap IO we have Coupler IO and Titan apps IO. Those products are from completely different industries. Mailtrop is from the email sending coupler, AI is the data analytics platform and Titan apps is the set of productivity tools for Atlasian and Monday.com marketplaces and consultancy part which actually we started with very famous for building Calendly for instance from the very scratch Top is the founder of Calendly. He's our good friend and he speaks about Rails for a lot during his podcasts and interviews and we really appreciate that. So we right now build another successful company product for the company Tradezilla. So which is growing just significantly, like heavily, exponentially. And many other companies worked with us, mostly startups and we helped them to grow from zero to millions of dollars in ARR.
- [06:14]
B
Great. So let's focus on the Mailtrap. Tell us a little bit more about. You explained this briefly, but what does the product do, who's it for and what's the main problem that you're helping to solve?
- [06:28]
A
So Mailtrap originally was born from the mistake that we've made. We've sent about 20,000 test emails to the customers from the staging environment into production, into production value to the real customers. So it was the huge fuck up. I don't know if I can use such words during the podcast, but yeah, customers were angry and they were, they didn't understand like what happened, like kind of it was a set of emails related to some billing. So were they charged or they were not charged, you know, so that's a lot of confusion was brought and so we decided that we need to build some simple tools that will block SMTP traffic from the staging environments, from the local environments and guarantee by that the emails will not reach real customers. So that's how Mailtrap was born. It was 2011, I guess maybe even earlier. We've never considered that product as the product but then it was rather just tool that we give back to the community. So we are developers ourselves. Myself is like I'm developer, your Slavis developer. Our company management team is our developers and the whole culture of the company was driven by developers and still driven by developers. But back then we were much more integrated into the Ruby on Rails community. We participated in different conferences kind of speaking on those conferences like making some open source projects which are still a part of the Rails open source. Yeah. And community find out that Mailtrop is not only useful for us like for elsewhere, but they start to use it. So we made it public. It was very small tool, not a lot of features, but we made it public and community decided that it's pretty useful and started to promote it themselves. So we had zero marketing. It's a perfect example when you find your market fit and I must say that this is very, very complicated to find such market feed. So it's a combination of your, of the concept eat your own dog food. Right. When you do something for yourself, it works good for you and then it might work well for your community as well. So in this specific case it worked out pretty good.
- [09:15]
B
Yeah. So Initially this was an internal tool. You made it available to the community, putting on stack overflow and places like that one. Like, I mean it's grown from like just this internal tool that was never supposed to be a business to a seven figure ARR SaaS. And now you have spun that off and you have a dedicated team focused on Mailtrap. I'm curious, how do you spend your time? Like, it sounds like you have a lot of plates to juggle here with Railsware and that side of the business and everything you're doing with Mailtrap and the other products.
- [09:55]
A
Yeah, true. So I must say that we have a fantastic team right now. It's about 40 people, all the different roles, product managers, designers, engineers, support marketing people, deliverability experts. Because right now Mailtrap is not only a sandbox, but it's an email delivery platform. So we cover both staging and production already. And this is the. We will talk about challenges later. I guess so of this transition. But speaking about myself and how do I spend my time, I would say that about 70% of my time I spent on Mailtrap on the role CEO, helping team, basically with the vision delivery, with the strategizing part, helping them with unblocking any kind of problems that might appear. And this is the major role of CEO. Right. You need to make your team productive. So you should see where are the weak points. You need to strengthen them kind of. You need to find proper team players. So it's a. We love this concept of Moneyball we talk about. So if you have seen this movie, if not, I heavily recommend that sometimes you don't need like a team of stars, but you need the team which become a star based on their specific kind of software. Software soft skills and hard skills. So that's my main goal is to build this team of like star team, not team of stars.
- [11:44]
B
So the 40 people are just focused on Mailtrap only?
- [11:48]
A
Yes, yes, yes. Mailtrap only. And so we have about same size coupler team. We have much smaller team on Titan ups and we have the rest of the team help. Like we have other joint ventures, products. But this is something we can talk probably in the next episodes. Yeah. And we have this consultancy part which we started with originally as the company.
- [12:14]
B
Great. So mailtrap is this internal tool. You share it with the community, it starts to take off. People are using this. But for many years it was just a free tool. You didn't monetize it. What happened that shifted your thinking and got you thinking about monetization for mailtrap.
- [12:38]
A
So yeah, as I said, it was a side project for us. Side meaning that we haven't focused on it at all. We were focusing on the other parts of the business. And for about five years this product, or I would call it rather tool, was available online. It was living its own life. We had part time product manager, part time engineer who was working on this product, just adding smaller things here and there and community loved it deliver kind of the more and more customers joined our user community. We had User voice back then as the tool to collect proposition of the features that customers would like to have. And we've started to see that there are more and more and more requests like this and this and this. And so we decided, well, you know, maybe it makes sense to make it not just a tool, but convert it into the product, start to purchase at least a bit to cover our development effort and the infrastructure costs. And so decision has been made. Five years after being tool, Mailtrap has been converted to a product. We've introduced some plans which I don't fully remember. What was the original price? Like 10 bucks or something and 25. We limited the amount of emails that you can send to the sandbox and a few limitations on the features. But kind of the strategy, the pricing strategy was pretty simple.
- [14:21]
B
One, how big was the user base when you started looking at pricing?
- [14:25]
A
So it was already back then about 200,000 users. I mean signups. So none of them were active. But I guess back then it was like 20, 25,000 active users. And so right now we have about 100,000 active users.
- [14:45]
B
A lot of founders would probably just say we want to monetize it. Let's look at what competitors are doing and let's introduce a paid plan. You took a much more of a data driven approach and you actually interviewed users and ran surveys to figure out your pricing. 1. Why did you decide to do it the hard way and what did you learn?
- [15:08]
A
Yeah, so it's a good question. The first pricing we've introduced, it was pretty simple and without communicating with the customers and without analyzing their behaviors. It was just the first test, I would say. But later then we started to put more and more efforts and we decided, all right, maybe it's time to reconsider the pricing model. We analyzed the behavior of our users from which perspective? So we have product analytics and this is something that I heavily recommend for every product owner to have. Product analytics track how like the usage of your product, see what features are used, which are not used, find correlation between feature sets that are used and conversion to the, to the purchase. So that's very important because we have a lot of assumptions, kind of, we as owners, we think that oh, this feature is so cool, it like when we will deliver it, users will love it and they will, they will purchase our product 10 times more. But then you deliver and you don't see any change in this, in the purchase yet. So that's. We have assumptions, right, but then you need to measure the results of those assumptions. And so when you take data from the product analytics and then you take the survey results and as you've mentioned correctly, we've talked to our customers, so we've picked different groups, like more advanced users, less advanced users, from the smaller companies, from the bigger corporations, individual users. And we talk to them more than 100 interviews, collecting their feedback about their user flow, how they use product, what the use cases. And so based on these and product analytics, we've already organized the new pricing model. And not only this, but also it helped us to shape the roadmap and prioritize the features that we want to deliver to the users.
- [17:25]
B
Was there any one sort of surprising thing that you learned from going through this process compared to your sort of initial attempt at just guessing at the pricing?
- [17:37]
A
Surprising was not that part, but the other part. We had an assumption then if we will clean up the user experience in the beginning, like first time experience, will be very slick without many clicks and then kind of you just sign up and arrive to the email like the, to your newly created sandbox with all the instructions and the first and just one click to send the email, that it will increase the conversion dramatically. But in fact it didn't. So the major finding was that if there is a value like core value in the product, even if you have 2 more clicks or 20 more clicks to be done to achieve that value, users tend to make those clicks. If they understand that value, they will reach the value after those 20 clicks. So that was a big surprise. I mean there was some change, but it was like a few percent. So it wasn't like 20% change or like 30%, just hardly noticeable, I would say. So that was a surprise.
- [18:55]
B
So most of the growth you've implemented, the pricing you've had users participate in helping you figure this out. Most of the growth has been coming from organic word of mouth. We talked about that. Obviously people talking about in the community where you had been very active anyway, and then presumably just having a free tier was probably a good viral driver anyway. When you think about getting to that first Million in ARR. Was there anything else that helped you get there faster or were those the main sort of growth strategies?
- [19:38]
A
Yeah, word of mouth and community, they drove us to the brand exposure and they built this foundation for our community of the users. But then in certain moment we were on Plato, and so at that moment we decided that, okay, maybe it's time to invest into marketing. So we found we have hired a few people who helped us because we didn't have anything like there was just a homepage and then sign up and then sign in. And so there is an application. So we didn't have blog, we didn't have. So we had some very simple documentation. So. And we were absolutely inactive in social media. And this is something that we focused on and had very positive influence, actually. So we start to create blog share a lot of use cases. We start to talk more about mailtrap on the different podcast shows, like here we talk right now. And yeah, and it helped us to start to grow exponentially comparing to what we've seen before.
- [20:57]
B
So I think it was around 2020 that you hit the first million in ARR. Is that about right?
- [21:04]
A
Yeah, I guess around 2020, yeah.
- [21:07]
B
Okay, great. Let's go back to the surveys because I think that's super interesting that you were using surveys to get feedback from users on pricing, but then you also implemented surveys as part of the signup process, but you went one step further and you made this a required thing that people had to do. And you and I were talking about this earlier that there's always this worry that this is going to hurt conversion rates. So just, just tell me about that. Like why, why did you do that? And why was it so important for you to make this a required thing that everybody had to complete as part of signup?
- [21:43]
A
Yeah, this is one of the best insights I've gotten for the last couple of years. So I guess it's important to mention here to our listeners that Mailtrop had this huge transition from just being a sandbox in actually, in 2020, we decided that it's time to. To not only test emails, but also send and become a competitor to services like SendGrid, Mailgun, Postmark. And our goal was to build the whole flow for the emails during the development cycle. So you want to test your emails on the staging environment. You have sandbox, you go into production. So you have Mailtrop sending email API product, which you use to send those emails in production. And so when we've built that part a few years ago, we start to polish first time experience, which I've mentioned before. And when we see that making it very slick and without any clicks hasn't changed much, we thought maybe if we will add a few more useful steps for us useful it will not influence conversion as well. And it actually hasn't influenced conversion, but it gave us a huge kind of insight. So we've introduced required survey. We didn't want to overload with like our customers with a lot of questions. So it's important that survey is clickable. So without open questions because people like users do not like to those open questions. So we asked about the intention. If it's a business intention, it's just, just surfing, looking at the product, or it's an educational project, or it's a pet project, we ask for the position like is it a C level, is it developer, is it marketing person? We asked for the marketing channel because it's very hard to attribute specifically. Sometimes you can attribute, but in many cases you cannot attribute the marketing channel. Exactly. So user usually can see you on YouTube, then go to Facebook and see some ads and then search in the Internet and like how would you attribute? But when you ask a person, they usually can tell you the most, the one that they have noticed and understood. Okay, so this is Meltrap. I will go and try to work with it. Yeah, and we introduced that. And again it's something that I recommend to every, to every founder, to every head of product or product lead that I'm talking to from our friends and partners networks. So it's amazing. Kind of right now we have dashboards where you can say, all right, show me conversion from United States pet projects. And it shows you some very, very little. And then okay, show me like let's say United States and business intention. And then it shows completely different conversion. But if you do not have such opportunity of filtering, then you see, all right, I have like hundreds of thousands of kind of signups over some time and why my conversions are not that great. So what should I fix? And then when you have such filters, you can go to your marketing team and say, you know what, you bring a lot of traffic, that's great. But you bring a lot of folks who are doing pet projects and they do not convert into the paid product, so they do not pay. So here is the cohort that you should focus on and you show them specific cohorts. So it should be like C level business intention and like some tiers of the countries which tend to convert and that's it. So because those huge numbers in traffic Usually can make you blind. Kind of you think what should what like what do I do wrong? Like there are hundreds of thousands of users, so why my growth isn't that fantastic, as I would expect. So it makes you, it puts you in control of what you're doing and what is the outcome. So that's very important.
- [26:39]
B
You were telling me you were getting about 30,000 signups monthly at one point and you implemented this required survey and how did that affect the number of people signing up?
- [26:52]
A
Nothing has changed. So that was, yeah, that was the insight. So we made it required, I would even say by mistake. So we consider it like making it required, non required. But then okay, let's deliver it without requirement. But then we'll see if there's going to be some drop. We will introduce this just recommended survey rather than required. But we observed and nothing has changed. So conversion from sign up to activation stayed the same. So nothing has changed. But we had a lot of benefits after that. Again, we made it very nicely looking this survey, it's just three steps, just a few questions. You click, you choose. So it should be the proper balance. Of course if you will overload with the questions and kind of, you will introduce complexity, then it may influence. But we made it very clean, very, very slick kind of few questions. And yeah, it is also important when you do surveys you should randomize the answers kind of. If you have some choices from 1 to 10, like let's say role C level developer, marketer, they should change their position for different users. So it should be a random position, otherwise they're going to be a bias. So people will tend to click first one for instance and you will have unfair advantage of the first role and you will have impression, wrong impression that you have C level users. But actually it's going to be a regular user who just click first answer. But when you randomize them, there are still users who just blindly click. But if you randomize. So this percentage is distributed among the all answers and so it does not influence the result if you have kind of thousands of customers.
- [28:58]
B
So what's the ultimate objective of this survey? To identify cohorts and intentions within those cohorts to be able to make better decisions. So this helps you make better product decisions, this helps you give better feedback to marketing about where they should focus and ultimately gave you more clarity on who your ICP was.
- [29:22]
A
Exactly. And speaking about surveys, we practice surveys much more than just this. So at some point we decided maybe. So we introduced these transactional emails. So there was a sandbox then we introduced transactional emails for production and then some of our customers started to ask if we didn't provide the email campaign functionality. And they've clearly stated that hey, we don't want to purchase Mailtrap for transactional and sandbox, but then for campaigns purchasing other product, we would rather go and purchase one product with all this functionality. And it pushed us to consider earlier than we expected that maybe we will need to deliver this, the campaigns or promo emails faster. So instead of. So that was an assumption, right? And instead of building it right away, we've just introduced email campaigns menu item on the left, so the main menu and we put the email campaign there and when you click it it was just a type form which will clearly state, hey, we are planning to build this functionality. Can you help us with some insights? What would you like to see in this product?
- [30:46]
B
A quick break to thank our sponsor, Sprinto. Most companies treat compliance as a side project, but without it, enterprise deals stall. Sprinto turns compliance into a competitive advantage. Its automation platform unifies audits, risks and vendors. So you're always audit ready. With 300 plus integrations and AI driven monitoring, Sprinto keeps compliance running quietly in the background. Join over 3000 SaaS teams already using Sprinto. Learn more and book a demo@sprinto.com that's.
- [31:17]
A
Sprinto.Com and again for me it was such a surprise that during a few weeks we've received 300 replies. Like 300 people decided that their feedback is valuable. Like no, no Amazon codes, no, you know, no rewards, no, no discounts, nothing. We just put it into that soon we put this email campaign, email marketing soon and then survey and again a lot of insights prioritization from the feature perspective so you don't need to have clashes in your product team. What should go first. And you have already pretty valuable insight on the prioritization.
- [32:05]
B
So I love that. I think that's great. Really smart way of figuring out whether you should go and build that feature and how best to build it. One thing that strikes me is that up until that point you had a very clear niche with what Mailtrap was doing and because you were really about testing and that's what you had been built the brand around and now you're going into the space of sending which you know, not only are you potentially competing with these, these other products that you never had to worry about before, but what were, what were some of the, the main challenges you faced when you decided to, to move into the sending space as well?
- [32:48]
A
Yeah. So I must say that There are challenges on top of the challenges and on top of the challenges. So it's definitely not easy. So let me say that one thing build a fake SMTP where you receive emails. The other thing, building SMTP that sends emails like the whole Internet wants to hack you and send spam and scam. Like once you declare that you send emails, that's it. Like you constantly have attacks after attacks. It's completely different perspective. So you need to build spam shield and invest into that a lot. But we will talk about technical challenges later. So the biggest challenge that we are facing right now, and we put a lot of efforts actually to change this perception, is the brand perception. Because before Mailtrap was about not sending email to the inbox of real customers and it was a message like the core message of the product. But when we start to send emails to customers. So that's the goal for. So there are two opposite goals. For testing email, you must guarantee that it will not send email to the inbox of the real customer. With the sending product, you, you should guarantee that you will send two inbox. So it's confusing. I mean we understand it's confusing, but once you think about it as a developer, that there is one tool which covers your development flow. So you start your product and you introduce Mailtrop from the very first test, like we need to sign up on, like forgot password, whatever. So Mailtrop goes into the game early stage and you use it on staging environment. But then when you go to production there are not many changes. So you have just a configuration for production. So there are two configurations, staging and production. And Mailtrop does the job. So it guarantees to you that it will never send email from the sandbox, from the staging. And it guarantees you that it will send to production. Like from production, it will send to the real user. And that's the biggest challenge that we are facing because brand was perceived for so many years by developers like millions of. Because at the current moment we have just about 2 million signups over the course. So all those users, well not all of them because last year they are sending also, but let's say more than a million users considered Mailtrap only as a testing tool. And it takes us efforts to convince them that it's not only testing tool anymore. So it's our major bet right now on sending because it's much more complicated. It's. It's a huge market. And this is by the way why we decided to move into that. Because although customers loved our product like testing product It's a very niche product with a lot of, let's say alternatives. And those alternatives can be free kind of, it's. They're not that convenient. But users can decide that, all right, it may not be that convenient, but I will use like free version of some tool. While if we talk about sending, there is no free alternative, we have free package like 3, 3.5 thousand emails you can send monthly for free, but if you need to send more then it's already paid.
- [36:59]
B
Got it. So again, very interesting that you got user feedback on whether you should build this product, this feature, how you should build it, but you also got insights into what they didn't like about some of the competitors. Right. Can you, can you share an example of that?
- [37:22]
A
So when we were thinking about this sending development there was a trigger for ourselves to move into the direction because we also. So we were using other famous tool for sending ourselves and we faced a lot of unpleasant things. So we had the problem with deliverability to Office 365, but we never knew about it because all the dashboards inside the service that show that everything is green and nice and kind of no problems, while we've received quite a lot of feedback in the support that I cannot receive my email, I cannot receive my confirmation or like link or something. And so we started investigation and it was close to impossible to find through the provided dashboards and the analytics within the product, kind of those other service product. So what are the problems? So what we've did is we've took all the data from that service, put it into the BigQuery and and our data analytics team, they sat about two, three days digging into this data like gigabytes of data and trying to understand what can be wrong. And so we find out the perspective, how you should look at the sending data. And we've built a bunch of interesting dashboards that gives you an experience of drill down reports. So like you have a helicopter view and it shows you, highlights you if there are some risks or there are issues. And if you want to go into the issues, you kind of click deeper and deeper and deeper and you can find the root cause of the problem. And so we've seen that it's so much better experience than we have in that service that we use ourselves, that we start to think well maybe if we will build the product within such functionality it will be very helpful for the other users. And so we start to talk to our community of testing users because of course they evidently they send, if they test sending emails that they Send emails in production. So we've picked different cohorts, kind of smaller customers, bigger customers, individuals, corporations, and we talk to them about their experience with sending, kind of how do they like things, what they didn't like. And we find out that many of them are frustrated about the quality of support, a lack of advices from the product. So product does not advise you to what you should do next and kind of how you should do it correctly. There are some hints in documentation, but product doesn't guide you. And we've built sending in a way that product guides you to apply the best approaches. So you have high deliverability, so you have good analytics and we honestly show you if there are some issues and how to fix them.
- [40:55]
B
One sort of semi technical question for you about AI and we've seen recently people getting very excited about vibe coding and being able to build products more easily.
- [41:08]
A
Yeah, that's my favorite topic.
- [41:10]
B
Yeah. And often you find that the honeymoon period ends pretty quickly when they realize that they got, you know, they got sort of a scaffolding, a basic product built. But when they try to get more complexity into it, it often becomes a nightmare. And I'm curious about how you think about AI, how you use it as part of your business and what's the direction that you guys are going towards with that.
- [41:41]
A
The thing with AI hype is that there is a lot of hype, but there is also a rational part of it. And we having all this experience of years and years of building software, we try to kind of assess tools properly. Right. So without over expectations or under expectations, just clearly. So you have a test, you can write this code yourself or you can write it with help of courser and.
- [42:13]
B
So.
- [42:15]
A
You can compare the result. So kind of shortly we use AI inside of the team, but not for wipe. Like wipe coding can appear for product managers trying to hack something quickly to show before they did it in figma. So in Figma they just make some screens and then make a prototype. Clickable prototype. Right now they can do it with wipe coding, but still sometimes it's still easier to make in clickable prototype in figma. Anyway, so this part of wipe coding here. But we use AI as I'm talking about software. Right. Because not software. AI's applicability is very high. So like creating content kind of it should be done smartly, but definitely it is in use. We use for kind of PG decks and presentations and other things of course. But if we talk about code then corso copilot, we experiment with those tools. Our developers are free to choose between those tools. What we usually do is we have many different so as a product studio we have this advantage that different products have different stacks and different I would say trajectory. So there are simpler products, more complicated products. And so you are able to compare applicability of this technology, AI technology in the different conditions. And what we do is that our engineers, they actually work with course or copilot so they make some reports and then share in the. We have this craft engineering craft guild when they share some presentations, when they say that all right, so it's pretty good for writing tests, it's great for complicated refactoring when you need to replace some name of the function everywhere and it should be done so kind of swiftly. It's good in kind of templatization or it's good in creating first version of UI from the Figma screenshot. So kind of different team members use those tools, they share feedback. And so what we see right now, at least at this specific moment. So it's September 24, 2025. AI is just a tool that helps good engineers to be productive. It definitely fantastic in helping working with documentation, with analyzing code. So when you need to dig some logic out of the code base, it's so much easier because AI is able to combine knowledge from the code base with the technological documentation and propose you some solution which you may accept or you may choose something different, but it just reduces the amount of time you spent on educating yourself about this context. So yeah, this wipe code is the thing that and we just had a call before this podcast recording with my team for launching campaign Rails for web Services. So like it's just a development of software like I mentioned before and one of our campaigns going to be we will rewrite your wipe code so because it really becomes a nightmare as you've mentioned and we already have three clients who came to us with the wipe coded projects. But that's fine. I mean like it's just. It's just changing per Dygma how you started the product before you usually need to have some pro engineer, certain level of engineer who can quickly build proof of concept or MVP with Ruby on Rails or Symfony or any or like Django frameworks and then you go to investors right now this cycle is shortened so you, you can wipe code something proof that this feature or idea can work, get round of investments and then come to company like railsware or other company with strong engineers who can create a good product from that concept. So but usually you should throw away the code that is written, it's hardly maintainable so you will need to spend more time to maintain it rather than rewrite things from scratch.
- [47:42]
B
Yeah, I mean I've had this conversation a lot with founders in my SaaS Club community and I think where we've sort of ended up is, you know, it's if you're, if you're non technical or even if you're technical using this sort of vibe coding sort of approach to take an idea to prototype maybe an mvp, whether you're going towards investors or trying to get those first five or 10 customers, you can probably get that far. But if you think that you can continue that to get to a seven figure arsas business and beyond, that's probably highly unlikely, at least based on where we are today.
- [48:23]
A
Highly unlikely, yeah. Unless it's, I don't know, it's like database of vacancies and you're in a spot like you have some very good traffic source which goes, I know candidates and firms. So when you have some sweet spot in Marketplace and you just build some simple version of Marketplace, very, very simple one and then you can make those figures but just a few more features here, a few more features there and it stops working. So it's hardly maintainable.
- [48:54]
B
Yeah. So there definitely comes a time where this thing that you've built, it needs a professional developer to take over and continue. And I think especially if you're working with a developer who uses AI but knows how to implement the right guardrails in place to be able to use it for what it's good at but not give it any more leeway to do more than you need to, I think that is a superpower combination and so I think that that's a really interesting space that's coming out. And the more I see developers who, you know, people are like, oh, this is going to put developers out of jobs, I think it's actually going to be the opposite. And especially when you have developers who are really smart with how they use AI, I think that's going to be a killer combination.
- [49:44]
A
Just one quick comment here speaking about that. We've seen it as another tool that makes you like mix developer a bit more productive for some percentage. Hard to say which percentage because it really depends on the complexity of the product, kind of skill of the engineer and so on. But definitely it's not like a replacement of engineers and it's not 300% boost, it's just, I don't know, 20, 30, 40, 50% boost. But if you will roll Back kind of history, you will see that such changes happened before. So there was assembler or before assembler there were like those paper cards and then there was assembler. It was so much more productive than those paper cards. But then languages like Turbo Pascal appeared and it became like engineers become 100 times more productive than they were with assembler. But then rapid development frameworks appeared like Delphi and so developers were able to build desktop applications with the speed they haven't seen before. And like much smaller teams, similar things happened with the web when frameworks like Ruby on Rails appeared on the market. Kind of just compare how much software engineer was able to build with those open source solutions. It's just they became hundred times more productive. So that was much more influential point in the productivity of software developers than right now AI. But I'm saying again, this is for this moment. I believe that it will be hard to achieve with LLMs, kind of some bigger results, much bigger results. But if they deliver like those giants will develop some other logic of this generative AI which will think like a person, then it can be a trouble. But so far LLMs, they do not give you such boost like it is promoted. So I think it's a bit overhyped at the moment.
- [52:03]
B
Yeah. All right, let's get on to the lightning round. I have got seven quickfire questions for you. Are you ready?
- [52:10]
A
Yep.
- [52:11]
B
Okay. What's one of the best pieces of business advice you've received?
- [52:16]
A
Go with the flow.
- [52:17]
B
What book would you recommend to our audience and why?
- [52:21]
A
I would recommend the Power of Now by Egghartole. So it's not about business, but it's about the possibility to appreciate the moment Now. So when you are in active development of the business, you are overstressed and you need some point where you can appreciate the Moment of Now and the work you do. Do not wait until you become a billionaire and only then you will appreciate yourself. So that book teaches you to appreciate the moment Now.
- [52:58]
B
That's a great book. I'm definitely somebody who overthinks and I read that book many years ago and whenever my wife sees my overthinking, she's always like, you need to go back and read the Power of Now.
- [53:13]
A
Yeah, that's fantastic. And there is one more of the same. Author is the New Earth. It's even better, I would say. But you need to read it after the Power of Now.
- [53:26]
B
Cool. What's one attribute or characteristic in your mind of a successful founder?
- [53:32]
A
So you never stop.
- [53:34]
B
That's a good one. What's your Favorite personal productivity tool or habit.
- [53:39]
A
My productivity, it's Spotlight. Like I like this experience in every tool when there is a search line and you work through a search line or terminal command line. So it's. And that's why I like kind of this new ChatGPT experience. I mean this GPT AI experience. This. It's like an advanced command line, actually. So you type what you want and you get the answers.
- [54:08]
B
What's a crazy or business or crazy business idea you'd love to pursue if you had the time? Not that you already have a number of businesses you're working on?
- [54:19]
A
Oh, Jesus. No, I don't have anything in my mind honestly here.
- [54:24]
B
I think you got to pass on that, given all the products that you're building anyway.
- [54:28]
A
Yeah. So we just, for those who don't know, we have really multiple products in development. Yes. And the portfolio kind of which is not. Has not been released or even started, is even bigger. So I'm rather searching where to stop, not just what to add in this portfolio.
- [54:49]
B
What's an interesting or fun fact about you that most people don't know?
- [54:53]
A
I am a professional swimmer.
- [54:55]
B
Okay.
- [54:57]
A
Well, was in my kind of early years. Yeah. Of course I'm not a professional swimmer anymore. Like I'm too old, but I was a part of Olympic reserve in my country.
- [55:09]
B
Nice, nice. And finally, what's one of your most important passions outside of your work?
- [55:15]
A
Sports activity? I do snowboarding in winter. I do bike and running in summer and spring. I do swim sometimes, but I had enough of my. Of swimming in my early days. Yeah. So that's. And I do love spending my time with family, so all my family trying to be as active as I am. So we love to spend time on the ski slope and riding bikes.
- [55:48]
B
Great. Well, Sergey, thank you so much for joining me. It's been a pleasure. If people want to check out Railsware, they can go to Railsware.com and if people want to check out Mailtrap, it's Mailtrap IO and if folks want to get in touch with you, what's the best way for them to do that?
- [56:05]
A
Just write@contactalsvery.com contactosevery.com or find me on LinkedIn.
- [56:12]
B
Great. Well, thanks again. Thank you for unpacking your story and sharing some really super practical insights and lessons about your experience with building Mailtrap. And I wish you and the team the best of success.
- [56:27]
A
Thank you very much. Thank you for invitation and it was pleasure to talk to you.
- [56:31]
B
Awesome. Cheers. Thanks again to Sprinto for supporting this episode if compliance is eating your team's time, there's a better way. Sprinto automates audits and risk management so you can focus on building, not chasing evidence. SOC 2, ISO 27001, HIPAA all handled from one simple platform. Go to sprinto.com and book your demo today. That's sprinto.com.