Ripping off bandages

Every growing ESP reaches a stage where they realize that fundamental parts of their stack need to be reworked to address the growth of their business and the demands of their customer base. What happens more rarely is that they give you an unfiltered look into that, because it seems “unprofessional” to tell everyone where your weak points are. Everyone has them, they just don’t want to communicate them. Silence and vagueness are often seen as strengths, as a result of this. I disagree that those things should be valued. I believe that your customers deserve to follow your journey, no matter how messy that might look. Don’t just change the product on them, let them in on the struggles you’re facing to give them what they want.

MXroute started out using a free web hosting control panel (VestaCP) as its front end, with WHMCS as its billing/provisioning system. We manually stripped out web hosting links in the control panel, and offered the most basic email hosting anyone could find. The goal wasn’t to provide the front end user experience that people expect from major email services. It was about providing you with an inbox, giving you a low cost option without user/domain limits, and working hard to make sure that your outbound emails weren’t halted by the bad IP reputation often witnessed with the web hosting providers that bundle email into their product (typically as an after-thought, and only because cPanel bundled the features). We expected a bunch of Linux admins to sign up because they were tired of IP reputation issues, and that’s all we ever meant to be back in 2013.

When VestaCP experienced a major privilege escalation issue, we realized that it would be better to rely on a vendor that was financially obligated to patch software quickly. We migrated to cPanel, which afforded us a greater feature set at the same time. When cPanel started shaking us down for cash, we turned to DirectAdmin. At the same time that the cPanel price hikes began, the WHMCS pricing model changed in a way that attacked our business strategy, so we migrated to HostBill. It was more difficult to consistently alter the DirectAdmin user experience to create a curated experience that had no bleed over from the web hosting functions of the panel, but our users mostly understood what was happening.

As we grew more, our customers demanded a more coherent email experience that more closely resembled their experiences at major email providers. Along came Crossbox, a company that created a product that stacked on top of cPanel or DirectAdmin and layered a bunch of these features on top of the existing systems to provide that.

As we grew even more, we saw more and more end users that didn’t understand the choices we made or the inherent UX oddities present as a result of our choice to use a web hosting control panel for email only. So we developed panel.mxroute.com and management.mxroute.com, both API frontends for DirectAdmin and HostBill. This allowed us to offer a more complete and streamlined user experience that just “made sense” to more people.

After that, our growth was even greater. Customers started pouring in from other ESPs as industry prices started rising. Those new customers would echo the same complaints and confusions about the service that many of the customers from our previous growth periods expressed. Whether or not they were aware of it, many of these complaints and points of confusion would trace back to DirectAdmin, Crossbox, and HostBill (very rarely HostBill, but I’m including it anyway). Not necessarily because there was something “wrong” with those applications (though in many cases that would be the case), but because the limitations around the design of those applications required far too much tech debt (some of which would become points of failure on software updates) to change the things that were frustrating them.

To continue addressing customer feedback, the only viable path forward is to start chipping away at third party software, to start migrating away from it and into in-house software. We have to stop outsourcing things to people who are not developing exclusively for MXroute customers.

The problem is that this is where we have to face two camps of users. In the first camp, we have users that are leaving if anything changes. In the second camp, we have users that are leaving if nothing changes. Many of the changes that are needed require changes that do not appear, to the average onlooker, to even be related. Because dependency chains run deep. So that forces me to make a choice of who I’m going to upset. In my opinion, the only right choice is to upset anyone who would leave over changes that are required to provide users with an experience that is most commonly expected up front. It’s not enough to say “I didn’t promise you that” if I’m having to say it increasingly and our credit card chargeback rate is growing. The things people expect from an email provider should be the things we’re willing to make brief disruptions to provide.

This year, we want to migrate away from DirectAdmin, Crossbox, and Roundcube. New customers already have no interaction with DirectAdmin, but they do have interactions with its limitations and frequent errors. Once we do this, the options we have for addressing your frustrations and complaints grow exponentially.

Now, will we give everyone plenty of advance notice of these changes? Sort of. We’ve already replaced user interaction with DirectAdmin and encouraged users to stop going to it directly, we just haven’t stopped older customers from continuing to use it. Crossbox isn’t our product, it’s merely one choice of webmail clients and webmail isn’t even a requirement. In these cases, this blog post is the advance notice.

Will we aim to make the transitions painless? To the best of our ability, yes. We’ve been working tirelessly to implement the things that users need to be able to painlessly leave behind these third party applications, at least where the implementations needed don’t require that the transition occur before we can even do so. The goal is a smooth transition across the board, in every way that we can reasonably facilitate.

We’ll keep you informed of what we’re doing as we’re able to do it. Our aim is not to interrupt your workflows, though you may visit a familiar URL and see an unfamiliar change as you would with any software update.

← the evolution of the cron job (aka improving reliability with local llms) ↳ subscribe via RSS