# Productizing Infrastructure: what surprised me most

> What cutting enclave deployment from two weeks to two hours taught me about one codebase, fleet operations, and saying no to forks.

- Published: 2025-09-19
- Tags: Infrastructure, Product, Leadership
- Source: https://stevenfoerster.com/notes/productizing-infrastructure/

GovCon Enclave began with a deployment process that took roughly two weeks. Each new environment required enough manual work that growth naturally implied more delivery engineers, more opportunities for drift, and more customer-specific knowledge living in individual heads.

The obvious response was to staff around the process. We made the opposite bet: spend the engineering time on one automation framework until an enclave could be deployed repeatably in about two hours.

That decision taught me what it actually means to turn infrastructure into a product. The automation mattered, but the difficult part was defining what had to stay identical, what customers were allowed to vary, who owned an environment after deployment, and how upgrades reached a growing fleet without creating forks.

## One codebase meant saying no

Every customer had legitimate requests. Many would have been easy to satisfy with a local patch or a one-off configuration branch. Each yes would also have created another system to test, document, upgrade, and support.

We treated customer needs as candidates for the product rather than instructions for a bespoke environment. If a change belonged, it entered the shared platform and every applicable enclave inherited it. If it did not belong, we declined it.

That was not always the easiest commercial conversation. It was the choice that kept fifty-plus production environments on one operating model instead of turning the company into a consultancy with fifty subtly different deployments.

## Deployment time was only the visible metric

Reducing two weeks to two hours made the result easy to explain. The more important change was what repeatability did to the rest of the company.

A deployment stopped depending on which engineer remembered which sequence. Security controls became code that could be reviewed and applied consistently. The maintenance team could reason about a fleet because the environments shared a known shape. Evidence for assessment came from enforced platform behavior instead of a separate manual story about how each customer was configured.

The deployment metric was evidence that the product boundary had become real, but it was only one piece of the product.

## The support model had to be designed too

Infrastructure is not finished when it installs successfully. Someone has to recognize drift, handle failed upgrades, investigate alerts, and know when a problem belongs to the shared platform rather than the customer environment.

That required runbooks, fleet-wide visibility, clear ownership between engineering, development, and maintenance, and enough training that routine operation no longer routed through me. Those investments competed with feature work, but without them the automation would only have produced environments faster than the company could safely operate them.

## The part that surprised me

The hardest product decision was not technical. It was protecting the shared system from short-term exceptions while customers were waiting and the manual path was still available.

Automation demanded months of investment before the payoff was obvious. A one-off request could produce revenue immediately. Training someone thoroughly took longer than doing the task myself. Productizing the platform meant repeatedly choosing the slower-looking option because it was the one that could compound.

By the time GovCon Enclave became the core platform behind Rimstorm's acquisition, its value was a repeatable promise, not a collection of Kubernetes manifests or an installer: one product, deployed and operated by a small team, with controls that survived across the fleet.

The full architecture, leadership decisions, and outcomes are in the [GovCon Enclave case study](https://stevenfoerster.com/projects/govcon-enclave/).