SaaS vs code it yourself

Something pretty wild happened at the start of this year. In the space of about 30 days, roughly $2 trillion in market capitalisation evaporated from the software sector. Klaviyo down 46% year-to-date. HubSpot down over 50% from its highs. Atlassian off 35%. Salesforce dropping 28%. The press started calling it the “SaaSpocalypse” and hedge funds piled in with $24 billion in short positions against software stocks.

The narrative writes itself: AI agents can now do what these tools do. Why pay per seat when a Claude session can handle the workflow? Why subscribe to a CRM when an AI can log your customer interactions for you? The seat-based model is toast. Pack it up.

And I’ll be upfront - I’ve lived some of this. I’ve spent the last year pulling apart the SaaS stack at Reboxed, our refurbished phone business, and replacing chunks of it with code I built myself using AI tools. I’ve killed subscriptions, collapsed workflows, and saved real money. So I’m not here to defend every SaaS product on the market. A lot of them deserve to be nervous.

But here’s what I think is actually happening, and it’s less dramatic than the headlines suggest.

The SaaS selloff isn’t purely an AI story. It’s a correction story that AI gave a convenient narrative to. These stocks were wildly overinflated coming out of the pandemic-era tech boom. The median revenue multiple for software firms was sitting above 7x at the start of 2025. It’s now below 5x. That’s not AI destroying an industry - that’s a market remembering what reasonable valuations look like. The AI threat gave Wall Street a reason to reprice, but the repricing was overdue regardless.

That said, the fear isn’t entirely irrational either. There is a real structural shift happening. It’s just more nuanced than “SaaS is dead, build everything yourself.” The truth, as usual, is messier and more interesting than the hot takes. And I think I’ve got a decent perspective on it because I’ve been living on both sides of this line - killing some SaaS tools while happily continuing to pay for others.

The ones that deserved to die

Let’s start with where the narrative is right, because it absolutely is right in places.

There’s a whole category of SaaS product that I’d call “thin wrapper” tools. They do one small thing. They connect A to B. They format something. They automate a three-step process. And they charge you £30, £50, sometimes £100+ a month for the privilege.

At Reboxed, we were paying for a lot of these. Zapier was the big one. We had zaps running everywhere - connecting our inventory system to our CRM, pushing order data between platforms, triggering notifications, syncing spreadsheets. All those little automated workflows that accumulate over time until you’re spending serious money on what is essentially “if this, then that” logic.

The thing is, “if this, then that” logic is exactly what AI coding tools are brilliant at. You can describe a workflow to Claude, get a working script back, deploy it on a cheap server, and you’re done. No per-task pricing. No tier limits. No “you’ve hit your 750 tasks this month, upgrade to Pro” emails.

We systematically went through every Zapier workflow we had, rebuilt them as lightweight scripts, and shut the account down. Same with a handful of other automation tools that were doing simple data transformation or notification work. The savings weren’t life-changing on any individual tool, but add them up across a year and you’re looking at thousands of pounds that were essentially paying for convenience you no longer need.

The same was true for a bunch of internal dashboard and reporting tools. Things that pulled data from one place and displayed it in another. That’s just an API call and some frontend. AI can write that in its sleep.

The Retool story

Here’s a specific one that I think illustrates the point well.

We were using Retool as our internal operations interface. It’s a good product, genuinely. It let us build custom internal tools quickly, which was exactly what we needed when we were figuring out our workflows. I talked about this in my last piece - Retool was instrumental in our prototyping phase.

But we were paying nearly £200 a month for it. And once we’d validated our workflows and knew exactly what we needed, that £200 a month started to feel like a tax on knowledge we’d already gained.

So I built our own internal platform. Self-hosted. Our own UI, our own components, our own data layer. The hosting costs? About £20 a month. That’s a 90% reduction in cost for a tool that does exactly what we need it to do, nothing more, nothing less, and that we have complete control over.

Now - could I have done that a year earlier? Absolutely not. And this is the part the “just build it yourself” crowd conveniently ignores. I could build it because we’d already spent months understanding our operations, designing the architecture, and using Retool to prototype and validate. The SaaS product was the scaffolding. I didn’t skip it. I graduated from it.

That distinction matters a lot.

Where the narrative falls apart

Here’s where I start disagreeing with the obituary writers. Because for every Zapier workflow I replaced with a script, there are ten SaaS products in our stack that I wouldn’t dream of replacing. And the reasons are boringly practical.

Maintenance is not free. This is the one everyone underestimates. Yes, you can build a tool in two hours. But can you maintain it for two years? Every API you integrate with will change. Every dependency will need updating. Every edge case you didn’t think of will surface at the worst possible time. When you’re using a SaaS product, their engineering team handles all of that. When you build it yourself, that’s your problem now.

I’ve already had this happen with some of the scripts I wrote to replace our automation tools. An API changes its response format. A service updates its authentication flow. A webhook starts timing out. Each fix is small, but they add up. And every hour I spend debugging a homegrown integration is an hour I’m not spending on product, design, or actually growing the business.

