Get a DemoStart Free TrialSign In


4 min read


For our latest specialist interview in our series speaking to technology leaders from around the world, we’ve welcomed Fabian Jäger, CTO & Co-Founder at Mailbutler to share his insights on what it is like to be a CTO at a fast-growing startup.

Tell us about the business you represent?

At Mailbutler we aim to provide a digital email assistant for the self-employed, freelancers, and small companies to structure, enrich and boost their everyday business email communication and email-centric relationship management – all right from their inbox.

To achieve this, we build an extension to existing email applications, so that our users do not need to leave their known environment, but get additional tools by installing Mailbutler.

While other similar products target mass email campaigning, we focus on the 1-on-1 business email communication and optimize our users' daily workflow in a way that they do not feel as tired of business emails as they did before starting using Mailbutler.

Being the CTO, what do your day-to-day responsibilities look like?

I interpret my role as CTO at Mailbutler as being a manager, an internal consultant, a facilitator, a strategist, and probably a lot more. During a regular week, I participate in many different meetings, mostly with different colleagues from the product & development team.

Moreover, I try to always stay ahead of everything, which requires knowing the product very well. Only by knowing the status quo, decisions for the future can be taken reliably. To have a good overview of what technologies might be of interest to the team, the product or the company, I read a lot in blogs, and magazines and follow discussions inside and outside the company.

What frameworks do you use for managing technical debt?

We use project management tools, such as Jira, to always have an overview of work items. During development, the team uses many different linters (e.g. Rubocop, ESLint) to ensure code quality, static analyzers (e.g. Xcode) to find quirks in the code as early as possible and test frameworks (e.g. XCTest, Jest+Puppeteer) to ensure high product quality.

Additionally, we spend a lot of time in manual code reviews to squeeze the optimal solution out of any code change. As the last step, we have a relatively large quality assurance team that constantly checks different versions of our application for unexpected behaviour.

How do you decide whether something is so painful that it merits a full rewrite?

This decision is primarily based on whether the team complains a lot and very frequently about certain parts or components of the code base. I would do a re-write to reduce frustration within the developer team, because if they are constantly avoiding working on certain code parts, the product suffers, too.

While developers (including myself) often prefer to jump on every new technology and do refactoring and re-writes every now and then, a CTO also has to keep in mind that such changes always also lead to risks for the product and consequently our customers. That’s why there are two hearts beating in my chest, that of the developer and the CTO.

How does your technical organization work with the other operational components of the company?

We have a weekly meeting between the product owners from marketing and product & development. In this “cross-team” meeting, a senior customer success manager, the CEO and I as the CTO participate to exchange about the status quo and upcoming events, changes, etc.

Moreover, the product & development team, including the software developers, are in constant exchange with the customer success and quality assurance teams. We want to ensure that we know exactly about our users' pain points and about issues with the product and feature requests that they might have. Letting developers know how the users think about what they have built, raises awareness and makes them think and act like owners and see through the customers' eyes (two of the six core values of the company).

To be honest, there is no hot trend in the industry we are in. Our product is based on email communication and this technology has already existed for more than 50 years (the first email was sent in 1971) and has not changed significantly since then. It just works! And I am pretty confident that email won’t be replaced by anything within the next 10-20 years.

The trends we could be affected by might be auxiliary or companion services that enrich emails. I would like to see better HTML support in email applications. Their HTML rendering engines are comparable to web browsers from 10-15 years ago, which is quite embarrassing. When you look at the functionality of the email system, it is basically Mailbutler itself that sets some trends, such as email tracking, scheduling, or enriching email conversations with contextual information.

Do your technical teams or do you use log analysis as part of your role? If you do, how do you find this helps day-to-day operations?

We currently use log analysis only very infrequently whenever there is a larger issue with our backend system. Only then do we dig deeper into all the logs that we collect in our cloud infrastructure. Having some better tools to perform continuous analysis might be very helpful for us moving forward. For us, the whole process is currently too time-consuming, but this might also depend on the tools that we use and do not use yet.

What can we hope to see from your business in the future?

We plan to further tweak some of our existing features, such as Send Later. Moreover, we are going to extend our Contacts feature with some very helpful tools to enrich and boost our users' everyday email conversations. We constantly try to get closer to our vision of “making business email communication loved again”.

If you enjoyed this post then why not check out our previous article on the best Prometheus dashboards or our blog post on APM tools?

Get the latest elastic Stack & logging resources when you subscribe

© 2024 Ltd, All rights reserved.