Schlep as a Service

AI has us questioning the moats of Software as a Service. Each company seems to be caught between the pincers of “The labs will build it” or “I’ll just build it myself”. There are many instances where those pincers have already closed. Data analytics frontends like Tableau are one such example¹. Today, if the software is sufficiently low stakes, and not too complex it can be few-shotted by coding agents, or at least in a few weeks by a couple of engineers + AI.

As the models get better, the software moats of high fixed costs, ongoing maintenance, and painful migration, are clearly shrinking. The Valley-brained take is that these moats will evaporate completely. The labs themselves, and even Nvidia² are not safe, as is anyone who produces something intangible. This tweet captures the limiting case:

There are various counter arguments, some better than others³. The strongest counter argument: schlep, is overlooked. Schlep is an umbrella term that refers to the parts of writing software that cannot be made quicker with intelligence. Schlep is the moat, and we discuss how that moat affects incumbents and startups in the age of AI.

Software is Empirical

In machines of loving grace, Dario is optimistic about the progress that could be made in biology due to AI. However, he notes that we are fundamentally rate limited by running experiments. Biology deals in living cells and organisms, there is a limit to what humans/AI can know deductively. We must run (and wait for) experiments to test our theories and make progress. Everyone accepts that applies to biology, but it’s underappreciated how much that applies to writing software too.

Slack is a piece of software that is often discussed as “one-shotable in a few years”. The models aren’t quite there yet, but they are currently being trained to produce entire SaaS products. Soon enough, we’ll have models that can produce Slack and maintain it with very little human involvement. Then, companies will not pay for Slack, they will either write it themselves, or demand much lower prices. Or so the story goes.

This story overlooks all the things that are hard when it comes to building something like Slack. Yes, the writing of the code got much easier, but the feedback loops did not get faster. The first version of Slack was certainly trash. Countless releases with user conversations, metrics, error logs and eventually AB tests were all critical in getting Slack to where it is today. All of these move at human speed, just like our biological experiments.

If you’ve ever worked on a software product⁴ from scratch, you’ve felt the point I’m making. Iteration after iteration, you’re slowly making things less and less shit, the real world feedback is essential. This is doubly true for engineering decisions at scale. Over the course of a decade, thousands of issues are observed and fixed, complex trade-offs are made, all downstream of real world data.

A super intelligent AI will make better product and engineering choices. It will run simulations and execute the optimization loop in fewer releases, but writing software is still fundamentally an empirical process. It’s a superintelligence, not an omniscient god. It’s constrained by what it can observe. Thinking Slack and the way it is deployed can just be copied, is to overlook the 1000’s of trade-offs and system design decisions that could only have been made after observing millions of customers use the system over many years.

Both humans or agents are complex, chaotic systems (just like cells). You are optimizing the software for those chaotic beings. The more complex your problem, the more you benefit from optimizing across a large pool of humans/agents. So when companies or the labs are faced with implementing slack versus buying, it’s an easy choice, use what already works.

A great pre-LLM example of this is hyperscalers who historically implemented many SaaS tools internally. Initially this was borne out of necessity⁵, but as time went on the SaaS ecosystem caught up and passed these internal tools⁶. If you’ve ever worked for a big tech company, you’ll know how bad those internal tools are. Here’s Navi from Neetcode literally citing internal tools as his reason for quitting Google. The main reason is that these SaaS companies observed far more users than an internal tool ever could. They also ran a much stronger optimization loop, make this SaaS tool excellent or die. Internal tools just can’t compete.

Software is Real

Software as an empirical process is the most important schlep moat, but there are other less sexy contributors. Integrations, onboarding suppliers and proprietary data feeds. To be valuable, SaaS must correspond to the real world. The real world requires agreements to set up integrations and habit formation by humans to slowly depend on it and add data to it.

Agents do little to speed up the process of signing off on a proprietary bank integration. Nor do they speed up the willingness for humans to put trust in a system. The trust aspect reinforces the empirical, proving that you can execute complex, economically valuable, business logic is enough to deter switching.

To put a bow on it, exposure to the distribution of economically valuable actions is a big, underrated moat. Real world integrations and trust in the system add to that base. Note that the moat is not automatic, there’s plenty of lousy software that fails to leverage that position (Workday 👀). Nor is it completely unassailable, particularly during our global distribution shift from human users to agentic users, which is our focus for the rest of the post.

AI Tools, not Vertical Agents

The 2023-2025 reaction to AI was to lean in hard by building AI into the product. Originally derided as LLM wrappers, the current (more accurate) term for that business model is vertical AI agent. The vertical AI agent is an amazing business when executed correctly. But for many existing SaaS incumbents, it’s not a realistic outcome, and going for it risks losing the moat.

