Good SaaS Products Are Like UNIX Tools

Friday, November 12th 2021

These days, SaaS (software-as-a-service) companies do too much. Very few focus in on a niche market and ultimately stick to it. There's an obsession with growth, to every vertical possible, in order to squeeze out as much revenue as possible. Or so it seems. If you take a step back, out of Silicon Valley, into the land of small businesses, of bootstrappers, you'll find a Vast Valley of sustainable small- and micro-SaaS products.

Okay, so I get small SaaS — but what's a micro-SaaS? I think it was a term coined by Tyler Tringas, and it's kind of catching on in various parts of the web.

Here's how Tyler describes a micro-SaaS:

“A SaaS business targeting a niche market, run by one person or a very small team, with small costs, a narrow focus, a small but dedicated user base, and no outside funding. Hence, micro-SaaS.”

— Tyler Tringas

I'm not sure if Keygen is a "micro-SaaS" or not, but I like to think it is, and I think it fits with my own mantra for business: find a niche, prioritize profitability and sustainability, and focus in on one thing and do that one thing well.

The "one thing" part really reminds me of UNIX tools. They (mostly) try to do one thing, and they do it well. Reusable, composable, and of course, single responsibility. Staples like less, grep, cat, mv, cp, and sed.

A core tenet of the original UNIX philosophy is the idea that small, simple programs with clean interfaces can be combined to build larger systems. Rather than stuff more and more features into those programs, you make programs that are modular enough to be recombined as needed.

– CLI Guidelines

When a product does one thing well, it can become composable, just a UNIX tool.

echo 'hello, world!' > hello.txt && \
  cat hello.txt \
    | grep -i 'world' \
    | sed s/world/universe/ \
    | less
# => hello, universe!
echo 'hello, world!' > hello.txt && \
  cat hello.txt \
    | grep -i 'world' \
    | sed s/world/universe/ \
    | less
# => hello, universe!

This is also my philosophy on SaaS.

"It's a ~~UNIX system~~ micro-SaaS. I know this."

— Jurassic Park, probably

As a real life example — people ask me quite often if Keygen handles billing.

The answer to that is "no."

But not a "no, you're out of luck" kind of no, but a "here's what we do, what we focus on, and here's how you can integrate us with a payment provider."

There are so many existing tools that handle billing, and handle it well. Why do I need do handle it, too, even if indirectly? It breaks the core tenet of the UNIX philosophy.

But couldn't I just build out an out-of-the-box "integration" with say, Stripe, and call it a day? Add a simple license checkout flow using Stripe's hosted stuff?

Not really.

Over the course of the nearly 6 years since I started Keygen, I've had the opportunity of getting visibility into how various companies handle billing. From small to large. And let me tell you — they all do it differently. Especially when we're talking ISVs that have more than 10 employees, which is the market I've started to settle into.

If I were to create an official Stripe integration, or a Paddle or FastSpring integration, it'd need to be so complex and flexible that I'd end up building an entirely new product on top of my main product, just to handle the myriad of ways companies do billing, and how they initialize data within Keygen during and after the purchasing flow.

And I still wouldn't be able to support every use case.

It's just not feasible for a micro-SaaS.

It's much easier to let companies compose our SaaS with others to fulfill their unique requirements. They end up with the perfect setup, and I can do less.

Billing isn't my niche — licensing is. So there's a super simple reason Keygen doesn't handle billing: because it's not licensing.

I truly believe a lot founders try to make their products do way too much, especially when it comes to first time technical founders. I mean, I see founders adding feature after feature onto their product, some loosely related, before they even launch anything!

They end up throwing in the kitchen-sink, and they end up muddying their product offering as well as segmenting their focus, which is bad for a micro-SaaS.

Like, really, really bad.

Stay focused.

Another example of something I don't do would be complex product analytics. I do the bare-minimum for analytics, and it works for 90% of my customers. A handful of complex SQL queries and I called it a day. I mean, over half of my customers don't even use the UI — they only use the API — so I can't reasonably spend too much time here.

So the segment of customers that need better analytics go on to integrate with another SaaS, like Amplitude, or one of the hundreds of other analytics-focused products. They do their one thing, I do mine. The customer wins because they have products that focus on doing one thing well, instead of trying to do everything but nothing well.

Like Tyler mentioned in his talk, there's a reason my customers, like his at the time, are more likely to go out of business than to churn — because my micro-SaaS does one thing, and does it well. My focus isn't split on tens of sub-products all doing different things. I'm 100% focused on my one thing, so my customers can be 100% focused on their thing.

Focusing on one thing has also helped form good relationships with a lot of these billing and analytics companies, and I recommend business to them, and they recommend business to me. Businesses use us together — they compose us — to accomplish their unique business requirements.

I let my customers choose how to best handle billing. It's not my focus.

Once you start throwing in the kitchen-sink, you start competing with all the other companies that have also thrown in the kitchen-sink. You have to have feature parity to compete. And they're likely VC-backed, which is probably why they offer it in the first place. Your business enters a constant state of new product development.

As an owner of a bootstrapped SaaS, that just doesn't sound very sustainable.

You stretch yourself too thin, you'll likely fail.

So, how do you build a composable SaaS? By doing one thing.

Well, and webhooks. Lots and lots of webhooks.

Webhooks are like the | operator of SaaS.

By using webhooks, SaaS products can be wired up to talk to any number of other SaaS products, asynchronously. It's really quite amazing how pivotal webhooks have become in the infrastructure of the modern web. Webhooks are something I didn't see a lot until Stripe, but I'm sure there were others who came before.

Rather than build more and more onto my product, it's so much easier to hop on an email thread with engineering and say "here's what a webhook is, but you probably already know that, and here's how you can get your billing system to talk to our licensing system."

They go from asking if and why we don't handle billing, to being excited about composing their favorite tools together to accomplish their goals.

To wrap up — your product doesn't have to do everything. There are other products that can do the things that your product doesn't do.

Focus on one thing and you'll be surprised at how people compose your product with other products, just like the UNIX tools we love and use everyday.

Find a niche, narrow your focus, and do one thing well.

Until next time.