Garrick van Buren

The SaaSpocalypse wasn’t caused by AI, but it will be perpetuated by AI.

The narrative is: AI arrived. Revenue stalled. Therefore customers are buying fewer seats because they’re implementing AI.

$300B in market value evaporates.

The narrative has reached the capital markets too. Last quarter, Blue Owl investors requested return of $5.4 billion across two private credit funds, redemption rates of 40.7% and 21.9% respectively. KKR, Apollo, BlackRock followed by invoking their 5%/quarter withdrawal gates. Blue Owl attributed the pressure to “heightened market concerns around AI-related disruption to software companies.”

It’s a vivid and compelling narrative serving everyone involved and is mostly wrong.

Businesses across industries stopped growing headcount three years ago. Here’s the seasonally adjusted, non-farm job openings & hires against interest rates since 2000.

---

Narrative fallacy (Taleb): the mind’s compulsion to construct causal stories from loosely related events. Strongest under uncertainty, when a vivid explanation is unavailable and the actual cause is diffuse and banal.

Post hoc ergo propter hoc: e.g. “after this, therefore because of this.” It is the fallacy underlying most financial news narratives (“stocks rose on news that…”), most earnings call explanations, and apparently most SaaSpocalypse postmortems.

---

The non-farm hire rate peaked in early 2022 at the top of the post-COVID snap-back. Then it has steadily, continuously, fallen for three years. In February 2026 it sat at 3.1, nearing the lows of the 2008 financial crisis. This decline was well underway before Claude Code existed (Feb 2025) and before Klarna made headlines ditching Salesforce (Sep 2024).

Recently Fast Company posited SaaSpocalypse a myth, arguing enterprise software is so engrained in thei too deeply to be replaced by general-purpose agents.

The question is not whether AI can replace Salesforce with a homegrown solution because it’s too operationally ensconced.

The question is whether the companies running Salesforce are growing their human sales force and purchasing more seat licenses. The JOLTS data suggests they’re not – and haven’t for nearly 4 years.

Seat-based SaaS revenue is a function of customer headcount. When your customers stop hiring, they also stop buying the follow-on tools and amenities supporting the new employees. Office chairs, laptops, Office365 licenses, etc.

Unfortunately it’s seats that are ensconced. Seats are in the revenue forecast, in the sales quotas, in the board expectations, in the investor guidance. The entire operating system of a enterprise SaaS business is calibrated to a number the company does not control and never did: its customers’ hiring plans.

When hiring grew reliably through the 2010s, this tension was invisible. Seat expansion looked like product-market fit. It was, in part, just a rising labor market expressing itself through software licenses.

Headcount go up?

Many SaaS companies are now pivoting to outcome-based or consumption-based pricing (this was all my 2025 client work). Both models realign pricing with customers’ economics rather than their headcount. A dollar of ARR anchored to customer economics is more durable than a dollar of ARR anchored to a seat count in a contracting labor market. ARR still matters.

This is not a new.

Probably have been this way all along.

The headcount shrinkage has already happened.

Tech layoffs tracked by layoffs.fyi peaked at 264,000 in 2023, then decelerated: 153,000 in 2024, 124,000 in 2025, 41,000 so far in 2026. The acute phase is largely over. As you can see from the graph above, hiring has not rebounded across sectors. What remains is structurally lower hiring floor, because the companies doing the laying off stopped backfilling. Low-fire, low-hire, and no new seat licenses.

Suggesting the Saaspocalypse isn’t today, or in 2026, it’s forward-looking. Not because the SaaS companies have poor fundamentals or shrinking margins, but because their customers, and the US economy overall, stopped growing jobs.

My bet is not that “AI will disrupt SaaS”. My bet, is “companies will get smaller”.

Fewer employees than yesterday.

Quarter after quarter.

Moving forward, yes, some part we can blame on the productivity enhancements of AI. Hell, I’m planning to leverage AI in my business as much as I can ahead of hiring a person.

But, $300B in market value in 2025? No. AI is not that good yet.

