You could build this. That's not in question, and I won't insult you by pretending it is. An orchestrator like Airflow or Dagster, some cloud storage, a warehouse, a dashboard layer, every piece of a sensor-data platform exists as a rentable service or an open-source project, and a competent engineer can wire them together. The question was never can you. It's the question every water utility answered long ago: you could also dig a well and build a treatment plant. Municipalities do it. The question is whether you're in the water business.

When building is right, said first

The boundary up front this time, because for this comparison it's load-bearing. Rolling your own is legitimate, and sometimes correct, in three situations. You already employ a platform team with idle capacity (rare, but real). Your pipeline is your intellectual property (a novel processing method, a proprietary model) and owning it end to end is the point. Or you have substantial non-time-series data workloads to serve anyway, and the monitoring program can ride on infrastructure you'd be building regardless. If you're in one of those, build, and I mean that without irony. We built ours, after all; this post is partly a report from that well.

What follows is for everyone else, the teams where "we'll just build it" gets said in a meeting by someone who won't be the one maintaining it in year three.

The three bills nobody puts in the proposal

Bill one: time to first value. The pieces integrate; that's the pitch. But "integrates" hides the domain layer: the schemas for sites and instruments, the harmonization logic, the quality framework, the delivery surfaces. No orchestrator ships that. Every monitoring program needs it anyway. In our experience, and in every war story colleagues have shared, that layer is months of engineering before the first scientist trusts the first chart. Months during which the monitoring program still runs on the spreadsheets the build was supposed to retire.

Bill two: the standing line. A built platform is never finished. Dependencies rot, APIs deprecate, and the person who wired the DAGs (the workflow graphs that define what runs when) leaves. In our TCO model, the custom path's cloud tooling runs about $520 a month for a mid-size network, and the engineering attention to keep it alive runs about $5,000 a month; a fraction of a data engineer at $200k a year loaded. That ~$5,520 total makes "roll your own" the single most expensive path we model, more than the enterprise platforms it was supposed to undercut. The estimates are ours and stated so you can substitute your own; the shape survives any reasonable substitution.

Bill three: the meter on your own success. This one deserves its own chart, because almost nobody prices it before they're inside it. A monitoring platform's defining activity is serving data out to browsers, partners, agencies. Cloud pricing is built the other way: data in is free, data out is metered. On AWS, egress past the first 100 GB each month runs $0.09 per GB in the first tier. That meter scales with exactly the thing you're trying to maximize.

Around 5.7 terabytes served in a month, the egress line alone crosses what a fixed self-hosted connection costs in our model before you've paid for any compute or storage. Serve little, and this is a non-issue; that's the honest boundary on this particular argument. But a program that succeeds and has more sensors, more subscribers, and more dashboards refreshed will climb that cost line as a direct function of its success. It's a tax on being useful.

The asymmetry nobody prices: who improves it

One more bill, subtler than the three above. A bought platform improves while you sleep. Every release ships features your program gets for the same meter. A built platform improves only when you build the improvement, which means in practice it doesn't: once the pipeline works, the standing engineering line goes to keeping it working, and the backlog of "we should add quality rules someday" quietly becomes the permanent state. Two years in, the bought platform and the built one are not the same product with different logos. One of them has been compounding.

There's a hiring version of the same asymmetry. A bespoke stack is a resume risk for the people who maintain it. Nobody's career is advanced by year three of someone else's DAGs, so the maintainers you can hire skew toward whoever you can't afford to lose. Ask anyone who has tried to backfill the author of an in-house pipeline what that search was like.

The report from our own well

Here's the part where I show my work, because we faced this exact math ourselves. Datasparks serves interactive analytics to browsers all day. Each user's first sync ships them a working database, which is precisely the workload the egress meter punishes. We ran the numbers and chose to own the machines: our ingestion engine and storage run on our own hardware, on a fixed line, where the marginal bandwidth cost of serving one more user's sync is zero. That decision of infrastructure as a fixed cost rather than a success tax is baked into why our meter can be flat and public with a permanent free allowance: we aren't passing through a cloud bill that grows every time you share a chart.

I'm telling you this for two reasons. First, honesty: the "self-hosted line" in that chart isn't hypothetical to us; it's how we run. Second, because it's the strongest form of the build-vs-buy point: somebody should absolutely build and operate this infrastructure. A vendor amortizing that standing engineering line across every customer is way cheaper than each monitoring program funding its own. That's not a clever argument, it's just what "utility" means. You don't dig the well because the city already ran the pipe to your street.

The decision, cleanly

So: build when the pipeline is your product, your team, or your existing platform. Buy when the pipeline is plumbing between your instruments and your stakeholders; which, for an environmental program, it almost always is. And if you're currently in the middle, half-built, the DAGs mostly working, the original author updating their resume, run the arithmetic before sunk cost runs it for you: the standing line you're paying is bill two, and it doesn't shrink in year two.

The one next step: put your last three months of cloud invoices and engineering hours next to the TCO worksheet. If your bar comes out shorter than ours, genuinely keep your well, and I'd love to hear how you did it.