The Future Won't have a Dashboard
In early February, $285 billion was wiped from software stocks in 48 hours. Jefferies called it the "SaaSpocalypse." The narrative everywhere is the same: AI and vibe coding will kill SaaS. Anyone can build software now, so why pay for it?
I've been thinking about this a lot. At Smudge, our Mission is to enable people to thrive by delivering pragmatic technology solutions to operational business problems, so you'd think I'd be cheering. If everyone believes they can replace their SaaS subscriptions with custom-built tools, that should be great for us, right?
Not quite. Because this current conversation is missing the point entirely.
Yes, building software is getting easier, that's not the hard part
I don't want to dismiss how much has changed, the barriers to creating a working piece of software have dropped dramatically. I'm a big fan of Warp and use it for a lot of programming and writing, including this article. I've got personal tools that I've developed for my own use, that in the past would have taken me a few days when I was at my peak in a particular toolset, that I can now do in a few hours.
And yes, there are genuine technical challenges in building software - security, performance, scaling, integration. These are real. But they're not what trips most people up.
The hard part has always been deciding what to make.
The real difficulty is the freedom to make anything you want
When you can build anything, you have to choose what to build. And more importantly, you have to know when to stop.
I see this in our own work constantly. The most difficult conversations we have with organisations aren't about what's technically possible. They're about scope. What problems are we actually trying to solve? What does good enough look like? When do we stop adding features and ship something people can use? Just because we can, doesn’t mean we should.
Those questions don't get easier when the tools get faster. If anything, they get harder. When adding a feature takes a weekend instead of a month, there's less friction to stop you from building things nobody asked for. The constraint of effort used to be a natural filter. Remove that filter, and you need a lot more discipline.
Software for one, versus software for many
If you're making software for yourself — a personal tool, a side project, something that only you will use, that's relatively straightforward. You know your own needs. You can change things whenever you like. If it's a bit rough around the edges, that's fine, because you're the only one using it.
But organisational software is a different challenge entirely. You're not building for one person. You're creating a single, shared experience that many people need to understand and use consistently.
Can you imagine a workplace where everyone has vibe coded their own version of the same tool? "Jake, how do I create an order?" "Oh, just use the button in the top right." Meanwhile, Sarah's button is in the bottom left, and Tom's version uses a completely different workflow. That doesn't work. You can't onboard new staff into a system that's different for every person. You can't troubleshoot issues when no two people are looking at the same screen. Shared software needs shared understanding, and that takes design thinking, not just code generation.
This is the distinction the current narrative glosses over. There's a world of difference between writing software that works for you and designing software that works for an entire organisation.
We're assuming software will look like it does today
Much of the SaaS panic is based on the idea that people will build their own versions of existing tools. This assumes the interfaces we're used to — dashboards, forms, lists, buttons, are how we'll always interact with software. However I’m not sure this is accurate.
When the iPhone launched in 2007, no one predicted all the ways it would be used. We're at a similar point now. We don't yet know how many use cases will shift to voice, or to AI agents acting on our behalf, or to interfaces that don't look like software at all.
What we do know is that having quality APIs into data that you own gives you flexibility and choice. It means you're not locked into one way of doing things. You can build an interface that suits your context, whether that's a traditional screen, a voice interaction, or something we haven't yet imagined.
The value might not be in the application layer at all. It might be in your data, your workflows, and the connections between them. If that's the case, the question isn't whether you should build or buy software; it's whether you own your data and have the flexibility to access it in whatever way makes sense tomorrow.
There are real reasons to build your own software
I want to provide a balanced view to the instinct behind the SaaS backlash, because some of it is valid. There are genuine reasons organisations choose to build rather than buy:
- You're in charge of your own destiny. You can make changes when you need to, at the pace your organisation requires, without waiting for a vendor's roadmap.
- You're not at risk of a software manufacturer going in a direction that doesn't suit your needs. I've seen this happen many times — a product that works well for a business gets acquired, pivoted, or sunsetted, and the customer is left scrambling.
- And sometimes it's not about replacing an entire platform. It might be a small integration, or a specific workflow that's unique to your organisation, that you build as part of a larger solution using a mix of custom software and off-the-shelf tools. Some of our best projects at Smudge have been exactly this — a targeted piece of custom software that sits alongside a business's existing platforms and fills a gap that no off-the-shelf product quite covers.
There's room for both
I think there is plenty of room for off-the-shelf software, on-demand tools, and custom-built solutions. This isn't an either/or situation. The best outcomes I've seen often come from organisations that use established platforms where they make sense, and build custom where they have genuinely unique needs.
What's changing is that modern interfaces and AI tools are available to everyone — both the teams building off-the-shelf products and the teams building custom solutions. The playing field is more level than it's ever been. That's exciting. But it also means off-the-shelf products will get better too. The same AI tools that let you prototype an app over a weekend are being used by SaaS companies to improve their products faster than ever.
The fundamentals haven't changed:
- You still need to understand the problem you're solving.
- You still need to design for the people who will use the software.
- You still need to know when a tool is good enough, or when it needs more work.
AI makes building faster. It doesn't make deciding any easier. And deciding - what to build, who it's for, when to stop - that's where the real work is, has always been, and always will be.