I wrote a couple of years ago around why we were building a company centered on billing amidst an AI boom. The core argument there is: Orb allows you to stop spending time in the tedious, undifferentiated infrastructure of value capture so you can focus on the task of understanding and building product value for your customers.
A lot has changed in the last two years. In some ways, AI has started to cash some of its checks, including a real and dramatic shift in the cost of building software. Said more simply: Claude Code is pretty damn good.
Much ink has also been spilled on the first and second-order effects of this, including the proclaimed death of software categories. The story goes something like this: software vendors will quickly be obsolete as the cost of building software approaches zero. Instead of paying an annual fee to rent a product, companies just vibe code a copy. Since that copy will be built in-house, it will further have the advantage of being hyper-personalized to that company’s activity, data, and quirks. Push this far enough and you can just get rid of the software altogether. Just build your own bespoke AI agent that obviates the need for tooling.
I think this line of thinking misses a few critical things.
Aaron Levie recently published a post adding some useful nuance to this conversation. He frames things along two important axes:
- “Core” software is unique to your firm, whereas “context” software is undifferentiated. There’s an asymmetry in upside/downside here, too: the upside of getting “core” software right is high, whereas “context” software is usually about hedging downside.
- Deterministic processes require guardrails and structure that is a good fit for software, whereas non-deterministic activities are a good fit for probabilistic and generative agents. Agents need something to organize and bridge their interactions.
The implication is not the death of software, but a shift in what software is and how it captures value: from software-as-a-service to something closer to services-as-software, increasingly tied to consumption and outcomes (coincidentally though besides the point of this specific post: a ringing endorsement for Orb’s thesis around powering exactly these business models!).
I think this is right, but it’s worth pulling a thread more explicitly that’s relevant. The "vibe code your own billing" take misunderstands what you're actually paying for when you buy software. You are not paying for the feature execution (and in fact, enterprise sales is almost never about features anyhow, see also patio11 for a more organizational argument). Yes, that part is getting cheap. You're paying for accumulated judgement about a domain. How should proration work? What's the right schema for representing pricing tiers? How do you build your pricing data model in such a way that daily revenue reporting is possible to analyze? These aren't hard technical problems. They're taste problems that require having seen many companies get it wrong and actually spending team at the sharp edge of these failures getting burned.
Companies don’t hire McKinsey because they can’t make slides. It’s because they’ve seen the problem fifty times before (put aside for a second the majority of cases where it’s purely a risk transfer mechanism). The difference with agentic software vendors is that the output is not advice (real automated work gets done) and the margins nonetheless look like software, not services. That’s a lot of value on the table to capture.
Aaron frames context software as primarily downside protection. I think that’s incomplete. In domains with enough hidden complexity, context software is effectively about buying scar tissue and a specific point of view on how to avoid it. The fastest way to kill a company isn’t usually making an obviously bad decision. It’s making a decision that seems incrementally reasonable but constrains you six months later. In billing, there are hundreds of these traps at every turn because of the interconnectedness of the domain model. In these domains, context software doesn’t just hedge risk. It compresses the time it takes to develop good judgment. It lets a team behave, on day one, like they’ve already lived through a few painful iterations.
It's worth thinking through what factors go into a domain's defensibility (its so-called immunity to vibe coding). The index probably looks something like:
- Edge case density: how many gotchas per square foot?
- Feedback loop length: days, months, or at audit time?
- Unknown unknowns ratio: what percentage of the hard problems would you not even think to ask about?
- Decision Interconnectedness: does a decision made today constrain a decision you don't yet know you'll need to make?
- Multi-audience nature: does the workflow involved bridge n functions that speak different languages?
My intuition is that Postgres scores quite high, and internal admin tools score low. Billing is somewhere in between, but closer to databases than most people think. The consequences are diffuse, delayed, and load-bearing in ways you won't see until you're already stuck.
Aaron’s right that the demand for enterprise software will continue to grow dramatically, but it won't be evenly distributed. I think the investment will be significantly more concentrated in domains where judgement keeps regenerating at the frontier, and lean teams will continue to value that expertise.