Why we want to grow with our customers

Building our first feature (again)

Like many indie hackers, we‘re building a SaaS product. Our goal is to build a highly integrated set of building blocks for software/product teams so that they can focus on the things they‘re good at providing value.

As both Bruno and I have built multiple different projects, we already had some sense of which building blocks are important to us. But we had to validate it.

Talking to engineers of more mature projects revealed that many of their problems in our focus area had already been solved, but most of them by hand or with a solution of a specified provider (think of Stripe for payments or Auth0 for auth/user management). Still, they all had this problem to solve first, so this is where we wanted to start out.

Our first building block for our software is user management. It made sense for us to start there, as, for example, our previous approach of providing resource management did not work out. There was/isn’t enough trust in us to provide a fully scalable solution to resource management. We do need to build this trust down the road, and we hopefully will, but considering the sensitive nature, this of course was hard to validate.

User management, instead, is one of the first problems/needs engineers encounter when building their products: If they want to support social logins like Google or Twitter they’d need to build a sophisticated data model first without adding a single line of impactful code. Also, nobody wants to store (salted/hashed) passwords anymore. Thus, a pluggable solution also seemed for us to be a good starting point.

There is, of course, already a bunch of colorful options to choose from to integrate user management. But in the end, it does fit well with our larger vision, to increase the velocity of teams. And another thing: we want to deeply integrate out features with each other. This is where we can deliver value without compromising too much because of our relative (and absolute) lack of resources compared to larger companies specialized in one of our topics.

So, we want to grow with our customers to feel similar pains to theirs. This is, besides talking to them, one of the best ways for us to know what to build next and what might be important to them. Eventually, most SaaS companies want to sell to large enterprises. But we’re confident that our (future) customers will reach that point together with us, so we can provide value along the entire lifespan of a business just like ours.

Some learnings from our interviews

And to close it off, another very interesting thing we’ve learned (or, let’s say, it surfaced): the importance of good documentation (for developer tools). Most engineers of course know that to be true, but there is a big difference between “feeling” the effect of good documentation and being told that it actually is a big part in a decision of choosing a product (over another).

So in one of our interviews our interviewee said that they didn‘t check out a technology specifically because they did not understand the docs well enough. Which of course happens when a user is not familiar enough with one technology. So, if you‘re building developer tooling some way like we do, you probably want to spend a significant amount of time crafting high-quality docs.