Build, buy or rent a data platform

Coase's list, in a data team's words. Search: the weeks spent finding out which vendors exist, which of them do the thing you need and which only say so. Negotiate: the procurement cycle, the security review, the legal redlines on the data-processing terms. Contract: writing down what "the platform works" means precisely enough to hold someone to it, which is the eval-as-contract problem from deep-dive session 8 in a different costume. Monitor: checking, every month, that what was promised is what is being delivered, and having a lever to pull when it is not. None of these lines is on the vendor's quote. All of them are paid in your team's hours, which are the scarcest thing you have.

The in-house side has costs too, and Coase was equally clear about them: as a firm takes on more activities, the cost of coordinating them rises, managers make more mistakes, and the firm loses the discipline that a price would have imposed. The platform team you hire to avoid the vendor has to be hired, managed, retained and replaced, and its output has no market price to tell you whether it is worth what it costs. The boundary sits where the two curves meet: the rising cost of coordinating one more thing inside against the transaction cost of buying it outside.

Where a data platform usually lands. The friction is high when the thing is hard to specify, changes often, and is hard to check from outside, which describes the parts of a platform that touch your own data model, your own semantics and your own quality rules. The friction is low when the thing is standard, stable and easy to test, which describes storage, compute and most of the plumbing. That is why the same team can sensibly rent the warehouse and build the semantic layer: the boundary runs through the platform, not around it.

Every make-or-buy decision runs into a constraint that is not money: the number of engineers you can hire this year, the security clearance a vendor cannot get, the one person who understands the legacy schema. Economics calls the value of relaxing such a constraint by one unit its shadow price, and it is the number that tells you whether the constraint is the real reason you are building rather than buying. If the shadow price of one more engineer is high, the platform team is expensive in a way the salary line does not show; if it is near zero, the "we cannot hire" argument is not the binding one.

Computing a shadow price properly means setting the decision up as an optimisation and reading the dual, and that is the subject of the prescriptive analytics course at learn-prescriptive-analytics-with-phoebe, which owns the feasible region, the solver and the dual variables. Tonight does not solve one. It only insists that when someone says "we have to build because we cannot get X", the next question is what X is worth at the margin, and that there is a course where that question has a method.

Total cost of ownership is the sum of every cost an option incurs over a stated period: the fixed cost, the monthly cost, and the transaction costs from Part 1 priced in hours. Its one indispensable input is the period. On the invented inputs above, rent is cheapest for the first eleven months, buy is cheapest from month 12 to month 29, and build is cheapest from month 30. Ask "which is cheapest?" without a horizon and the honest answer is "when?". Anyone who presents a TCO comparison without stating the horizon has presented a number that could be made to favour any option by moving one date.

Fixed against variable is the reason the lines cross at all, and deep-dive session 4 met it as the break-even volume between an API bill and a fixed cost. A fixed cost is paid once and spread over every month after; the more months, the thinner it is spread. A variable cost is paid every month and never gets thinner. So a long horizon favours the option with the highest fixed and lowest variable cost, and a short horizon favours the reverse. The build line starts highest and ends lowest for exactly that reason, and it is neither the good option nor the bad one; it is the long-horizon one.

The number to write down first is therefore not a cost. It is how many months you are confident the platform will be needed in something like its current shape. Teams that are honest about that number, which is usually shorter than the roadmap says, find the decision mostly makes itself.

The rent line is the most expensive by month 36 and it is still often the right choice, because its monthly fee buys something the chart does not show: the right to stop. A fixed cost is a commitment; a monthly fee is a series of small decisions, each of which can be "no". That right is worth most when the future is least certain, when the team does not yet know which platform features it needs, whether the use case will survive its first year, or whether the data volume will be ten times larger or a tenth. Economics calls this option value, and it is real value, not a consolation.

The honest way to weigh it is to ask what the uncertainty is and when it resolves. If in six months you will know whether the use case is real, then six months of rent is the price of finding out, and it should be compared with the cost of having built for a use case that died. If the uncertainty never resolves, rent is a permanent premium for flexibility you keep needing, and that is also a fair price if the flexibility is used. Where the argument goes wrong is renting for the option value and then never exercising the option: paying the premium for years on a decision that was settled in month 4.

Tonight is the economics of the choice and not a survey of the market. What the warehouse buy landscape looks like, which categories of product sit where, and how to read a vendor's positioning, is the subject of the data warehouse course at learn-data-warehouse-with-phoebe, which owns that map and keeps it current. No vendor is named on this page, on purpose: the three lines and the three crossings are the same whichever names are on the invoices, and a page that named them would be wrong within a year.

What is in the block. Moving the data, which is the smallest part. Rewriting every pipeline, query, dashboard and model that was built against the vendor's dialect, API or semantics, which is the largest. Re-testing all of it against the numbers it used to produce, because a migration that changes a number silently is worse than no migration. Retraining the people who had learned the old tool. And the months during which two platforms run at once, which cost twice. Every one of those is a fixed cost paid at the exit, and the longer you have been on the platform, the larger it is, because more has been built against it.

Why it is invisible on the vendor's chart. Not deceit, usually; the vendor's chart is a chart of the vendor's fees, and the switching cost is paid to nobody. It is your team's hours, your delay, your risk. It appears on no invoice and so on no invoice-based comparison. It also grows in a way the invoice does not: the fee per month is roughly flat, while the exit cost climbs with every integration built. A rent decision that was genuinely reversible at month 6 can be effectively irreversible at month 30 without a single term of the contract having changed.

The option value from Part 2, revisited. The monthly fee bought the right to stop. A switching cost is the price of exercising that right, and if it is large enough the right is worth nothing: you are paying a premium for flexibility you cannot afford to use. That is the case where rent is the worst of the three, more expensive than build over the horizon and no more reversible. The way to know which case you are in is to draw the fourth line before signing, with an honest estimate of what exit would cost at month 12, 24 and 36, and to write it down where the steering group can see it.

Deep-dive session 5 taught switching costs as one of the few durable moats a platform can hold: a customer who would have to pay a large fixed cost to leave will tolerate a higher price than one who can walk. Tonight's chart is that sentence from the customer's chair. The vendor's incentive is to raise the exit cost, not by force but by helpfulness: a proprietary feature that saves you a week today and costs you a quarter to replace, a dialect that is slightly nicer than the standard, an integration that only works with the vendor's other products. Each one is genuinely useful and each one raises the block in the figure.

The customer's defence is the mirror of the vendor's strategy: prefer the standard over the proprietary where the difference is small, keep the semantic layer and the tests in a form that does not depend on the vendor, and price the exit every year as if you were going to take it. None of that is free either; it is a monthly cost paid to keep the option alive, and whether it is worth paying depends on how likely you are to need the exit. A team that is certain it will stay for five years can rationally build deep into the vendor. A team that is not should keep the block small, on purpose, and know what it costs to do so.