A wrong buy costs money. A wrong build costs a year

Months is the first data column in the build, buy, ELT and hybrid tables below, because months is what you spend first. The lines most models leave out are the ones with no invoice attached. Where no publishable benchmark exists the row says so instead of carrying a round number.

One enterprise's three-year comparison

One enterprise customer ran this on its own scope in 2025, with us, on its own salary and infrastructure assumptions (source 23). The customer is not named. The build side is seven modeled line items. The buy side is one figure: the three-year subscription for that one customer's own configuration, as of 2025-09-17. It is a modeled total rather than a copied invoice, one configuration rather than a rate card, not a price list and not a tier, and not a quote for you. The model decomposes it no further, and neither do we.

So do not try to read this line against line. One column itemizes because it is a model of work you would do; the other does not, because it is a price for one configuration. Three things you can do instead, in this order. Read down the build column and mark which lines a bought platform takes off you and which it leaves, set out under the buy table below. Put your own quote variables beside that customer's, in the next block. Then get a quote and replace the buy figure with your own number.

What the 30% is 30% of, the model does not record. The rate and the amount are both on the record; the base is not, which is why the row above reads "as modeled" rather than as a multiplier you can re-run. Our own arithmetic on that model's seven lines, not figures the model prints (source 23): 30% of development plus maintenance is $501,000, adding data quality gives $561,000, and only development, maintenance, data quality and security together reach about $606,000. The loading cannot be decomposed here, which is the same treatment the buy figure gets below and for the same reason - the model does not break it out, and we will not invent the breakdown. One consequence, printed rather than left for you to find: the struck-security row subtracts the $150,000 security line and leaves the loading exactly as the model set it. If any part of that loading was riding on the security line, the honest struck total is below $2,800,000, so the table overstates the build column and the error runs in our favor rather than yours. We would rather print the direction of that error than close it with a number the model does not support.

The model assumed four to five full-time engineers and 18 to 24 months to parity. Parity there meant one customer's own scope, set out in full at source 24: 17 or more sources in a single warehouse, normalized so a cost, impression or conversion figure means the same thing on every platform, backfilled as far as each platform's retention allowed, and operated with a named owner and a documented rerun path. The months belong to that scope, and a smaller scope is a smaller number. It is a build duration, not a payback date.

Three years is not a lifetime, and the two shares are not the same quantity. The under-30% figure at the top of this page is Composio's, and it is the share initial development takes of an integration's whole life, which runs well past any three-year window (2026-01-16, source 3). This customer's model stops at three years: $670,000 of year-1 development against $1,000,000 of maintenance in years 2 and 3 puts development at about 40% of the three-year people cost, which is our arithmetic on that model's own lines rather than a figure it prints (source 23). Both hold at once, and the longer the horizon runs the smaller development's share gets, but you should not have had to do that reconciliation yourself. One thing the model does not settle: at $500,000 a year the maintenance line runs at about three-quarters of the year-one rate, which reads like a smaller standing team than the one that built it, and the model records four to five engineers without saying how they are spread across the three years. This page argues that the operating half is the half that grows, so when you re-run this on your own numbers, that is the assumption to raise rather than the one to inherit.

What that one figure does not carry. It is the subscription. It is not everything buying costs, and the buy table below carries the lines it leaves out, from implementation and analyst time to renewal and an exit migration. None of those were priced into the $1,200,000, and several have no invoice attached on anybody's side. So the buy column here is a subscription total, not a buy-side total, and a complete buy-side model is larger than $1,200,000 by whatever those lines cost you. We would rather print that than have you find it.

Does the $150,000 security line apply under a buy? Partly, and smaller. That line is that customer's own assumption, and the model records the amount rather than the scope behind it. Under the scope rule in procurement, a pipeline that is never attested to a third party starts no examination clock and the line is zero: if that is you, strike it, which is the $2,800,000 row above. Under a buy, the examination and the annual penetration test sit with the vendor, and you ask for the report instead of commissioning one. What does not move: your own security review of that vendor at purchase and at every renewal, counsel time if the data processing agreement needs redlines, and every obligation you already owe your own customers. Those three sit on the buy table below, carry no dollar figure, and cost less than running an examination yourself. Less, not nothing.

