Start free trial Book a demo
Webinar on The Art of API Documentation: Best Practices for Writers - August 07, 2024 | 2:30PM UTC - Register Now!

From an idea to over 100 paying customers in less than 2 years

Category: Product Update

Last updated on Dec 1, 2023

Back in October 2017, I was at Redmond, Washington at the Microsoft Campus running our annual conference INTGRATE 2017. During that time one of the parallel tasks I had in my to-do list was to find a good knowledge base solution for our core product BizTalk360.

At that time, we were struggling for at least over a year with various challenges on our product knowledge base. We were using the self-service knowledge base solution that came with our help desk software and we were clearly outgrowing its capabilities and we need an alternate solution as soon as possible.

Our growth graph

Problems we were facing

Some of the challenges we were facing at that time

Version control: We had few people working on our knowledge base and it started to happen repeatedly the current content (sometimes really good ones)  getting replaced by new content whenever someone edits/updates the topic, and there is no version history.

Auditing: We had no idea what was going on in our knowledge base, people adding stuff all over the place, adding/replacing content, publishing live documents, delete categories and so on.

Loss of content: We were investing heavily in content with two full-time technical writers, and the whole customer support team constantly adding articles to our knowledge base.  We had an incident where someone accidentally deleted the whole category with at least a months’ worth of work. We never managed to get it back. There was no solution for periodic backup or restore on the platform.

Granular security access: In our knowledge base there are various categories, certain categories are deep-dive articles, only some core technical people can write and maintain. But in our case, we couldn’t restrict and have seen non-technical people making changes with inaccurate content.

Real-time Search: The search was very poor with no analytics. Either the search was performed only at the title level or it didn’t return appropriate results for some technical terms.

Analytics: There was no inbuilt analytics on the knowledge base, all you can do is just plugin the Google Analytics snippet. GA is good as a general analytics platform identifying visitor’s behavior, however, a knowledge base requires more sophistication. Ex: Search Analytics. It’s important to know what keywords your users are searching on your KB whether they are finding answers or not. For every failed search, they are going to raise the support ticket which can be easily deflected if you have a good knowledge base.

Category management and editor: At the face of it, everything will look fine, but once you are working full time on your knowledge base, you’ll start noticing various issues. Inserting videos will require enormous effort, code blocks and call outs will require custom work, category hierarchy is restricted to only 3 levels, you cannot move articles between categories easily, and so on.

Publishing Workflow: We were not having any control over who is publishing live content, our editorial process was controlled by the manual process which failed most of the time and no visibility (auditing).

In addition, there were about another 4-5 core features we were missing like SEO support, Redirection (when we move the article from one place to another), and Localization (we didn’t have the requirement, but it was not there), etc.

Birth of an Idea

Being a technical person, for me, the above requirements are pretty preliminary for a good knowledge base.

I initially thought we were facing all these challenges because we were using the knowledge base solution that came bundled along with the customer support/help desk product and if we move to a dedicate knowledge base product these problems will go away and I started my research to identify the right product in the market.

After a couple of weeks of research, the results really surprised me. At the one end of the spectrum, there are enterprise quality technical writing products that are extremely complex, expensive and still missing a few things that are required for an online knowledgebase. These enterprise products are designed more for technical authoring and multiple platform publications (print, online, etc), but requires efforts to host it and maintain it.

On the other end of the spectrum, there are pure online knowledgebase products who claim to be good, at the face it looked like it’s ticking all the boxes, but once you start exploring they started to fall apart. The editor/category management experience was poor, auditing, security access, etc non-existential. The marketing site looked fantastic, but the product falls apart.

At this point, I was convinced there must be enough people in this world experiencing what I’m experiencing. Being an entrepreneur and having the confidence and ability to build a technical product, I thought instead of keep complaining why don’t we address the solution. There is a famous saying “don’t fall in love with your solution, fall in love with the problem”. This is that Eureka moment, I really wanted to solve these problems.

Business Plan

For many years, I have this practice of raising up early (around 4:30 am without an alarm) and work for 3 hours on core activities. That’s my regular quiet period for myself and I tend to do high-intensity activities during that time. I follow this practice in spite of wherever I’m in the world, whether I’m on business or on holiday.

I was staying at Hyatt Regency, Bellevue (a few miles away from Redmond) and following the same morning routines, this time doing my analysis for knowledge base and seeing all the above-mentioned problems. The moment I decided we are going to build the product, I started documenting all my findings as a business plan.

I captured the core requirements and challenges that we are facing, started putting together wireframes of how the UI/UX will look, and what are the core features we wanted to bring in the product.

I returned back to London from that trip but continued working on the technical specification document for about 6 weeks on my own, without telling anyone. Finally, I had a full technical specification, what features we need, what are the core ones we need to build first, wireframes for the screens, etc.

Here is one of the early prototypes of Document360

I even mapped out the technical stack, what provider we are going to use for authentication, search, data, cache, etc

Choosing the name

