Hacker News Reader

> Most of the effort in software goes into understand people other than you and building guardrails for them.

100%, which is why I think hyper-tailored, small software is an exciting option. When you shift your goal to serve 1000 customers, the hardest part is not having a tech stack that supports them, but making sure the software is good enough for all their different needs. Or you try to meet them all and you get into feature creep.

> For businesses, the buy vs. build tradeoff does now have some new compelling evidence in favour of "buy" but there's still maintenance needed for the service internally

What if you neither buy or build the software but buy the service outcome?

A data analyst that creates custom workflows with auto-generated dashboards. A dev-ops that provides access with exactly the information you need, depending on the hand-off level you want for the process.

My point is that a lot of these micro tools that started to appear the last few years will vanish, either bundled with bigger SAAS, internalized, or shifted to a service offering. This trend started with productized services, this is the next step.

> SaaS is far from dead.

Micro SAAS*. I agree with all your points, but I do believe the small software landscape will change drastically in the coming years

This is just the old argument in favour of SaaS, though. The article is pointing out that those long-standing rules may no longer make sense, in a world where 1. it no longer takes even a weekend to build the niche, perfectly custom tool and 2. the maintenance / feature requests side is also just a prompt away.

At my job (we're somewhere in the transition between startup -> enterprise), we still use a lot of SaaS and are continuing to do so, but even there we're starting to move off certain platforms (Pendo, is a recent casualty) as we've realized in many cases we can just build it ourselves, pay drastically less, and actually get to control how it all works.

My suspicion, though I could be wrong: SaaS will move more and more towards focusing solely on the enterprise. Personal users and startups will have a harder time justifying both the cost and lack of flexibility of pure software SaaS. Enterprise will continue to be ok with paying the costs in exchange for compliance and vendor stuff and integration and whatever else they care about.

I think small, ma and pa businesses who don't know anything about software engineering will still need support.

> those long-standing rules may no longer make sense, in a world where 1. it no longer takes even a weekend to build the niche, perfectly custom tool and 2. the maintenance / feature requests side is also just a prompt away.

…as are your own, perfectly custom security vulnerabilities and their successful exploitations.

Even if maintainance is just a Claude/ChatGPT session away we know that the cost of that session could be 1-2 hours of attention going to a supporting tool. And what if suddently is down? now your software team is having an incident about an in house tool instead if an incident about your paying customers.

Moreso while a custom build software just for you is a great fit for your own processes you are loosing innovation and what you could benefit from using a software where someone is trying to innovate and bring out better things that you might not know even to ask for in a prompt as that is not your own domain of expertise or better said you are too expert in your own process that you cannot see what else is out there. And to overcome this you have to try to put in resources for this tool.

For businesses that build software (which is more than you'd think, as this includes the entire financial sector), building vs. buying has an entirely new scale.

At work, which I won't say where, we replaced a few SaaS we were using with in-house software. We largely have a culture of in-house software so it made sense. These were not small tools. They were behemoths created by multi-billion dollar software houses. And we replaced them, entirely, in the span of weeks. The reason it worked is we already had many domain experts in those tools.

The advantages don't stop at "money". The biggest advantage is complete control. We can integrate across our other tools, for free. We can add whatever features we want.

> It's easy to build something for yourself that solves your own use case. You know how you work and what's important to you. Most of the effort in software goes into understand people other than you and building guardrails for them.

Fully agreed. It's also just a time saver. People are lazy, and I don't mean that in a bad way, just that people don't really want to sit there and explain to an agent exactly what they want software to function like. In fact, most people don't even actually know what they want software to function like.

It doesn't just stop at humans either. When I recently started creating my smart budgeting app, Claude pointed me to use Clerk for auth. So not even the AI wants to build everything from scratch.

To be fair to Claude on the Clerk thing, I had my agent build session management and auth from scratch, then beefed it up with all the best practice advice, and and and.

It took me an extra day of agent-prodding and code review.

And I still will have to add SSO and Google/whoever sign-in and passkeys and 2FA at some point.

Using Clerk would've avoided that, but at a permanent cost of one more dependency.