To retain users, you should pare down features

Today we are launching on Product Hunt after 2 years of building. We know this is the right moment because our user retention is at an all-time high and developers tell us every day how much they love our tool. But it was not always this way. Below I’ll talk about our road to product-market fit for Arctype, and two major decisions we had to make along the way.

What can we build for makers? That was the question we started with. Justin was an engineer at a data startup and worked with portfolio company data at the VC firm, Social Capital. I was the CTO of a retail AI company. I always felt my tools could be better. Marketing and business people have new flashy products — why did my interfaces look like they had not been updated since 2000?

When I was combing through retail data, digesting product analytics, and building internal tools, I found it was always a problem to get data in, filter and sort it, and just get a quick chart to show to someone. Nothing worked together well, and if it did, it would cost thousands of dollars per license.

No code tools solved this problem. I had admired how Retool had not only built a no-code tool, but an internal tool builder too, effectively creating a market segment for themselves. So the first versions of Arctype had built no-code features that let you write JavaScript alongside SQL, and chain operations together to move data around visually and transform it.

Even with these no-code features, our users still wrote (or often generated using our GUI tools) a lot of SQL. That was interesting.

Even if we thought it would be beneficial to build no-code tools, should we stick to that vision, or follow what our users were doing?

Many makers face similar forks in the road as they are building. To answer this question, we followed the standard procedure: interviewed users, changed the product, watched the analytics, and so on and so forth.

But the honest answer is we did the “Mom Test.” That is, does your mom know what an internal tool is? Everyone (in our target userbase) knows what a SQL client is. Within our community, most people come in with a familiarity of what SQL is and they can use it for. Why take away what they’re already comfortable using?

Earlier this year, we made the decision to remove ⅓ of our code and deprecate the internal tools piece — 1 of the 4 main tools in Arctype. We sent out migration emails and nervously pushed update.

No one mentioned anything. In fact, retention increased! From there we learned to be more fearless in changing the product and throughout this year we’ve removed more complicated features and UIs too, showing preference to simplicity and very high quality. Lesson #1: Arctype is a SQL editor and database GUI first.

The second fork in the road was database support. Should we support many popular databases with a mostly comprehensive feature set, or have the best tools for a few select databases?

It’s not an obvious choice. Databases have so many features, and certain specialities for each one so most users don’t encounter gaps. There are over 300 databases, how much work could this be?

We determined that even though there are hundreds of DBs, the open source community has chosen a few interfaces that most databases implement. For example, Spanner on Google Cloud can be connected to from a Postgres client, even though underneath it bares little resemblance to Postgres. And PlanetScale, a database meant for serverless applications, implements MySQL.

There was also the issue of SQL, or lack thereof. You can write SQL almost anywhere (except No SQL, where you cannot write SQL), but companies use all types of databases to build their products, including ones that do not support SQL.

To sort through all of this, we interviewed users — or they told us what was up in support chats. We created a linear board to track which features got brought up by users, and what kinds of apps they were building.

Again, it came down to cutting rather than adding and our users and usage patterns again pointed the way. In the same way that marketers and business pros had great software, developers who used commercially supported databases had great clients, but for open source databases, the options were more limited.

In our server, we were constantly helping users with Postgres and MySQL clients. Pretty often, these clients just had so many features. Users would ask us: “How do I download a CSV?” Even, “Where is my list of tables?” And always with an undercurrent of “Why do I have to look at this UI all day?”

As Steve Jobs said, “Design is how it looks, and how it works.” It turns out that, for Postgres and MySQL, how it looks was typically less of a consideration. SQL clients were built for database administrators, who rightly need a comprehensive set of features. They also deal with sometimes hundreds of databases with many tables. So many database clients show every feature of a database, even when a user doesn’t use the features! This has led to an overwhelming UI, which then feeds back into all those questions we were getting from developers and makers who were trying to write a little SQL.

We realized we could simplify and invert. Open source databases without a singular company behind them had the users who suffered the most. Developers also often wanted to craft their database and write some SQL but did not necessarily need to bother with procedures and views. Arctype could gradually reveal these features in the UI with a few simple tools and a tab system.

So the decision was made. Instead of 10 types of databases, we could focus on two. And go deep. Within a few months of building, the decision paid off. People started calling us their “favorite Postgres client” or the “best MySQL GUI.” We realized that being attached to a particular database as the preferred tool for its uses was a great thing, and actually preferable to being a general SQL tool.

My #2 takeaway here was that you can always get more specific with your user. Whichever category you’re targeting, there’s actually an even more specific category that might help you gain true fans — and fans turn into customers in the developer tools space.

So from these 2 forks in the road — whether to be an internal tool or a SQL client and whether to roll out every database or focus on a few — Arctype found our fit and our fans. By cutting out features and focusing, we were able to actually build the best tool for developers. And today, we are launching that tool to the Product Hunt community.