1. Try
2. Instructions
3. Safety

The B2B zeitgeist is asserting trust is at an all-time low.

Buyers don’t trust vendors.
Buyers don’t trust marketing.
Buyers don’t trust new anything.

I think it’s a convenient misdiagnosis benefiting everyone.

The “trust crisis” puts the burden on sellers — just build more credibility, just produce more case studies, nurture longer, be more transparent.

An entire colony of sales trainers, advisors, and marketing consultants has organized itself around helping sellers navigate this dearth of buyer trust. If you just get your approach every more perfect, the deals will close.

It reminds me of the résumé optimizers promising jobseekers more interviews if they just tweak the formatting, strengthen the action verbs, optimize for keywords. All seller-side technique applied to a buyer-side disengagement. The hiring side isn’t. No amount of résumé polish changes the fact there’s a hiring freeze even though the job description is still up.

Exact same dynamic.

The buying side just isn’t.

The majority of deals I’ve lost over the past two years haven’t been lost to a competitor. They haven’t been lost on price or credibility. They’ve been lost to: “Nah, we’ve decided not to do this at all.”

Maintaining the status quo isn’t saying “I don’t trust you”, it’s saying “We don’t actually have capacity for this” or “Turns out, we don’t think doing this will be worth it.”

For one company I talked with, it wasn’t lack of budget, nor credibility concerns on my part. It was lack of strategic alignment within their departmental leadership.

A professional services firm wants 30% growth this year but is too busy delivering (awesome!) to draw a strategic roadmap to the goal. No board politics. No bureaucratic layers. The leadership is the decision-maker.

That’s not a trust gap. It’s lack of strategic bandwidth.

Working in the business vs. Working in the business

“Uncertainty” and “Volatility” are often the next scapegoats.

Yes, conditions might change dramatically in the next 90 days. This has been true for the past 5 years, 10 years, 25 years, but every year prior. I had a project back in 2018 around trying to navigate geopolitical uncertainty. CNN’s 24-hour headline news has existed since 1980 and every new headline is terrifying. But at a 12-18 months horizon, it quickly becomes irrelevant noise.

In 2025, U.S. business investment grew nearly 6%, heavily concentrated in data centers and IT infrastructure. According to Harvard economist Jason Furman, excluding those categories, GDP grew at 0.1% annualized in the first half of 2025. Not a typo. Zero point one percent.

“Our economy might just be three AI data centers in a trench coat.” – Rusty Foster

It looks that way because no one else is doing anything.

For, it’s not that AI responses are highly trustworthy. Claude, Gemini, ChatGPT all have warnings about their lack of trustworthiness (“Claude is AI and can make mistakes. Please double-check responses.“). If trust were actually the concern, AI — the least proven, most hallucination-prone, lowest-quality-output category in B2B — would be the last thing getting funded. Instead it’s the first. An MIT study of 300 generative AI initiatives found 95% delivered zero measurable return on $30-40 billion in investment.

Last year, each of my engagements was three weeks from initial call to kickoff. The difference wasn’t trustworthiness. It was whether leadership had a specific, unavoidable, urgent, project. No amount of effort on my part could manufacture it if they didn’t.

• GDP growth of 0.1% outside data centers.
• 86% of B2B buying journeys stalling before a decision.
• Buying committees doubling in size.
• 95% of AI initiatives delivering zero return.

None of this is a trust problem.
All of it is a leadership problem.

In 2025, a record 234 CEOs were swapped out — up 16% year-over-year. Tenures less than 36 months increased 79% year-over-year. A CEO who knows they have 30 months before the board reconsiders them isn’t going to invest in a bold 36 month bet.

Thus the strategic vacuum perpetuates itself.

• A customer
• An offer
• A way to take payment

The rest you can pick up along the way.

LLMs will become small enough and cheap enough and most computers powerful enough that they’ll be readily and easily embedded into most software. General purpose LLM providers – OpenAI, Anthropic, etc – will largely exist as research organizations. On a day-to-day basis we’ll interact with LLMs more, but they’ll be run & maintained by the same companies that maintain the software wrapped around the LLMs. LLMs will be invisible,

