InfraDots vs. DIY pipelines: an honest comparison

Let’s be honest about why DIY wins so often. It’s effectively free — you already pay for CI. There’s no procurement, no vendor review, no new platform to learn. Every engineer already knows how to read a GitHub Actions log.

It’s also fully under your control. Your runners, your secrets management, your conventions. No feature you need is gated behind a pricing tier, because you build the features. And there is no lock-in story at all — it’s just Terraform in a pipeline.

For a team of two or three with a dozen state files and infrequent changes, this is the right answer. The problems start when the team and the infrastructure grow faster than the pipeline does.

DIY isn’t free — it’s prepaid in engineering time. A platform engineer spending even twenty percent of their time feeding the pipeline costs more than most platform subscriptions, before counting the incidents that better review and drift detection would have caught.

The crossover point is earlier than most teams think: roughly when you have more state files than engineers, more than one team touching infrastructure, or your first “the plan looked fine” postmortem. Before that, keep the pipeline. After it, the pipeline is keeping you.

Plan-on-PR, apply-on-merge is a weekend of work. Then reality arrives: concurrency locks so two merges don’t apply over each other. Environment ordering. Targeted applies for emergencies. Retry logic for transient provider errors. Secrets rotation. Terragrunt run-all behavior in CI. Each one is a YAML patch, a bash script, a convention someone has to remember.

Eighteen months in, most teams are maintaining a few thousand lines of pipeline glue that one or two people actually understand. That’s a product — with no roadmap, no tests, and a bus factor of one. The platform you avoided buying, you built. You’re just not maintaining it on purpose.

In a DIY setup, the plan is a log artifact. Reviewing it means scrolling CI output or a folded PR comment — hundreds of lines of diff, where the one line that matters (a resource replacement, a security group quietly opened) looks exactly like the ninety-nine that don’t.

Nobody reads those plans carefully. Everyone knows it; approval becomes a reflex — you’re rubber-stamping infrastructure PRs. The pipeline enforces that a human clicked approve, not that a human understood the change. That gap is where the production incidents come from.

A pipeline runs when you push. It’s blind between pushes — and that’s precisely when drift happens: a console hotfix during an incident, a script someone ran once, an auto-scaling change nobody encoded. Git says one thing, the cloud says another, and nothing is watching the gap.

You find drift in a DIY setup when a plan you expected to be a one-liner shows forty changes — usually at the worst possible moment, when you needed to ship the one-liner. Building scheduled drift detection with useful notifications is exactly the kind of side-project the pipeline’s maintainer never gets time for.

DIY pipelines are the right starting point, and for small, stable teams they’re the right ending point too. The trap isn’t building one — it’s not noticing when it became a second product your best engineers maintain in the margins.

InfraDots keeps the parts of DIY that work — Git-driven, Slack-centered, your tools, your code — and replaces the parts that don’t scale: the glue, the log-scrolling reviews, the invisible drift.

If the pipeline is still cheap, keep it. If you’ve started paying for it in engineer-weekends and postmortems, the build-vs-buy math has already flipped.