In the age of AI the war chant is: “Move up the value chain, deliver outcomes not software, cut into labour budgets, do knowledge work, get on the token path, expand the TAM!”. It’s natural for a successful SaaS company to want to swing for the vertical agent outcome, because pulling it off entails continued and accelerating growth.

The problem with the vertical agent model is the vertical part. Think about the position of most SaaS inside a business. Each one executes a tiny slither of that business’s activity. Human knowledge workers are fundamentally horizontal. Humans get the full picture across email clients, editors, spreadsheets and dozens of different SaaS tools.

In 2026, Claude and Codex started getting the horizontal picture too. Out of all the agents, they are in the best position to execute the knowledge work. Conventional wisdom says this is how the labs eat your business model. The conclusion being, hold onto your proprietary data as a moat, build your own agent using that context (and maybe even train).

While that advice may be helpful for some businesses, the “data moat” argument is just wrong for most SaaS. Firstly that data isn’t really yours, it’s your customers. More importantly, it’s not enough data. No matter how good your product is, your vertical SaaS does not have enough context. Even in the much lauded “system of record” the value is not in hoarding the context, but the fact that it contains an accurate, working, useful representation of a particular vertical of the business. In most cases, the correct strategy is to eagerly make this accessible to the horizontal agents. In other words, become an AI tool.

If you make your SaaS an agent friendly tool, it is simply not in the interest of the labs to replicate it. The years of painful integrations that move at human speed, and the thousands of iterations that made it the best in class at its vertical slice. It took years to build your schlep moat, and you’re underrating just how hard it is for your customers to build something as good.

Databricks is a great example of a business that naturally became an AI tool. I’ve fantasized about building a more agent friendly Databricks competitor. Last time I used it, debugging and tuning Databricks jobs with Claude was a real pain in the ass. But their cloud computing platform is excellent and battle tested, it’s already in the enterprise, and they’re a cashflow machine. They don’t even need a great developer experience anymore, agents will deal with it, as long databricks make all relevant tasks possible via MCP, CLI or API. Even if they bumble their way there, they crush me, the schlep moat is too great.

Many SaaS incumbents are doing the opposite, trying to become the agent the white collar professional uses. They’re explicitly hoarding their functionality for their agent or UI, and either over-charging for, or outright blocking, programmatic access. Resisting becoming an AI tool is the quickest way to drain your schlep moat. If everything else can be accessed by a horizontal agent, your product becomes the bottleneck, and an immediate priority to get rid of. This opens the door for challengers.

Seat based Counter Positioning

Databricks, Stripe and Twilio are all businesses that are well-poised for the agentic transition, because they already have usage-based pricing models. Usage based pricing is usually discussed in terms of consuming tokens as a vertical agent, but I mean it in the more traditional sense⁷ (e.g. per API call, per CPU, per GB).

This is a difficult transition for seat based SaaS incumbents, for multiple reasons. Pricing changes are a one way door, customers find them confusing, and there is genuine downward pressure on prices due to the cost of producing software going down. SaaS incumbents built their teams when engineers hand wrote the code, they are well over-staffed, accustomed to continuous revenue growth and will find it very challenging to nerf their own revenue with a cheaper usage based model.

Then there is the allure of becoming the vertical AI agent. To the incumbents, that is perhaps the only path that doesn’t require an initial drop in revenue.⁸ It’s natural to want continuous growth, but as discussed it’s unlikely and expensive. Context engineering, building tools, harness and evals requires expensive talent.

This is doubly delicious for startups challenging incumbents. Not only do we have traditional counter positioning, but the incumbents are distracted and wasting money on an expensive quest that will likely fail. While they’re spending time on that, small startups can come in and start building the schlep moat, starting with the most useful functionality and making it agent operable.

2026 is the time to execute this strategy. While programmers have all transitioned to working via a horizontal agent, much of the white collar workforce is just starting to try out Claude Cowork and codex / GPT work. The pain of an agent-unfriendly SaaS is about to become real, and being forced to use an incumbent second rate agent/UI via computer use is going to infuriate the incumbent’s customers.

The irony is that the potential growth from being used by agents is so much higher than any seat based model ever had. Focus on building an AI tool. Keep your code deterministic and boring. No token bills, no GPUs, no expensive talent. Let the labs and other companies spend billions to make agents better at using your tools. Schlep your way to becoming Claude’s chosen AI tool, before the incumbents understand where their true value lies.