The hidden cost is your attention. This is the real killer and nobody talks about it. As a founder, your attention is the most expensive resource you have. If you’re spending your Tuesday morning debugging a notification script because Slack changed something in their API, that’s not a win. That’s a terrible trade. You saved £40 a month and spent £400 worth of your time fixing it.

SaaS products aren’t just selling you features. They’re selling you the ability to not think about that problem. And for anything that isn’t core to your business, that’s often worth every penny.

Some things are genuinely hard. Payment processing. Email deliverability. Authentication and security. Compliance. These aren’t “thin wrapper” products. These are deep, complex, constantly evolving problem spaces with real consequences for getting them wrong. If you think you’re going to replace Stripe with a weekend of AI coding, I genuinely wish you the best of luck. You’ll need it.

The products that are safe from this wave aren’t the ones doing simple things at scale. They’re the ones doing hard things reliably. There’s a huge difference.

The framework I actually use

After a year of doing this, I’ve landed on a pretty simple mental model for deciding what to build and what to buy. It comes down to three questions.

Is it core to my operation? If the tool directly supports something that makes Reboxed different - our grading process, our inventory logic, our customer experience - I want to own it. That’s where building makes sense, because the tool needs to reflect exactly how we work, not how a generic product assumes we work. We covered this in the last article. Understanding your operation is the architecture.

Is it a thin wrapper? If the product is essentially doing simple logic - moving data from A to B, formatting things, triggering notifications - and charging a premium for it, that’s a build candidate. AI tools have made this kind of work trivially easy to replace. The maintenance burden is low because the logic is simple.

Is it solving a hard problem I don’t want to own? If the product is handling complexity that’s outside my core business - payments, email infrastructure, security, compliance - I’m happy to pay. More than happy. I actively want someone else to be responsible for PCI compliance and email deliverability. Those are not problems I need to own to build a great re-commerce business.

Most SaaS products fall clearly into one of these buckets once you actually think about it. The problem is that most founders don’t think about it. They either default to buying everything (expensive and constraining) or get swept up in the “build it all yourself” hype (expensive in ways that don’t show up on invoices).

What the SaaS companies should actually be worried about

Here’s my honest read on where this is heading.

The products in real trouble are the ones in that middle ground. Not simple enough to be obviously replaceable, but not complex enough to be obviously worth paying for. The tools that do a moderate amount of work, moderately well, for a moderate price. The ones where a founder looks at the invoice and thinks “I could probably build that” - and for the first time in history, they’re actually right.

Project management tools that are basically fancy to-do lists. Analytics dashboards that are just SQL queries with a UI. CRM systems that are glorified spreadsheets with email integration. Form builders. Survey tools. Basic scheduling software. Internal wikis.

All of these are now in the “buildable zone” for a technically capable founder with AI tools. Not all founders will bother, and not all of them should. But enough will that these companies need to be asking themselves some hard questions about what they’re really offering beyond the basic functionality.

The winners will be the ones that have built genuine network effects, deep integrations, or domain expertise that’s hard to replicate. The losers will be the ones whose entire value proposition is “we saved you from having to code this” - because that particular form of salvation is getting cheaper by the month.

My actual numbers

I’ll be transparent about this because I think specifics are more useful than vibes.

Over the last year at Reboxed, I’ve eliminated roughly £800-900 in monthly SaaS spend by building replacements. That’s mostly automation tools, internal dashboards, some reporting and notification systems, and the Retool migration. Call it £10,000 a year in savings.

The time investment to build all of that was significant. Probably 150-200 hours across the year, including maintenance. If I value my time at even a modest consulting rate, the pure economics are marginal in year one. The real payoff comes in year two and beyond, when the tools are built and the maintenance overhead drops.

But here’s the thing - I also learned an enormous amount in the process. I understand our systems more deeply than I ever would have if I was just configuring SaaS products. I can iterate on our internal tools instantly when our operation changes. I’m not waiting for a product team at some other company to decide that my feature request is worth building.

That operational agility is hard to put a number on, but it’s real. When your ops team says “can we change how this works?” and the answer is “give me an hour” instead of “I’ll submit a feature request” - that compounds.

Meanwhile, we still happily pay for Shopify, our payment processing, our email infrastructure, our customer service platform, and a handful of other products that are solving genuinely hard problems well. No plans to change that.

The actual death of SaaS is exaggerated

SaaS isn’t dying. But the bar for what justifies a SaaS subscription is rising fast, and it’s going to keep rising.

The lazy SaaS products - the ones that were essentially charging rent on basic functionality - are in trouble. And they should be. They were always overpriced for what they delivered. AI just made that obvious by giving everyone the ability to build the alternative.

But the great SaaS products, the ones solving hard problems, providing genuine infrastructure, and delivering value that would be genuinely painful and risky to replicate? They’re fine. Better than fine, probably, because the death of the lazy competitors raises the overall quality bar for what “good software” means.

For founders, the play is simple: be ruthless about auditing your stack, build the easy stuff yourself, and pay gladly for the hard stuff. Know which is which. And for the love of god, factor in your own time when you’re calculating whether “building it yourself” is actually cheaper.

The calculator never lies. But it does require you to include all the inputs, not just the ones that make for a good tweet.