Dora NodaElite DevOps teams deploy 973 times more often than low performers. They also recover from incidents 6,570 times faster. Those DORA numbers have been the industry's scoreboard for years — and by that scoreboard, 2026 looks like a golden age: more than a third of teams now deploy daily or more often. But a Harness survey of 700 engineering practitioners, conducted by Coleman Parkes in February 2026, asked an embarrassingly basic question underneath the glory metrics: can you add a functioning build-and-deploy pipeline to an environment in under two hours? Only 21% said yes.
Read that again. Teams ship code daily, yet nearly four in five cannot rebuild the machinery that ships it in a single afternoon. The pipeline works until the day it doesn't — a new service, a new environment, a migration — and then the setup tax comes due. AI coding tools made the gap wider, not narrower: 84% of developers now use AI daily for coding tasks, while more than a third of their time still goes to repetitive manual work the pipeline was supposed to absorb.
This post itemizes that tax. Not as vibes — as a timed, row-by-row comparison of the two paths teams actually walk: the Dockerfile-plus-CI-config path the 79% are stuck on, and the buildpack-based git-push path that finishes before lunch.
The setup tax, itemized: DIY versus git-push, side by side
Take a typical starting point: a small team with a working web app in a repo — say a Node or Python service with a database — that needs to go from "runs on a laptop" to "deploys from git to a URL with TLS." Here is where the hours go on each path:
| Step | DIY: Dockerfile + CI config | Git-push PaaS (buildpacks) |
|---|---|---|
| Containerize the app | 2–8 hours: write the Dockerfile, multi-stage it, pick and harden a base image, slim the layers, debug the "works locally" gap | ~0 hands-on: buildpacks auto-detect the runtime and produce an OCI image with no Dockerfile; first build takes minutes of wall-clock |
| CI workflow | 2 hours–2 days: author and iterate on workflow YAML (build, test, lint, cache), wire up branch protections. One practitioner put it plainly: "I spent two days wiring up a proper .github/workflows/ setup" | ~0: pushing to the connected branch is the pipeline trigger; no YAML to author |
| Registry + image plumbing | 30–60 minutes: provision a registry, create pull secrets, wire credentials into CI and the cluster | 0: the platform builds and stores the image internally |
| Environments + secrets | 1–3 hours per environment: env files, secret stores, per-env config drift ("staging works, prod doesn't") | Minutes: env vars in a dashboard or config file, scoped per environment |
| TLS + custom domain | 1–4 hours: DNS records, certificate issuance, renewal automation, redirect rules | Minutes: automatic TLS on a generated URL; custom domain is a DNS record plus a click |
| First green deploy + debugging | 2–8 hours: read CI logs, fix the flaky test, re-push, repeat — 70% of Harness respondents say their pipelines are plagued by flaky tests and deployment failures | Minutes: first build streams logs to one place; failures point at app code, not plumbing |
| Preview env per PR | Hours to days to build (ephemeral namespaces, DB branching, teardown) — most teams never get here | Automatic: every PR gets a URL |
| Total | Roughly 1–3 days of skilled work, spread across a week of interruptions | Under 30 minutes wall-clock, under 10 hands-on |
The DIY column is not a strawman. It is the documented normal: platform engineers report new-service setup taking six days before a golden path exists, Jenkins alone eating 6–8 hours a month in maintenance after the pipeline is "done," and multi-day workflow-wiring sessions as recently as September 2026. The PaaS column is not fantasy either — Render's own walkthrough deploys a Rails app in five steps and under ten minutes, and the canonical golden-path story in platform engineering is a CLI that scaffolds repo, pipeline, namespaces, and observability in 90 seconds, down from six days.
Two things make the table representative rather than flattering. First, the DIY ranges assume a competent engineer who has done this before; a team touching Kubernetes RBAC or OIDC-to-cloud auth for the first time lands at the top of every range, or past it. Second, the PaaS column assumes the app fits the golden path — a standard web service or worker. Exotic builds (GPU images, monorepo surgery, air-gapped compliance) spill out of any zero-config path, and the checklist below is honest about where that line sits.
The headline number now has a mechanism. "Only 21% can do it in under two hours" is not a skills gap — it is an architecture gap. The 79% are paying the left column line by line, and every line is toil that produces no product value.
Why the 79% stay stuck: no golden path
If the DIY path were a one-time cost, teams would amortize it and move on. The Harness data says they can't, for structural reasons:
- 77% wait on others for routine delivery work. The pipeline is not self-service — shipping needs a ticket to the platform team, the security team, or whoever owns the Jenkins controller. Every handoff converts hours into days.
- 72% have hardly any standardized templates or golden paths. Each new service replays the full left column from scratch: fresh Dockerfile, fresh workflow YAML, fresh secrets wiring. There is no paved road, only trailblazing with a machete, per service.
- 78% admit to fragmented delivery toolchains. CI in one tool, CD in another, secrets in a third, observability in a fourth — each seam is a place where "under two hours" goes to die.
- 70% fight flaky tests and deployment failures. Even the pipeline you already built cannot be trusted, so every new environment inherits the debugging burden.
Add the AI accelerant and the picture sharpens. AI coding tools raised code output — 35% of teams deploy daily or more — without raising pipeline maturity one notch. Over half of respondents say AI-generated code causes deployment problems at least half the time, 86% say security and compliance checks need more automation to hold delivery timelines, and 71% of developers work evenings or weekends at least weekly on release tasks or production issues. Faster code through the same narrow pipe means more pressure on the pipe, more toil, and the burnout 75% of respondents report. The industry automated writing code before it automated shipping code. The 21% figure is the receipt.
This also reframes the 973x DORA gap. Elite-versus-low deploy frequency measures steady-state throughput once the pipeline exists. The 21% measures something upstream and more basic: how fast you can conjure the pipeline at all. A team can deploy daily from a pipeline it would take a week to rebuild — and that team is one replatform, one acquisition, one "we need a staging environment in the new region" away from discovering its elite metrics rest on artisanal infrastructure.
What "under two hours" actually requires
The teams inside the 21% are not typing faster. They removed rows from the left column until fewer than two hours of work remained. Concretely, that means five capabilities — a checklist you can audit any platform against:
- Buildpack-style auto-detection. The platform turns source into a runnable image without a checked-in Dockerfile: runtime detected, dependencies installed, image built by convention. This single capability deletes the biggest row in the table.
- Zero-YAML service definition. Connecting a repo — not authoring workflow files — creates the build-test-deploy loop. Branch pushes and PRs get builds and preview URLs by default.
- Managed TLS and domains. Every service gets HTTPS on a generated URL automatically; custom domains cost a DNS record, not a certificate-renewal side project.
- Ephemeral environments. Preview deployments per PR with isolated data, created and torn down without human steps.
- Golden-path templates for the escape cases. Standard service types (web, worker, cron, static) as one-click templates — the 72%-missing piece — so the second service costs minutes, not another trailblazing expedition.
Now the honest caveats, because "zero-config" has a boundary and pretending otherwise is how teams pick the wrong tool:
- If you already paid the tax, keep the receipt. A team with a mature, templated platform — real golden paths, paved-road CI — is already inside the 21%. Ripping out working infrastructure to chase a marginally simpler deploy is negative-value work.
- Exotic workloads need escape hatches, not magic. GPU images with custom CUDA layers, regulated builds with pinned hermetic toolchains, monorepos with bespoke orchestration — these need Dockerfile support and raw YAML access. Judge a PaaS by its escape hatches as much as its happy path: the good ones (Render, Heroku, and the self-hosted alternatives) accept a Dockerfile when buildpacks don't fit.
- Compliance-heavy shops trade setup speed for control. If every image must come from an approved base with signed provenance and every deploy needs a four-eyes approval, some left-column rows are load-bearing. The goal there is templating them, not deleting them.
- Someone still owns the platform. Git-push PaaS moves the toil from every product team to one platform surface — which still needs operating, upgrading, and securing. Self-hosting that surface on your own machines keeps the data and the bill under your control, but "zero-config for developers" and "zero-ops for everyone" are different claims. Don't confuse them.
The through-line: the 21% club has one admission ticket, and it is not talent. It is refusing to pay per-service setup toil — by template, by platform, or both.
The pipeline is the product now
Step back and the 2026 surveys tell one story in two numbers. DORA's 973x gap says steady-state delivery separates winners from laggards by orders of magnitude. Harness's 21% says the ability to create delivery capacity is scarce even among teams that ship daily. AI coding widened both gaps at once: code got cheap while shipping stayed artisanal, and the teams feeling it are working weekends to keep the pipe unclogged.
The direction of travel is clear. Pipelines are becoming platform features — declared, templated, and self-service — rather than per-service craft projects. The teams that get there stop answering "how long to stand up a pipeline" with a shrug and a sprint plan, and start answering with a stopwatch reading in minutes. The setup tax is optional. It just doesn't feel optional until you've seen the other column.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources
- Harness, "State of DevOps Modernization 2026" (survey of 700 engineering practitioners and managers by Coleman Parkes, February 2026): press release and DevOps.com coverage by Mike Vizard
- DORA elite-vs-low benchmarks (973x deploy frequency, 6,570x faster recovery): Teleport DORA guide, Middleware 2026 roundup
- Golden path case study, 6 days to 90 seconds: Varun Varde, April 2026
- "Two days wiring up
.github/workflows/": Ronik Dedhia, September 2026 - Jenkins maintenance cost, 6–8 hours/month: CI tool comparison experiment, 2026
- Rails on Render in under 10 minutes, 5 steps: Altcademy walkthrough
- Buildpacks vs Dockerfile tradeoffs: Google Cloud practitioners guide
