The SaaS Zoo

As I mentioned in the previous articles, AI-assisted coding finally opened my folder of ideas, and now our small team runs several projects at once. Today I want to describe a problem that showed up right after that. I think every founder knows it, even one with a single project.

I call it the SaaS zoo.

One founder, many processes

A startup is not only a product. Around the product there is a whole set of processes that have to run every day: outreach, content, social media, support, analytics, email campaigns, and the list goes on. None of them is optional. You can skip any of them for a week, but not for a quarter.

For every one of these processes there is a SaaS service. Usually not one but dozens. And here is where I found myself:

• —Some services fit you better, some worse. Every tool is designed for an “average” company, and you are not an average company. So you adapt your process to the tool, not the other way around. Sometimes it’s a small compromise; sometimes you fight the tool every day.
• —Even the good ones need managing. Every service is another tab, another login, another dashboard, another stream of notifications. Even when everything works, you spend your morning walking through the zoo: checking this, exporting that, copying numbers from one place to another. The tools work, and you are the integration.
• —Cheap plans are cheap only one at a time. $15 here, $29 there, $49 for that one. Each looks harmless. Together they add up to hundreds of dollars a month. And when you run several projects, some services have to be paid per project. The math gets unpleasant fast.

For years I considered this a normal cost of doing business. You can’t build your own outreach tool, your own scheduler and your own support desk; each of those would be a separate startup. So you pay, you adapt, and you jump between tabs.

You already know where this is going.

So I built my own

At some point I asked myself a simple question: what exactly do I need from all these services? Not what they offer, but what I actually use. The honest answer was maybe 20 percent of each. A specific outreach flow. A specific way to prepare and publish content. A specific set of metrics from all projects on one screen. A simple support inbox.

So I described all of this to AI, piece by piece, and built my own internal tool.

It took about a month, and I keep improving it all the time (believe me, the first version was far from beautiful). Now it runs these processes for all my projects in one place, the way I need them. Not the way a product manager at some SaaS company imagined an average customer, but my way. One screen in the morning instead of ten tabs. One logic for all projects instead of a separate setup in every service.

And my favorite part: I built it once, and it works for every project. When we launch the next product, I don’t buy another set of subscriptions or configure another zoo. The new project simply appears next to the others.

The honest math

The savings come to around $500 a month. For a corporation, that’s nothing. For a startup, especially for several bootstrapped projects, it’s a real number.

But “I saved $500 a month” is only half the story, so let me be honest:

• —My time was not free. A month of building is a real cost. If your alternative is one $29 subscription, building your own tool makes no sense.
• —SaaS exists for a reason. Reliability, support, updates, security: a serious service does many things my tool doesn’t. For critical infrastructure like payments, hosting, or anything where a failure costs you customers, I still buy rather than build.
• —This tool fits my processes. It fits me perfectly precisely because it was built for me. It probably wouldn’t fit you, and that’s exactly the point.

So the real value isn’t even the $500. The real value is that, for the first time, my processes are organized the way I think, not the way twelve different companies think. That feeling is hard to put into a spreadsheet.

The bigger picture

There is a classic rule in our industry: build or buy. For a small team, the answer for internal tools was always “buy.” Building was a luxury for companies with spare engineers.

I’d say AI quietly broke this rule. Not for everything, but for internal tools the equation has changed. A non-technical founder can now sit down and, in a few weeks, build the exact tool the business needs instead of renting ten approximate ones. Five years ago, that sentence would have sounded like a joke.

I’m not telling you to cancel all your subscriptions tomorrow. I’m suggesting the exercise I did: look at your zoo and ask what you actually use from each service. If the answer is “20 percent, and I fight with the rest,” maybe it’s time to describe your perfect tool to AI and see what happens.

I’ll keep sharing what we build and how we bring it to market. The zoo, meanwhile, keeps getting smaller.