Comparative Advantage in Software
Why should anyone buy software
As someone who builds software for a living and— more importantly— sells that software, I have to think a lot about the value it provides. The landscape has changed a lot over the past few years. Coding agents and generally capable models lower the cost of building and increase the bar software needs to meet to provide value.
When software was hard to build, the advantage of buying it was so obvious it didn’t bear explaining. Now it does. In this post, I want to start from the premise that any software can be generated by an LLM and figure out, from there, how software companies retain their comparative advantage and how this cashes out in product development.
An analogy to databases and event streams
As an engineer, the first place my mind goes for any mental foothold is the nerd bible of Designing Data Intensive Applications.
In distributed systems, the event is king. The entire business comprises a stream of events—clicks, purchases, impressions, state modifications from user input. The business-as-event-stream thinking unlocks a lot of core concepts of scalability. The focus becomes maintaining the log of events at any cost, since everything else is essentially ephemeral. As long as you can replay the event stream, you can rebuild your databases and recover from any catastrophe.
Databases become materializations of the event stream, wrappers for convenience and efficiency. You want to know how many purchases the user has made in the last month? You could just replay all the events and tally them up. You materialize, because that’s too expensive.
There’s a similar reframe happening in the conversation around products and services. The weights within large LLMs contain the knowledge to perform any intellectual labor, if the right tokens are induced from them— including any code needed to perform a specific task. So a software product, then, is a materialization of a token stream. And there’s a nice parallel to framing of a database as a materialization over an event stream. Why materialize? To save time and money.
Where a product’s comparative advantage comes from
A way to look at the moat around any product, whether it will get eaten by AI, is to figure out the cost in tokens of producing and maintaining the product. On one end, if the product is a thin wrapper, its gross margins are either negative or it’s a rip off. On the other end of the spectrum is a system of record with rich workflows ingrained. Maintaining the correctness of the state and the actions taken within a Claude chat would be enormously difficult and expensive.
If, theoretically, customers can get the tasks they want to accomplish done with tokens right from the source (Claude), a product will have value if there’s a comparative advantage in how it uses those tokens. We can’t sell dollars for fifty cents, but we can 1) lower the number of tokens needed to complete a task and 2) increase the correctness and therefore the value of each token used.
Towards the first goal, deterministic harnesses and data modeling reduce the number of tokens required for a given task. To extend the event stream metaphor, this type of software functions as a read cache for the tokens needed to do the work. Workflows force agents down the right logical paths, rather than exploring each turn the space of next steps. Strong types and domain models further constrain.
Towards the second, context engineering and evals increase the average value of each token produced by improving accuracy. Evals shape the distribution of tokens coming out. And context engineering provides the evolving state with which the weights interact (the event stream, the log of what’s happening in the business).
It rings weirdly to call all databases context. But if we’re talking about agents, they’re the source of all context. And maintaining persistence with the right level of normalization, evolving for new requirements etc is hair-thinning work.
Some examples from Kintow
Kintow is both an AI tool and an ERP for restaurants. We run agents on top of a foundation that models every part of a restaurant—inventory, waste, recipes, labor etc. And the comparative advantage thought exercise is not theoretical for us. Some of our customers came from spreadsheets, others came from incumbents, but a select few came from their own home-cooked solutions. And I expect that number to go up.
Their systems break along the dimensions I described above. I’ll choose two examples: automated procurement (which I’ve written about here) and invoice parsing.
Automated procurement entails a complex, evolving state in the form of inventory levels and their theoretical depletion. Any agent completing this task should take this context into account with precision and adhere to the right notification and approval controls for substitutions and out-of-stock issues. It’s a lot to prompt, and it needs to be reliable enough to entrust with 30% of a restaurant’s revenue.
Invoice parsing on its face seems like the perfect candidate for a home-grown solution. With some prompting, Claude nails the parsing of an individual invoice; but it doesn’t do it quite the same way the next time, and, more time-consumingly, it doesn’t sync up with your catalog. Preventing small issues from compounding overtime into an unmaintainable slop requires evals and context engineering and error-correcting workflows.
These failures cost time and money. Most customers come around to the simple fact that they’d rather focus on their core business and trade with a company that specializes in building software. It’s just a good deal.