From the desk of Guy Pistone, Founder of Valere
TL;DR
Service-as-software promises software margins on service revenue. But here’s the hole. Software margins climb as you scale, and a rented AI stack pays a metered bill for every outcome, so your margin is capped, and the vendors you depend on can squeeze it. It’s valued on the software’s curve and runs on a service cost structure. The fix is selective. Own the cost on the part of your pipeline that sets your margin, and rent the rest. Below is the test for telling which is which.
The hole
Start with the question that should come before the strategy. Does the math even work? Meaning, is the cost of your tool stack proportional to the revenue it generates, and does that ratio hold as you grow?
For a traditional software company, the answer gets better with scale. You build the product once. The second customer costs almost nothing to serve, the thousandth costs almost nothing, and your gross margin climbs toward 80 or 90 percent as the fixed cost of building spreads across more revenue. That margin expansion is the entire reason software earns the multiples it does.
Service-as-software on a rented AI stack works the other way. Every outcome you deliver triggers metered costs across several model calls, a specialized API, a vector database, and an orchestration platform, billed by usage. The thousandth outcome costs the same as the first. That cost does not amortize away. Your gross margin is capped at the spread between what you charge per outcome and what the stack costs you to produce it, and that spread does not widen as you scale. It can only narrow, because the vendors setting your costs raise prices precisely when you are most locked in.
This is the hole. The model is being valued on the software’s margin curve and operates on a services cost structure wearing software’s clothing. The companies raising at software multiples on this model are pricing in a margin expansion that the cost stack cannot deliver.
What Coase already told us
In 1937, Ronald Coase asked a question that sounds simple and turns out to run the whole economy. “If markets are so efficient, why do companies exist at all? Why not buy everything you need on the open market, transaction by transaction?”
He answered that using the market is not free. Every purchase carries a transaction cost in finding the vendor, negotiating the price, managing the dependency, and absorbing their price increases. When that transaction cost grows larger than the cost of producing the thing yourself, you bring it in-house. The boundary of the firm sits exactly where those two costs meet.
Every tool in a service-as-software stack is a live version of that decision. Each one is a bet that buying beats building. For nearly every component, the bet is correct because the tool is mature, the price is fair, and rebuilding it would burn months of engineering on a problem someone else already solved. But for the component that does the thing your company exists to do, renting carries a hidden transaction cost that the invoice does not show. You have handed a vendor control of your margin and your moat at the same time. If a competitor can assemble your differentiation from the same price list, your differentiation has a price, and it is not yours.
The proof
The best example to prove my point is Dropbox.
Dropbox ran on Amazon’s cloud for years. Then, around 2016, the company built its own storage infrastructure, a project it called Magic Pocket, and saved on the order of $75 million over the following two years.
The lesson people take from this is “own your infrastructure at scale.” But that is only half of it. The more useful half is the timing. Dropbox stayed on rented infrastructure for years first, and that was the correct call, because below a certain scale, renting was cheaper than building, and let the company move faster while it found its footing. The building was right at scale, but would have been wrong early. The same component, the same company, two opposite answers separated only by volume.
That is the part the build-from-the-ground-up advocates skip. The decision has two dimensions: which parts of your cost structure to own and when to own them. Timing is the one operator that operators tend to skip.
The test
Here is how to draw the line on your own pipeline. Take every component in your stack and score it on two axes.
The first axis is whether the component is strategic to your differentiation. If you owned it outright, would it create something a competitor could not easily copy, or is it a commodity available to anyone with a corporate card?
The second axis is whether its cost scales with your revenue. Is it a metered, per-outcome cost that grows with every unit you sell, or a fixed subscription that stays flat as you grow?
Those two axes give you four positions, and each one carries a different instruction.
When a component is strategic and its cost scales with revenue, build it from the ground up. It is both your moat and your margin lever, and it is the one place where owning the cost changes the slope of your economics. This is where the instinct to build is unambiguously right.
When it is strategic but its cost is fixed, own it or partner deeply, for defensibility. The reason to own it here is exposure rather than the bill. You do not want your core capability dependent on a vendor who can change terms on you.
When it is a commodity but its cost scales with revenue, you are in the dangerous quadrant, the one teams routinely misread. The component is not your moat, so building it feels like a distraction, and the cost looks manageable at today’s volume. But it scales with revenue, which means it will compress your margin at exactly the moment you are growing. Engineer it down now (route easy tasks to cheaper models, cache aggressively, manage tokens like a cost of goods sold), and revisit building it when your volume justifies the investment, the way Dropbox did.
When it is a commodity, and its cost is fixed, rent it, and do not let your engineers talk you into rebuilding it. The vendor spent years iterating on a hard problem and priced it predictably. Rebuilding it to save a fixed cost is the build trap, and it has ended more companies than the cost ever would have.
The discipline this test enforces is treating your tool stack the way a manufacturer treats its cost of goods sold. Manufacturers obsess over COGS because it decides whether they have a business at all. Service-as-software companies tend to book the AI bill as an operating expense or a cost of growth, which buries it. Reframed as COGS, the right behaviors follow on their own. You negotiate it, you engineer it down, you own the inputs that are strategic and expensive, and you refuse to sell an outcome below the cost of producing it.
A note on who is selling you the model
One more thing worth saying. The loudest proponents of service-as-software are often the companies selling the tools it runs on. They win whether you build or rent, because building means you buy their infrastructure, and renting means you buy their tools. Charlie Munger’s line covers it. “Show me the incentive, and I will show you the outcome.” The people doing the margin math in the keynotes have a stake in the answer. The independent operator has to run the numbers that the evangelists have no reason to run.
Coase’s insight was that a company is nothing more than the set of decisions it makes about what to own and what to buy. In service-as-software, those decisions are not back-office logistics. They are your margin structure, and they are your advantage. Get them right, and you have a business that compounds. Get them wrong, and you have a growth story with a hole in the bottom, draining a little more with every outcome you sell.
Guy Pistone is the founder and CEO of Valere, where he has spent fifteen years building digital products as a solo entrepreneur and for mid-market companies, and the last four years putting AI into every workflow he can find. Signal vs. Noise is his field log from inside that work, covering what AI compresses, what it stalls, and where the bottlenecks have moved.
Valere is a product and engineering firm that builds software and AI applications for mid-market companies. Six years in and an AWS Advanced Tier Partner, Valere works inside the digital transformation projects it writes about, with engineers and designers embedded in client teams from initial strategy through production deployment.
