Part of The OPC Manual · By Adine Tjeenk Willink
Section 2.4 described the Stratum stack as a snapshot. This section is the framework underneath it: how to decide whether to add a tool, when to add it, and when to drop one. The framework is what survives across companies; the tools change.
The default state of an OPC stack is: nothing.
This sounds obvious and is widely ignored. The instinct, when starting a company, is to build the stack first — pick the CRM, pick the project management tool, pick the email client, pick the design tool, pick the AI tool, pick the analytics tool. Two weeks in, you have spent fifteen hours configuring software and have produced no commercial output.
The correct starting position is empty. Each tool is added one at a time, in response to a specific bottleneck, with a clear test for whether it stays. Tools are not infrastructure investments — they are responses to friction.
Before adding any tool to the stack, run it through four questions. Failing any one is a reason to wait.
Question 1 — What specific bottleneck does this resolve?
Not "this would be useful" — what concrete piece of work is currently slow, expensive, or impossible without it? If the answer is a hypothetical bottleneck ("once we scale, we will need this"), the tool waits. The OPC stack is built for the company you are running today, not the company you might be running in two years.
Question 2 — Can AI plus existing tools cover this for now?
Most tools that founders reach for can be partially or fully replaced by AI plus a tool already in the stack. A dedicated CRM can usually be replaced by a structured database in your existing knowledge base for the first 50 active deals. A dedicated marketing automation tool can usually be replaced by Clay plus AI plus Gmail drafts. A dedicated project management tool is rarely needed at one or two people. If AI plus what you already have can cover 80% of the use case, the additional tool is not yet justified — the marginal capability does not pay for the marginal complexity.
Question 3 — Does this make revenue more likely or prevent a compliance failure?
This is the single highest-bar test. Tools that produce neither revenue nor compliance protection do not belong in an OPC stack until much later, regardless of how reasonable they sound. "Productivity" tools, "team collaboration" tools, "insights" tools — all of these compound complexity without compounding output. The stack stays lean by holding this line.
Question 4 — What is the trigger to drop this tool again?
Every tool that comes in needs an exit condition. Not because you expect to drop it, but because the act of writing the exit condition forces you to articulate why it is in the stack at all. "We will drop this if X" is the discipline that prevents tools from outliving their usefulness. Tools without exit conditions accumulate. Tools with exit conditions get pruned.