[In collaboration with Ivan Stegic]

“Context is that which is scarce” – Tyler Cowen

Product companies have an allegiance to the product. 

Service companies have an allegiance to the customer.

Both are legitimate vows. 

Both, unexamined, become traps.

The coastline paradox — the more accurately you measure the coastline, the longer it grows — is the most precise metaphor for this trap.

The closer you get to matching your offering to your customer’s precise shape, the more shape there is to trace. It never bottoms out. Their coastline is infinite.

Too often product leaders are hesitant to even lower their elevation claiming ‘it doesn’t scale’ – despite the competitive advantage waiting in the details.

The customer faces the same question from the other side. 

Before choosing a vendor, someone at the customer has to decide:

Do we want to invest our competitive advantage in this JobToBeDone?

• If yes – let’s get a tailored-fit solution to start and consider building out an internal team.
• If no, we’ll adapt to the undifferentiated product and focus time, energy, and budget elsewhere.

The customer who chooses a product company isn’t settling. They’re making a deliberate choice not to compete on CRM, project management, email clients, calendaring, document management, accounting, or hosting. The customer choosing a service company is betting a custom solution will serve them better. Both are allegiances to a strategic outcome for their organization.

---

Let’s imagine a customer’s organization as terrain as dramatic as mountainsides and fjords. 

A product company operates at elevation, let’s call it satellite view; coastlines are visible, yet smallest inlets untraced. The higher the elevation, the more customers fit, but only in the most abstract manner. Despite the abstraction, the edges of the product are firm, which makes on-the-ground implementation awkward. Accommodations within the organization will need to be made and the pricing reflects the mismatch. 

A service company descends, and gets closer to the customer’s actual shape from the beginning. The promise: we will tailor to you, as perfectly as your budget will support. Higher price, because every engagement, every organization is unique, and little can be repurposed elsewhere.. 

The trap isn’t in which model is chosen, it’s in unexamined drift away.

---

Product companies don’t decide to become service companies. They inadvertently drift there, one big logo at a time. First, the product gets built for one prestigious customer’s inlets. Eighteen months later it perfectly fits this one customer and everyone else with increasing awkwardness..The portfolio quietly churns.

Service companies fall into the mirror image. The stated allegiance is to the customer — but the actual allegiance, in practice, is to the ongoing relationship. They seem identical until the desired outcome is achieved. Then they diverge.

Allegiance to the relationship says: Stay, find more to do, trace more coastline.

Allegiance to the outcome says: You’re done. Leave.

Consultant: noun, someone who comes in to fix a problem but ends up becoming part of it.

The service company’s trap is confusing being needed with being effective.

---

There’s a third allegiance, and it’s the one worth keeping: allegiance to the outcome.

For the product company, it’s answering every anchor customer request with a simple question: Does this serve the outcome we promised the portfolio, or just this one? 

For the service company, it holds the line against indefinite engagement. The practitioner who leaves when the work is done is being faithful to the outcome, not disloyal to the relationship.

Both take discipline.

The competitive advantage for a product company lives in controlled descent, going just a little deeper into the customers’ shape than the competitors; dedicated Customer Success, dedicated account executives, custom onboarding, custom implementation. Deliberately priced. 

The danger is reactive descent, subletting office space from the customer.

Back in the 1900s when I was in 4th grade, the teacher gave us an exercise: Successfully get a robot to sharpen a pencil.

Now this was public school in rural Wisconsin, we didn’t have robots. What we did have was other 4th graders. So, once you hand wrote out your instructions and handed them to the teacher, a fellow student randomly selected a set of instructions and executed them.

Perfectly to the letter.

To inevitable failure and laughter from the entire class.

For even at 9 years old, we make assumptions about the important parts of a task, and we leave out substantial context; either because we don’t appreciate it or we take it for granted.

