The Plan Is Not the Schedule

I opened the preview site to a small group this week. Friends, colleagues, people whose opinions I trust. The feedback came in fast and in forms I didn’t expect.

The layout had problems I hadn’t seen. The Four Doors section — the part of the site that describes the four different kinds of people Quorum is built to serve — got called out directly: it wasn’t landing. Someone sharp looked at it and didn’t see themselves in it. The “what we do” section on the front page wasn’t clear enough. LinkedIn’s in-app browser doesn’t play nicely with basic auth, which I discovered when someone couldn’t load the preview at all.

The first reaction to all of it was the obvious one. I built this. I’ve been staring at it for weeks. I know what it means. That dissolved quickly into the only productive question: how much of this is signal, how much is noise, and what can I actually do about it?

I rewrote Four Doors. Fixed the layout. Killed the basic auth on the public-facing routes. The site is meaningfully better than it was a week ago because real people looked at it and told me where it was broken.

None of that was possible three weeks ago. The site wasn’t running on real infrastructure. There was no deployment pipeline to push changes through. Acting on feedback fast requires the ability to act fast — and that ability came directly from the decision to build the VM service layer when I did, not when the original plan said to.

The business needed it

I wear two hats here. I’m the person building the platform and I’m the person who has to go get clients. Those two people don’t always want the same thing at the same time.

The technical plan had Kubernetes as the prerequisite for almost everything. Site live on infrastructure? Gated on Ceph being healthy. Analytics? Gated on Ceph. Workflow automation? Gated on Harbor and ArgoCD. The logic was sound from a pure infrastructure standpoint — build the platform, then build on top of it.

But the business couldn’t wait on Ceph. Marketing, messaging, outreach, getting the site in front of real people — all of that needed to happen. You don’t get useful feedback from a preview URL behind basic auth that half your contacts can’t even load. You don’t learn what’s broken about your positioning until someone who doesn’t already understand it tells you it’s broken. The business needed an injection of perspective, and getting that perspective required having something real to put in front of people.

So the business said go. The question was whether the technical foundation could support that without compromising the standards that make the platform worth building in the first place.

It could. Because everything is automated.

Standing up six VMs, wiring a deployment pipeline, getting TLS termination working through a reverse proxy, migrating analytics data, deploying identity infrastructure — none of that required cutting corners. It required executing the same automation-first approach that’s been the standard from day one, just applied to a layer that wasn’t in the original sequence. The Ansible roles are idempotent. The GitHub Actions workflows are version-pinned and SOPS-encrypted. The backup architecture is deliberate. The ethos didn’t get compromised to move fast. It’s what made moving fast possible.

That’s the argument that collapses most of the objections — both technical and positioning. “We’re not ready” stops being true when the infrastructure discipline means you can stand up a production-grade service layer in a week and trust it. “This doesn’t fit the plan” stops mattering when the plan’s job is to get you to the right outcome, not to predict every step of the route.

The debt reframe

I called this technical debt earlier. I want to be more precise about what that actually means here.

When I stood up Authentik on a VM, I wasn’t deferring the right answer. I was choosing the right answer for that moment. The question of whether Authentik belongs on Kubernetes is now a question of value, not technical imperative. The VM-layer deployment has an operational plan. It’s backed up. It’s automated. It’s running under the same Ansible-driven, declared-state model as everything else in the infrastructure. There’s no gun to anyone’s head to migrate it.

That’s a different situation than debt. Debt implies you owe something. What I actually have is optionality — the ability to make a considered decision about what moves where and when, based on what that move is worth, not based on what the original plan said had to happen in what order.

The Ansible roles managing VMs and the Kubernetes manifests managing cluster workloads aren’t in tension. They’re both expressions of the same operating principle at different layers: automation-first, declared state, idempotent operations, no manual exceptions. The interfaces are different. The contract is similar enough to matter. And having good tools with clean boundaries at each layer is exactly what makes it possible for the business to move without waiting for the next planning cycle to catch up.

We might migrate Authentik to Kubernetes. We might not. We might use Ansible to act on the Kubernetes cluster over time. None of those are decisions that need to be made right now, and the fact that they don’t is the point. The decisions got easier, not harder. That’s what good infrastructure work produces.

The plan is a negotiation

I started this build with a 16-week milestone plan. That plan is now 17 weeks, compressed back close to the original target by making better sequencing decisions mid-build. It will probably change again.

That’s not a failure of planning. A plan that never changes is a plan that isn’t being used. The plan’s job is to hold the structure — the sequence of dependencies, the logical ordering of work, the high-level milestones that tell you whether you’re heading in the right direction. The schedule’s job is to be adjusted when you learn something new.

What I learned this week is that outreach pressure is a forcing function, and forcing functions are often where the best decisions get made. The site is live on real infrastructure because it had to be. The feedback is real because real people looked at it and told me where it was broken. The service layer is running because the automation was there to support it without compromising the standards it was built on.

The next time someone asks why you’re running Ansible on VMs when Kubernetes exists — or why the migration hasn’t happened yet — the answer is that the question is wrong. The question isn’t which tool wins. The question is what the right tool is for this layer, at this moment, given what the business actually needs. When the interfaces are clean and the operations are automated, the answer can change. That’s the point.

Good infrastructure decisions don’t lock you in. They open things up.