New Blog Post! The Citizen Developer
Read hereThe MVP is easy: a form that calls a Terraform module and provisions a database takes a sprint. Everything after it is a reinvention: access control, policy, state and secrets, audit, a portal nobody owns.
Every month spent rebuilding those is a month taken from the cloud services your developers need and the day-2 work that keeps them running.
10
Systems a platform team must build before the portal is useful
54
Engineer-months for a team of three over 18 months
$200K
Fully loaded cost per engineer per year
$900K
Year-one total for the build: 3 engineers over 18 months
A request comes in from a form, resolves into infrastructure, runs through policy, executes, and shows up in a portal with an owner. Each step is a system, and Massdriver ships all ten out of the box. Estimates are engineer-months for a first production version, not the ongoing maintenance.
| Component | What you build | Engineer-months |
|---|---|---|
| Catalog | A registry of approved modules with versions, ownership, and release channels, so a fix reaches every consumer. | 5 |
| Form generation from module schemas | Turn each module’s variables into a validated form developers can fill in without reading the Terraform. | 5 |
| Dependency resolution | Wire outputs of one module into inputs of the next, in order, across environments, and detect what a change affects. | 6 |
| Policy gate | Evaluate compliance and organizational rules against the plan before apply, with a place to store and version the rules. | 5 |
| Pipeline execution | Run plan and apply on demand, isolated per deploy, with retries, logs, cancellation, and concurrency limits. | 8 |
| State and secrets handling | State storage, locking, backups, and secret injection that never writes a credential to a log. | 6 |
| RBAC | Who can deploy what, where, scoped by team and environment, kept in sync with the identity provider. | 4 |
| Audit | Every change recorded with proposer, approver, diff, and result, exportable for an auditor. | 3 |
| The portal | The UI developers see: the catalog, the environment graph, deploy status, ownership, and every permission screen behind it. | 8 |
| Drift and import | Detect resources that changed outside the platform and bring existing infrastructure under management without a rebuild. | 4 |
| Total | Three engineers for eighteen months, before maintenance starts. | 54 |
Three platform engineers at $200,000 fully loaded per year, for eighteen months, is $900,000 in salary, before the cloud bill for running the platform, the tooling, and the product work those three engineers did not ship.
3
Platform engineers on the build, full time
$200K
Fully loaded cost per engineer per year
18 mo
To a first production version of all ten systems
$900K
3 engineers x $200,000 x 1.5 years
After the first version ships, the platform becomes a product with one customer, your own company, and no product team to run it.
The pipeline runner, the state locking, and the dependency resolver were one person’s mental model. Their replacement spends the first quarter reading code instead of shipping modules.
A new database engine, queue, or cloud region each needs a schema, a form, a policy, and a pipeline change, and the backlog of requested modules grows faster than the team can add them.
Rules end up split between the form validation, the pipeline, and the Terraform, so when an auditor asks what is enforced, the answer takes a week to assemble and differs from the last one.
The portal was the visible deliverable, so it shipped first and best. In year two it lags the backend, developers stop trusting the status it shows, and requests come back through Slack.
Building is reasonable under a narrow set of conditions; outside them, the ten systems above become a second product your company did not plan to fund.
| Your situation | Build | Buy |
|---|---|---|
| Modules | Fewer than about twenty, so one person can hold the catalog in their head. | Dozens or hundreds, across teams that do not talk to each other. |
| Clouds | One cloud with one account structure and one IAM model. | Two or more clouds, or Kubernetes plus a cloud, or an acquisition that brought its own. |
| Teams | One engineering team consumes the platform and one team runs it. | Several product teams, business units, or subsidiaries need the same guardrails. |
| Compliance | No audit regime, and nobody asks who approved a change. | SOC 2, HIPAA, PCI, or a customer security review that asks for change records and access scopes. |
| Who builds it | Three engineers you can dedicate for eighteen months and keep on it afterward. | The same three engineers should be publishing modules rather than running a pipeline service. |
Massdriver is the ten systems in the table above, built once. Your infrastructure code and your cloud accounts stay where they are.
The Terraform, OpenTofu, and Helm your team already writes are the modules Massdriver publishes. Nothing is rewritten in a new language or a new spec.
Massdriver provisions into the AWS, Azure, and GCP accounts you own, with your credentials held by Massdriver and never handed to a developer or an agent. Your CI for application code is untouched.
Catalog, form generation, dependency resolution, pipeline execution, state and secrets, drift and import: Massdriver generates a pipeline per deploy from the module’s own schema.
Policy runs before every apply, access is attribute-based by team and environment, every change carries proposer, approver, diff, and result, and the portal ships with it.
Backstage is a good portal. Teams adopt it to get self-service, write a scaffolder template that calls CI that calls Terraform, and then discover they have built the smallest of the ten systems and still owe the other nine.
The catalog knows what exists and the scaffolder can start a job, but nothing in Backstage runs a plan, evaluates policy, holds state, or knows that a database depends on a network.
Massdriver publishes a Backstage plugin. Backstage stays the front door and catalog of record; Massdriver is the provisioning, policy, and audit layer behind it.
Mid-build teams are the ones we hear from most, and the hard part for them is admitting the math changed.
The months your team has already put in do not come back if you keep going. The question is which path costs less from today forward, and finishing a homegrown platform is rarely the cheaper one.
Whatever remains (hardening, the next integration, the security review, the next cloud) is new spend. Compare that bill to the cost of switching rather than to what you have already invested.
Your Terraform, Helm charts, and module conventions carry forward. Massdriver publishes the infrastructure as code you have already written instead of replacing it.
“Massdriver's platform has revolutionized our approach to infrastructure, saving us 89% of the time spent managing infrastructure.”
The questions platform leaders ask most when they weigh a homegrown build against buying Massdriver.
Time already spent does not come back whether you finish the build or switch. What matters is the cost from today forward: the remaining build work (hardening, integrations, security review, ongoing maintenance) against adopting a platform that already does it. For most teams the remaining build cost is larger than the cost of switching.
Three platform engineers at $200,000 fully loaded per year, for eighteen months. The per-component split is our estimate for a first production version of each system. Your numbers will differ; the point is that the portal is one of ten systems, and usually one of the smaller ones.
Yes. Your CI for application code is untouched. Massdriver takes over the infrastructure side: it generates and runs the provisioning pipeline for each deploy from the Terraform, OpenTofu, and Helm your team already writes.
No. Massdriver publishes the infrastructure as code you have already written as self-service bundles. Your platform team’s existing modules become the catalog developers provision from.
Most customers migrate incrementally. Run Massdriver alongside the in-house effort, move one team or one service at a time, and wind down the homegrown build once developers are self-serving through Massdriver. Resource import brings existing infrastructure under management without a redeploy.
A senior platform engineer costs about $200,000 fully loaded per year, and a production IDP needs three of them for the build and then to keep it running. Massdriver costs a fraction of one of those salaries, and those three engineers go back to publishing modules and improving the developer experience.
Massdriver supports AWS, Azure, GCP, and Kubernetes, and runs self-hosted inside your own boundary for regulated and high-security teams. See the Self-Hosted / On-Prem page for the deployment model.
Tell us your build timeline and team size. We put your numbers through the same arithmetic and show what switching saves.