How we grew Mintlify by doing things that don't scale

Most people envision the process of founding a startup to play out like this: the founders brainstorm around a whiteboard, there is a lightbulb moment when a golden idea is born, users flock to the startup the day the product is launched, and then the founders ride off into the sunset to build a successful billion dollar company.

While I certainly wish this were true, experience tells me that this could not be further from reality. Instead, what usually happens is a startup launches their product, and either the product does not work, in which case no one uses it, or it does work, but no one wants it anyway.

As engineers, we are by default taught to build the thing that is as close to “perfect” as possible: it has to scale, and it has to be high-performing. After all, engineers are trained to build bridges and airplanes where imperfections are costly. But for startups, this creates a trap of startups spending significant time and resources trying to create the most optimal product, only to launch and realize that it does not really address a customer need.

Growing Mintlify

Doing things that don't scale refers to the idea that most startups require a laborious process, separate from the building and launching of a product, in order to acquire customers and really take off as a business. In the process of acquiring customers, startups gain insightful feedback to better translate user “need” to “product.”

While this is not a new idea (Paul Graham wrote a near biblical essay about this back in 2013), it is certainly not an easy pill to swallow.

It was something Hahnbee and I had to learn the hard way when we first started Mintlify. We needed customers, and we were determined to go out of our way to get them.

Our very first customer

By the time Hahnbee and I had arrived at our model of what would eventually become Mintlify, we had already gone through 7 pivots.

At our 8th product, we had nothing to lose. Over a weekend, we built the prototype, essentially a website of static pages that could host documentation content. It was a half-finished product with no back-end infrastructure, but we decided to put it out anyway. All our previous scrapped projects had taught us that before we pushed any further, we had to validate our idea first.

We pitched the prototype to someone who we were familiar with and who we knew had a use for our product. I called up Declan, a friend from the same YC batch and my future roommate at the time, offering to build and improve the documentation for his startup Hyperbeam. He agreed, but mentioned that he had no time to set it up. That was not a problem for us.

We went ahead and migrated his documentation. On top of reviewing their content, we built a simple webpage that housed Hyperbeam's new and improved documentation. It was a literal brick page. We did not even have any functions that would've allowed Hyperbeam to update their content.

Despite all that, the new documentation got an overwhelmingly positive reaction from Hyperbeam's team and their customers, and even helped acquire new users. We received our first ever payment, an important milestone for any new startup, and Hyperbeam became our very first customer.

It was a sign that we were finally doing something right.

Hahnbee and I continued building out the prototype after that, adding key functionalities that we hadn't had the time to build during our weekend-long sprint. As luck would have it, by the time Hyperbeam needed to make edits to their documentation a month later, we had just built out the function.

What had started out just as an idea and a half-baked product gradually became a comprehensive solution, and Hyperbeam has been our customer ever since.

Acquiring our first 10 customers

We took more or less the same approach to acquiring our first 10 customers as we did our very first.

We reached out to our founder friends from the same YC batch and asked if they were interested in trying our product. Even if they weren't that sold on the product to begin with, we offered ourselves as their technical writers and improved their documentation content for them.

Interestingly enough, this was an approach that appealed to a lot of founders. Often, we would spend hours or even days reviewing and editing a customer's content. We'd revise grammar and formatting, in addition to manually migrating their documentation to Mintlify. After seeing their improved documentation, many stayed as our customers.

It was a laborious and time consuming approach, but it was effective in getting our customer base started. At that point so early in our growth, what mattered was delivering an experience beyond people's expectations to convince them that we were even worth giving a shot.

Growing to 100 customers

To grow from our first 10 to 100 customers, we had to take an even more proactive approach. This meant researching potential customers and then spending many hours building a version of their documentation on Mintlify, all before even establishing any communication with them. When we were done, we'd send them a cold email, including the revamped documentation.

Building documentation for a cold connection might seem like an unreasonable use of our time, but it worked surprisingly well. It helped us onboard more users, to the point where after a while, it was no longer feasible for us to continue reviewing documentation content for our customers.

We learned a lot from our experience manually migrating and onboarding our customers. From the experience, we found trends and insights. We took those ideas and built out the first version of our self-service onboarding flow. It still took many iterations until we got it right, and there's still a ton of room for improvement. You can check out our progress at mintlify.com/start.

What we learned

Looking back, what we did to grow Mintlify was exactly all the things that didn't scale.

In the beginning, we couldn't really compete with the incumbents who had many features and existing products. We knew that the product didn't have everything the customers wanted, but we launched it anyway, instead focusing on gaining those first few customers to validate the idea.

We went out of our way to do things that our users would not have expected and honed in on delivering a delightful customer experience—all so we could compensate for a product that, at the time, still had a lot of space for improvement.

It was painstaking, but it made all the difference. By acquiring those initial customers, we gained invaluable feedback on where to improve our product, what components were missing or needed scaling, and what features our customers actually cared about the most. None of this would have been available to us if we hadn't gotten the ball rolling on acquiring customers first.

It helped us expand and optimize our product, until we had something that could hold its own, if not outperform, against our competitors.

Where we are at now

Nearly a year later, we no longer review and offer feedback on customers' documentation content. With over 1000 customers and counting, the scale of these tasks have simply expanded beyond our ability to provide them. But, the philosophy of doing things that don't scale has forever stuck with us.