Every OPC needs a stack. The question is not whether to have one — it is which tools, at what cost, added in what order.
The wrong approach is to tool up for the company you want to be in two years. You end up paying for capability you cannot use, and spending more time configuring software than doing the work the software is supposed to support.
The right approach is to start with the minimum that covers your actual needs today, and add tools at defined milestones — not because they sound good, but because a specific bottleneck has appeared that a specific tool would resolve.
This is the Stratum stack as it currently stands. It is a live example, not a recommendation. Your stack will be different. But the logic behind the decisions is transferable.
Buy only what generates revenue or prevents a compliance failure. Everything else waits.
That is the one-line test. Before adding any tool, the question is: does this make revenue more likely, or does it protect against something that could cost more than the tool? If neither, it waits.
The secondary test is the team constraint: nothing gets added to the stack until the founder and AI cannot cover it between them. When a gap appears that the two cannot fill, that is when a tool conversation happens. Not before.
This applies to product build too. The instinct is to hire a developer or engage a technical partner the moment you need something built. The right instinct is to build it yourself with a tool like Lovable first. Not because it produces production-grade infrastructure — it doesn't — but because it produces something more valuable at this stage: proof. Proof that buyers want it, proof that the interaction model works, proof that the use case is real. You bring in a technical partner when that proof exists. Not before.
Before the tool list, the model. The stack is organised around three layers:
Input → Brain → Output
What connects the layers is not a separate automation tool. It is the AI layer itself: Claude is connected to the other tools directly — it reads meeting context and prospect data, writes to the knowledge base, and drafts into the inbox — so information moves between layers inside a working session rather than through scheduled scenarios. (The mechanics of this are in 4.3.)
Every tool in the stack has a defined place in this model. If a tool doesn't fit cleanly into one layer, that is a signal it may not belong.