> I built a SaaS in a few hours

> 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.

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 Saa…

> 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 …

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.