If you use someone else’s task manager, you inherit all of their abstractions. In a world where LLMs make software a solved problem, the cost of ownership has flipped.
The Dependency Trap
Every control plane comes with opinions. A task runner, an orchestration framework, a CI system, a deployment platform. The moment you adopt one, you absorb its model of the world: its notion of a “task”, its definition of “success”, its retry semantics, its concurrency model, its error boundaries.
This is not neutral. These abstractions shape what you can express. They constrain the solution space before you’ve even defined the problem.
When the abstraction fits your domain, this is leverage. When it doesn’t, it’s a tax you pay on every decision.
Most teams never notice because they’ve been trained to work around the mismatch. They build shims, write adapters, maintain escape hatches. They call this “integration”. It’s actually the cost of renting someone else’s primitives.
The Old Calculus
Historically, building your own control plane was expensive and rarely justified. The reasoning was sound:
- High upfront cost. Writing a task scheduler, a state machine, an orchestration layer from scratch takes months.
- Maintenance burden. You own every bug, every edge case, every upgrade.
- Opportunity cost. Time spent on infrastructure is time not spent on product.
So you adopted the popular framework. You accepted its tradeoffs. You shaped your architecture around its assumptions. And for most of software history, this was the correct call.
The calculus has changed.
LLMs Made Software a Solved Problem
Not in the sense that all software is trivial. In the sense that the marginal cost of producing correct, working code has collapsed.
If you can specify what you want precisely enough, you can point recursive compute at the problem and get a working implementation. Not a prototype. Not a sketch. A working system with tests, error handling, and documentation.
This changes the build-vs-buy equation at a fundamental level.
The old argument against building your own was: “It will take you six months and you’ll get it wrong.” The new reality is: “It will take you a week and you can iterate on every primitive.”
The bottleneck has moved from implementation to specification. If you know what you want, you can have it. The constraint is clarity of thought, not engineering bandwidth.
What You Actually Control When You Own the Plane
When you build your own control plane, you own:
The primitives. What is a “task”? What is a “step”? What constitutes “done”? These are not universal truths. They are design decisions that should reflect your domain, not someone else’s.
The failure semantics. How do retries work? What happens on partial failure? What gets rolled back? Every framework answers these differently. Your domain has specific answers that no generic framework can anticipate.
The observation model. What do you measure? What do you trace? What signals matter? Generic observability gives you generic insight. Domain-specific observability gives you leverage.
The evolution path. When requirements change, and they always change, you modify your system directly. No waiting for upstream releases. No working around deprecated APIs. No rewriting your architecture because the framework authors changed their mind about state management.
The composition model. How do pieces connect? What are the boundaries? Where does data flow? These decisions cascade through everything. Inheriting them from a dependency means your architecture is shaped by someone else’s priorities.
The Weird Moment We’re In
We are in a transitional period where this is simultaneously obvious and counterintuitive.
Obvious because anyone who has fought a framework knows the pain. You spend more time working around the abstraction than working on the problem. The framework that saved you three months on day one costs you six months over the next year.
Counterintuitive because the instinct is still to reach for the established tool. “Don’t reinvent the wheel” is deeply embedded. It was good advice when wheels were expensive to make. It’s less compelling when you have a machine that produces wheels to spec on demand.
The upfront cost is still real. You need to think clearly about what your control plane should do. You need to specify the invariants, the state transitions, the failure modes. This is hard work.
But it’s the right kind of hard work. It’s the work that produces understanding. And understanding is the asset that compounds.
When to Build, When to Borrow
This is not a universal prescription. Not everything needs a custom control plane.
Build your own when:
- The control plane IS the product (orchestration systems, agent frameworks, workflow engines)
- The abstraction mismatch costs more than the implementation
- You need to evolve primitives faster than the upstream can
- Correctness in your domain requires semantics the framework can’t express
- You’re building something that needs to compound over years
Borrow when:
- The domain is well-understood and stable (HTTP servers, database drivers, crypto libraries)
- The abstraction matches your domain closely enough that shims are minimal
- The community provides value beyond the code (security patches, ecosystem, knowledge base)
- You genuinely don’t need to modify the primitives
The test is simple: how much time do you spend working around the framework vs. working with it? If the answer is “more than a third”, you’re paying rent on someone else’s opinions.
The Compound Argument
Building your own control plane is a compound bet.
The first implementation is more expensive than adopting. But every subsequent system you build on top of it is cheaper, because the primitives already match your domain. You’re not translating between your mental model and the framework’s mental model. You’re just building.
This is the same logic behind investing in infrastructure over features. The individual feature ships slower. The factory that produces features gets faster.
When you own the control plane:
- New capabilities are additive, not adversarial
- Debugging goes straight to your code, not through three layers of framework abstraction
- Onboarding means understanding your domain, not someone else’s framework
- Every improvement to the plane improves everything that runs on it
The Real Leverage
The deepest version of this argument is about cognitive ownership.
When you use someone else’s control plane, you think in their categories. Their abstractions become your mental model. You stop asking “what should a task be?” and start asking “how does this framework define a task?”
That’s a subtle but critical loss. The ability to define your own primitives is the ability to think clearly about your domain. Outsourcing that to a dependency is outsourcing your capacity to reason about the problem.
In a world where LLMs handle implementation, the scarce resource is precise thinking about what to build. Owning your control plane forces that precision. Renting it lets you avoid it.
One compounds. The other doesn’t.