For the past 4 years, I’ve been managing DÉJÀ BRÜ via WordPress, WooCommerce, a Trello board, and a series of Google Sheets. It’s a small competition, so it works well enough. But this year, the fragmentation got to me, so two days after the competition was over I opened up Claude and started vibe-coding a homebrew competition management app.

Since Claude Code starts a $20/month, I just started with the chatbot, and had it generate a shell script to generate the app, then about half way through the week, I paid the $20 and it sped things up considerably.

But let’s set the full context.

Between 2000-2010, I taught myself PHP, MySQL, Ruby, Rails, and Javascript. I had a shelf of books covering all 5. If you dig back into this blog, you’ll find loads of posts from that era.

However in the intervening years, I’ve done little programming either for myself or others. Turns out, even maintaining a development environment takes deliberate effort. I grew tired of chasing the latest hotness (e.g. Node.js). I grew weary of managing server up-time and fixing bugs. So I stopped.

Then, in fall of 2021, I got an idea for an app to help me organize my genealogy research, so I dusted off my Rails skills and started building. When I completed the research project, I turned the app off and haven’t visited it since.

So, it’s been 5 years since I’ve used any software I’ve written and at least a decade since anyone else has.

Seems like it might be time.

As of this writing, I’ve spent $20 and Claude Code has helped me with 3 apps.

• A homebrew competition management app (~12hrs, from scratch, currently deployed on a test server)
• A homebrew recipe management app (~6hrs; from scratch, currently migrating my recipes into it, still local)
• The aforementioned genealogy research app (~3hrs; updating to Rails 8, and adding mapping, still local)

And that’s just been in the last week.

I’m absolutely left with the sense that vibe-coding is a misnomer, it’s more like technical writing, more like clearly articulating how to sharpen a pencil to a 4th grader.

Here’s my initial prompt for the competition management app:

create a ruby on rails app for beer judging.
2-3 judges per flight of 5-6 entries. homebrew competition, bjcp-sanctioned, but arbitrary styles could be select, from full BJCP to just a single historic style not recognized by the BJCP. actors: judges, entrants, stewards, organizer roles; cellar, judge coordinator, event coordinator, admin. entrants submit their own entries, some competitions may be paid, others may be free entrants get downloadable scoresheet PDF, publicly available leaderboard. devise for auth, unless Google OAuth would be easier. payment via Paypal. full rails with views. probably Heroku for deployment. the minimum I'd like; entrants enter beers, judges can register, organizer and assign beers to categories, organizer + judge coordinator can assign judges to flights while avoiding any potential entry conflicts, judges can evaluate a beer, entrants can see evaluation within their account.

As you can see, I had some requirements.

Now, there have been a few pleasant surprises at what Claude implements outside of my request (feature or bug?), and those suggestions usually force me to really consider what I want and how I want it to work. I find Claude’s code is readable and I’m comfortable making edits to it.

I tried Cursor for one of these vibe-coding sessions and found that while the code was somewhat higher quality (more readable, more concise), Cursor was a far worse business analyst, asking fewer clarifying questions, stubbing out worse features unprompted.

By the time Weekend Update started on Saturday night, I had deployed the homebrew competition management app to a test server and shared a link with my co-organizers. However, that in itself took 3 hrs – which is well within my past estimates of deployment taking 50% of the development time to date.

In the end, the primary reasons I hadn’t committed to building any of this software before: opportunity cost.

Why build custom software if Google Sheets works?

Why build custom software if stable, maintained, equivalents exist for $30/year.

I’m not sure that having an expert Rails developer at my fingertips for $20/mn substantially changes that. If anything, all this highlights is that writing the software was never the hard part – having an incentive to maintain it is.

And none of these 3 apps yet have that.

To this point, when I asked Claude to:

help me create a shell script to generate a ruby on rails app for managing homebrew beer, mead, and cider recipes

It’s initial response was:

Before diving into script generation, a few probing questions to make sure this is actually worth building right:

What's the actual gap? Brewfather, Beersmith, and Brewtarget already exist. What do they not do for you?

