A SaaS CEO pushes back.

Who owns all these little tools?

Somebody has to.

For my own tools, that’s me. In an organisation, there needs to be an accountable owner for the function, with access to the capabilities and help needed to maintain it.

What interests me is bringing responsibility and agency closer together. The person who knows the work can recognise what needs changing and has more means to act. AI can help with implementation; ownership still means deciding what should happen and checking whether it did.

I also want a more deliberate lifecycle. If a tool is useful, give it the attention it deserves. If the need has disappeared, retire it. A weekly or monthly review can ask whether something is still used, what needs attention and whether we should change or stop it.

This applies to subscriptions too. The annual payment can keep rolling long after the use has dwindled. Buying something doesn’t remove the need to decide whether it still belongs.

A personal tool doesn’t have to live forever. It can solve a problem for a while and then make a perfectly dignified exit.

Doesn’t shared engineering still make sense?

Absolutely. This is why I keep insisting on the distinction between dependable foundations and the things we build around them.

JJ Links uses Cloudflare to deliver the redirects. I want established capabilities doing the underlying work while I shape the part close to my needs. The AI assistants I work with help make that adaptation possible.

In an organisation, the same choice can involve building a small operating surface around capabilities and information already present in an established environment. People can adapt how they work without personally recreating the whole stack.

That leaves responsibilities on both sides. The provider has to keep supplying a capability worth depending on. The person running the personal layer has to understand enough about its dependencies and upkeep to make a sensible choice.

The boundary matters more to my argument than whether a particular thing arrives through a subscription, an open-source project or an AI-assisted build. I’m happy to pay for the foundation. I want more freedom over what I do with it.

Are you actually saving anything?

We need to count more than the subscription.

The $384 is money I can stop spending on Rebrandly. Hosting, domains, my existing AI tools and the time I spend making and maintaining the replacement still matter. If those costs outweigh the benefit, keeping the service can be the better choice.

But the benefit includes how well the tool fits my work, the effort each use takes and what I can now change. A service’s price doesn’t capture all the work around using it either.

In the exchange, I recalled a capability I’d valued being removed from a product. I reckon I spent more time trying to persuade the supplier to restore it than I later spent making an equivalent for myself.

Waiting, arguing for a need and adapting to somebody else’s decisions all consume time. They belong on the buy side of build versus buy.

Then there’s learning. Some of the time spent understanding a new capability is an investment I want to make. In the Four Jobs, that’s Job 3: improving myself. An hour of learning isn’t automatically an hour wasted because I could have delegated the task.

And yes, I enjoy making things. I don’t need to pretend the pleasure has no value until I can invoice it. The point is to understand what I’m getting from the time, including when the answer is simply that I had a good time learning something.

None of that makes every build a good idea. It makes the comparison more complete.

Have you become your own software supplier?

The CEO’s challenge also raised the work of understanding a market and developing a service over time. That’s real work for a vendor serving many customers.

My starting point is much smaller. I can look at my own need and judge whether a solution meets it.

A market of one is allowed to be very specific.

If someone else finds the result useful, I can make it reusable without automatically taking on a commercial roadmap or permanent support. Explain what’s offered, make the dependencies and limits understandable, and let people decide.

I’m interested in what happens when more people can make those choices. The supplier keeps the advantages of shared resources and expertise. The customer gains another option. Both now have to earn their place in an honest comparison.

I’m glad the CEO asked. I’d rather develop the argument with someone who understands what makes SaaS useful than win an easy argument against a version nobody actually believes.

What happened. What I think follows.

Observed: A private exchange raised the maintenance and total-cost objection. This essay recasts its questions and develops my replies, with the company and correspondent anonymised. The public JJ Links edition and its dependencies can be inspected.

My assessment: Ownership, fit, learning, enjoyment and supplier friction belong alongside subscription fees and upkeep. My removed-feature example is a recollection, not a timed comparison.

My inference: Some people can sensibly combine shared infrastructure with a small layer they control, rather than buy an entire packaged application for that layer.

My forecast: More suppliers will have to compete with their customers’ ability to assemble a suitable alternative.

Still open: When the full cost favours building, buying or combining them; how much maintenance people will accept; and which capabilities remain best shared. Lifecycle reviews here are a practice I’m advocating, not a claim that my tools maintain and retire themselves.