It took me only an hour or so to decide on the name, I wanted something with 360 in the name (due to our other product alignments) and something related to knowledge base and technical writing.

The number one criteria these days is whether your domain is available, after juggling with few options I settled for the name Document360. The .com domain was available but for a premium price, at this stage, I was not 100% sure about the project viability, so I just bought the .io domain at the standard price. (later we purchased the domain for $10k)

How quickly can we build v1?

Being an entrepreneur, when you are pumped up with an idea and can see a market potential you really want to build that stuff as soon as possible. But the reality is you won’t have resources. All of our engineering resources were busy with our other products and we didn’t have any bandwidth to start a new product.

But I felt this idea is something worth perusing and taking bigger risks. Something that made me not sleep seeing a missed opportunity and I has everything ready to take the next step.

This is when I took the drastic decision of pulling our entire company together for a two weeks hackathon in Dec 2017. You can read more about it here. “Ambitious plan to build a new product in 14 days

I presented the technical specification to the entire company on an all-hands meeting and announced we are going to build the MVP (minimum viable product) in 2 weeks between Dec 1st to 15th 2017.

We flew people from London to our India office and pulled the entire team of 35 engineers into the hackathon. At this point, I went one step ahead and mapped exactly how many teams are going to be there, who is going to deliver what, and how we are going to integrate things together.

Our years of experience building and scaling software products helped us a lot and at the end of two weeks we had a fully functioning product “Birth of Document360 – The Inside Story Behind Our 14 Days Hackathon”. Of course, it’s not stable, it’s not ready for production, but it gave us the confidence this product can be built to our expectation.

Sign up for your 14-day free trial with Document360 now

Get Started

Assembling the team

I returned to London after the hackathon, enjoyed the Christmas break however at the same time continued my morning routine putting plans together to take Document360 further. In the new year, we reshuffled the current project priorities and pulled a team of around 8 engineers to start working on the Document360 product.

At this point, we are fully committed and made the decision to go ahead in adding a new product to our portfolio. We cleaned up the hackathon code, pretty much thrown away a lot of stuff that was not well built (prototype quality) and from the ground up started working on a new code base keeping long term view in mind.

Product First & listening to customers 

We had a very clear plan of the features we wanted to build. I put together a road-map up to version 5.0 (3 months per version, 15 months total road-map), with the first version containing the absolute core features necessary for a knowledge base and slowly ramping up with more advanced features on further versions.

I strongly believe in iterative development. It’s impossible to build a world-class product on your first iteration. We have changed the complete UI/UX layout at least 5 times in the last 2 years. Every time we add a feature, we need to reshuffle the UI so that the features are discoverable and easy to use. 

We wanted to take the product to the market as soon as possible and wanted to build it with the customer feedback. We released version 1.0 of the product after 5 months in June 2018. That month we got 2 customers. I don’t know from exactly where they found us, we were writing blogs and engaging in the social media groups, Quora, etc. I was very particular our initial customers must be strangers, not friends and family. Only then you’ll get the true feedback. 

We were rolling out features continuously pretty much every 2 weeks once. Being a hardcore tech company building enterprise-grade products, we never had any challenges on the technical side of things.

We were constantly getting a handful of customers month-on-month, we were listening pretty carefully to those initial customers, making sure they are getting what they want. We are focusing on closing initial sales one at a time, every time the customer needs certain things we will reprioritize our development and deliver it, close the customer and move to the next one. One thing to note, we only built features that are in our road-map, not random (customer-specific) features.

The whole of 2019 we followed the same process, closing one customer at a time, fulfilling their requirements and stabilizing the product.

I strongly believe in this statement.

I keep telling my team, if you are a restaurant, nothing else matters except the food. If your food is good the word of mouth marketing is too powerful, it got inbuilt virality into it and your business will thrive. The same applies to good software.

This is exactly how products like WhatsApp, Uber, Instagram, Apple, and Facebook found success: They poured the majority of their early resources into building unprecedented products and services.

This is how the current version of Document360 looks

We pay attention to every single piece of detail on the screen. 

100 paying customers

This week we reached the first big milestone of 100 paying customers (with 1000’s of users since each customer is a company). This is one of the big feet and proud moment for us to look back and see the road we have traveled, making the right decision almost 2 years ago and keep pushing continuously without getting distracted.

100 customers in 2 years may not be a fancy number in a fast-paced technology world, where venture funding is enormous and growth at any cost mindset is a norm. However, we took a slow and long term view of the “Product first” approach. Now we are confident the product is ready for acceleration. We strongly believe pre-mature scaling will hurt you badly.

Within the 100 customers, we have a variety of profiles, right from small start-ups to Fortune 100 companies to unicorns. Some of the prestigious brands like Microsoft,,, IATA, Stackify, Harvard University trusted us to build their knowledge base (some of them are private).

Thank you. All I can say is thank you to everyone, first my team who stood behind me and trusted on my gut feeling and then our customers who made this milestone possible.  


Saravana Kumar

Nov 13, 2019

The Art of API Documentation: Best Practices for Writers

Related Articles