What's the scope? "Managing recipes" is vague. Are you tracking ingredients, fermentation logs, batch history, tasting notes, calculated ABV/IBU/SRM, scaling, something else?

Who's using this? Just you locally, or are you thinking multi-user, hosted, shared recipes?

Why Rails specifically? For a personal recipe manager, Rails might be overkill. Have you considered the tradeoff vs. a simpler tool?

Even Claude itself is aware of opportunity cost and was comfortable discouraging me right from the start. Not a bad thing to start with, “hey, have you actually tried the existing options?”

I have, and are my preferences worth the trade-offs? Unlikely. But here we go!

And now I’ve hit my rate limits without even knowing what they are, and it looks like they won’t reset for 4-5 days. Jeebus. These tools are highly unstable. More and more like the toy giraffe I evoked a year ago, the more you engage with them, the worse they are.

After being rate-limited on Claude yesterday, I did the next obvious thing and loaded up GitHub CoPilot, paid $10 to keep going. Quality seems just as good – if not slightly better, as CoPilot actually cares about specs and tests.

Update March 7: I canceled my Claude subscription. After sitting rate-limited for a work week, and pondering how much that was like waiting for scheduled computer time back in the 1900s, I had a list of things I wanted Claude’s help with, and for each thing the responses were so mid, and immediately hit rate-limiting again as I rebuilt context. I’ve kept the GitHub CoPilot subscription for the time being.

Update Mar 11: Wow. Claude is barely usable at this point. Between losing context and rate-limiting, the novelty of having a digital copilot has waned. It’s hard to imagine what would need to change for me to re-up for Claude.

TLDR; Investor-focused accelerator programs no longer serve founders or investors.

Over the past 6 months, I’ve been hired by two different pre-seed accelerator programs to look at founder outcomes and make recommendations for improvements. In total I talked with 25 founders (growing, pivoting, sustaining and shuttered) and a handful of early stage investors, and I reviewed the current status of portfolio companies going back a decade.

In both, I found the same systematic mismatches between what founders need, what investors want, and what programs actually teach. But, this post isn’t about picking on these specific programs.

Over the years, I’ve been directly involved with a half a dozen accelerator programs and advised nearly 100 early stage founders. All of these programs were modeled off the playbook YCombinator drafted twenty years ago; select 12 promising startup teams, run a 12-week batch, provide mentor networks, teach founders to pitch investors, culminate in Demo Day, hope everyone gets follow on investment. All in exchange for 7% of your company.

Today, similar programs exist in every mid-sized city from Minneapolis to Columbus to Oklahoma City to Mobile to Appleton. Some programs are no equity, some are fully remote, some run 6 months or a year, but they all have the same key characteristics and they’re all investor focused.

But, the seed stage investor appetite has shifted pretty hard since 2022. Investors stopped attending Demo Days and programs have pivoted to “showcase events” open to the general public. More honest for sure, but a quiet admission a core value proposition of the program has evaporated.

“Founders need to talk to customers” & “Founders need to run napkin math.” – Investors that want solid fundamentals.

Founders across these programs were expecting continuous introductions to investors, and in general – they didn’t arrive. Perhaps because the investors still interested seed stage companies are looking for the fundamentals; early revenue, sales velocity, and unit economics – and the program managers knew it was too early.

“It took us a year after program to get the company ready for investment.” – One founder still surprised at the gap.

Yet, accelerators are still focused on pitching. I talked with two dozen founders, each winning numerous pitch competitions yet struggling to get a single customer sale.

This last point aligns with the most consistent regret I heard from founders – successful & unsuccessful, “I didn’t talk to enough customers.”

The cause:

• not knowing how to define their customer,
• not knowing how to find them once defined, and
• not knowing how to have a customer discovery conversation with them once they did.

A program that’s focused on the things today’s investors want, would look very different. No Demo Day, no pitching, no mentors. 100% customer pipeline-focused, napkin math-focused, early sales-focused.