Where your own configuration sits

We publish no tiers and no per-connector rate, so the honest substitute for a decomposed buy column is the set of variables a quote is actually built from. There are five. Two of them are on the record for that customer's configuration and three are not, and the gaps are printed as gaps.

Two knowns and three blanks is the second reason that customer's total is not yours, on top of the first reason, which is that it was one configuration priced once, in 2025. Fill your own five in, then get an actual quote and finish your model with that number rather than with this one.

If you build

"Our dev team will just add it to the roadmap" is a headcount statement rather than a schedule, and the rows above are what it resolves to. The roadmap is not the constraint. The standing team that owns every line above, after the launch dashboard ships, is the constraint, and it outlives whoever proposed it.

If you buy a platform

What a bought platform absorbs from the build column, and what it leaves

This is the comparison that does not need a price, and it is the one to make. Every line in the build table above, and what a bought platform actually does with it. "Absorbed" here means for sources in the vendor's catalogue and for nothing else.

Absorbed does not mean gone. Every line above that moves to a vendor comes back as one of the lines in the buy table you just read: their support queue, their schema changes, their sunsets, their renewal, and your migration if you leave. The honest form of this comparison is build lines you keep against buy lines you take on, and both columns have lines with no invoice attached. That is the part of it we can hand you without a price.

If you buy connector-only ELT and model it yourself

If you run a hybrid

Hybrid has no model of its own, and building one would be the error this section spends its length refusing. It is a composition: every line below is already priced in the build, buy or ELT tables above, and the only new information is which of them it comes from. The sorting rule is the one in the four options - buy the layer that churns, build the part that encodes your judgment, keep your warehouse and your models where they are. No total is printed, because the total is your own quote added to your own salary line, and neither of those is ours to print.

Read the fourth column and the shape of a hybrid falls out: a subscription for the rows marked Buy, salary for the rows marked Build, and the Build rows never reach zero. That is why a hybrid is not a cheaper buy. What it buys is months on the catalogue half while your own months go to the modeling, and the sorting is only worth doing if the catalogue covers most of your source list. If your list is mostly long tail, the Buy rows cover less than they appear to and the arithmetic slides back toward the build column, and its months come with it.

What a connector costs, by band

Two figures from the same model look like they contradict each other: about $24,000 of engineering time for three basic connectors, and five or more engineers at roughly $750,000 a year fully loaded with about 60% of that effort landing on connectors (source 25, 2026-05). They are one model at two scales. This is the bridge, and only the first band has a number.

We will not fit a line through two points. Linear extrapolation from the first band (source 25) gives roughly $80,000 for ten connectors, and we do not believe it, because the curve bends on the mechanisms in the third column rather than on connector count. We hold no defensible figure for the upper three bands and will not invent one. The mechanism column is sourced from our own fleet (source 27); the dollars are not.

The crossover, as judgment rather than measurement. Below about ten mainstream sources, with a standing need, analytics engineers already shipping dbt models every week, and no agency multi-tenancy or regulated-data surface, connector-only ELT plus your own modeling is the cheaper answer and you should not call us. Above that, or with any of those conditions reversed, what you are buying is the normalization semantics and the long tail. That is judgment from our own fleet and our own customers rather than a measured crossover, and should be weighted as such.

The two rows that are zero for most readers

SOC 2. The observation window and the examination cost apply only if the pipeline itself becomes a service you attest to third parties. For internal marketing analytics under the posture your company already holds, this line is zero. The procurement section argues where it stops being zero.

On-call. For a batch marketing pipeline the honest floor is a named owner, a documented rerun path, a business-hours rotation, and an agreed staleness tolerance written down as a service level. A sync failing at 03:00 on a Sunday means the dashboard is stale on Monday morning and somebody reruns it. Nobody staffs eight engineers for that. The floor in the build table is what a genuine 24/7 production-service commitment costs, and it applies only if you are making one, to your own business or to a client. Hold any vendor including us to the contractual version rather than a headcount claim: a one-hour response target on a P1 incident and a 99.95% uptime target, written into the technical and organizational measures of our data processing agreement (2026-05-19, source 22). Make us put both in your contract and make every other vendor do the same. A target with no remedy attached is a marketing number, and an internal build has neither (procurement).