Progress on these things will serve founders whether they pursue outside funding or not, and they’ll be a much stronger signal to potential investors in any market.

Cyberstarts.com is a potential model; tightly focused domain (cybersecurity only), pre-existing network of executive buyers (60 CISOs), rolling admissions.

Regional programs have geographic customer advantages in something – manufacturing, agriculture, healthcare, mining, aerospace. Build buyer networks in these domains. Connect founders to the five local mid-size customers they need to build sustainable businesses – and teach them how to develop those long-term, win-win relationships.

Claude and I talk regularly.

I’ve reached the end of multiple context windows with Claude.

I credit Claude with helping me articulate the long running thread through my career and personal interests (e.g “Find what we forgot”) and clarifying the current positioning of my business (e.g. “When technology breaks your revenue model – call me.”). Once every couple of days I’ll paste an email draft into Claude and say, “I’m having a difficult time saying what I’d like to say succinctly.” and I’ll often take the suggestions.

Additionally, I have a long running chat in Gemini where it scores and ranks companies I offer it against the characteristics of my best clients.

I have the same 4,000 characters of instructions in both Gemini and Claude.

I don’t use ChatGPT anymore.

I would characterize my current usage as:

• Rubber ducking
• Summarizing qualitative patterns
• English-to-English translations
• Ensuring I’m being comprehensive / appreciating conventional wisdom.
• Raising the minimum quality of communication

Overall, I’d characterize this as “Help me minimize common mistakes”. Claude calls it “Sharpening“.

The more I work with Claude, the more it feels like the Mirror of Erised, simply reflecting back whatever you give it in a more narcissistic package.

There’s still nothing new here and I’m still of the position that “AI is amazing about the thing I know nothing about….but it’s absolute garbage at the stuff I’m expert in.”

An Increasingly Worse Response

I don’t pay for Claude, which is to me is a sign it’s not yet become an indispensable co-worker. The reports I’ve read of Claude CoWork and other ‘agentic assistants’ mainly make me wonder why the human operator even bothered with automating the task in the first place.

The greatest value of CoPilot and Claude Code seem to lay in an assumption that all software must start from scratch in Node. As soon as you say, maybe I don’t need to start from scratch, suddenly an entire world of options opens up. Admittedly, they’re not distinct applications that can be discretely monetized. On the flip side, someone else is maintaining the system, has already fixed and squashed thousands bugs you’ve yet to even experience.

But creating software hasn’t been hard for more than 25 years. There have always been piles of frameworks and environments to accelerate the creation of software; Hypercard, VisualBasic, Ruby on Rails, WordPress, etc, etc.

The challenge is in maintaining it, hardening it, justifying why it should continue to exist – that’s the perennial problem.

And that’s the first question I ask, should we create this custom software at all? Or perhaps we frame the problem differently and solve it in a different way altogether; we can minimize our overall maintenance costs while still getting the same output…or completely eliminate problem.

You’re Not Going to Need It

Recently I upgraded all my Google Homes to Gemini…and now the voice is even more tediously verbose. When I set a timer, I want confirmation not a conversation.

I picked up a copy of Bots when it first came out and was enamored by the promise of software applications appearing so human and useful. This promise, like software maintenance itself has held constant over the past 30 years. Perennially unsolved.

On the news of Netflix acquiring Warner Bros, I’m reminded of how good Netflix has been at innovating their business model.

Over the past 27 years, their business model has changed multiple times and each evolution appears to be in direct response to the bottleneck of growth, from maintaining inventory of DVD to acquiring global streaming rights.

Year	Business Model	Bottleneck to Growth
1998	Sell DVDs over the internet	Need to continually replenish DVD inventory,
1999-2006	Rent DVDs over the internet	USPS delivery & return times
2007	Stream movies over the internet	Acquiring US streaming rights to a massive library of movies
2009	Start producing movies (Netflix Originals)	Number of subscribers watching Netflix Originals
2010-2012	Global expansion; Canada, South America, Europe	Maintaining rights globally
2025	Acquire Warner Bros Discovery