Run a one-person company with AI.

Let's start with the simplest possible definition, and then make it precise.

An OPC — One Person Company — is a company built around a single decision-maker, where AI handles the execution layer that would otherwise require a team.

It is not a freelance practice. It is not a personal brand. It is not a side project. It is a company — with a commercial pipeline, a product or service, an operating system, and real revenue potential — run by one person who has made a deliberate architectural choice: to build leverage rather than headcount.

The word that matters in that definition is deliberate. An OPC is not what happens when you haven't hired anyone yet. It is what happens when you decide that the traditional answer — hire people to grow — is the wrong answer for what you are building and how you want to live.

Where the Term Comes From

The term OPC is emerging simultaneously from two directions.

In China, it has become a formal policy movement. As of mid-2025, over 16 million one-person limited liability companies were registered nationwide, with nearly 3 million new registrations in the first half of that year alone — a 47% year-on-year increase ( China Daily). Cities from Shanghai to Shenzhen are building dedicated OPC communities, offering computing infrastructure, legal support, funding, and co-working space specifically for solo AI-powered founders. The formula being discussed in these communities is direct: one person + AI = a company.

In the West, the same phenomenon is happening without the label. Solo founders are quietly building companies that generate millions in revenue with no full-time team. The share of new US startups launched by a solo founder has climbed from roughly a quarter in the late 2010s to over a third by 2024 ( Carta, Solo Founders Report). The model is not fringe — it is rapidly becoming the default starting point for a new generation of builders.

Both streams are converging on the same structural insight: AI has changed what one person can hold.

What AI Actually Changed

To understand OPC, you need to understand what AI actually changed — not the surface-level version ("AI helps you work faster") but the structural version.

For most of economic history, scaling a company meant scaling people. If you wanted more output, you hired more workers. If you wanted more capability, you hired more specialists. The minimum efficient size of a company — the smallest unit that could do serious work — was constrained by how many roles a human could plausibly hold at once.

AI broke that constraint.

A rigorous analysis of this shift was published in February 2026 by economists Christian Catalini (MIT), Xiang Hui, and Jane Wu in a paper titled Some Simple Economics of AGI ( arxiv.org/abs/2602.20946). Their core argument: as AI drives the cost of execution toward zero, the binding constraint on growth is no longer intelligence or skill — it is human verification bandwidth. The capacity to validate, audit, and take responsibility for outputs.

The authors frame this as two racing cost curves: an exponentially falling Cost to Automate — the price of getting AI to do something — and a biologically bottlenecked Cost to Verify — the price of a human checking, approving, and standing behind that output. As these curves diverge, a Measurability Gap opens: the growing distance between what AI can execute and what humans can afford to verify.

This is not an abstract economic observation. It is the foundation of the OPC model.

The authors summarise their own working method in the paper's acknowledgements with a line that is worth quoting directly: "They provided scalable execution, we provided intent and verification." Eight words. That is the OPC model.

The Human / AI Split

So what does this mean in practice? What does the human do, and what does AI do?

Every company — regardless of size — runs on the same five functional layers. What changes in an OPC is who or what handles each one.

What you do — always, irreducibly:

Strategy and vision. What the company is for, what it is building toward, what it will and won't do. No AI can set this. It can help you think, but the judgment is yours.

Relationships. The calls, the trust, the reading of a room, the follow-up that feels personal. Enterprise buyers do not sign letters of intent with AI. They sign them with people they trust.

Verification. This is the Catalini insight: someone has to stand behind the output. Check the proposal before it goes out. Approve the financial summary. Review the research. You are the human-in-the-loop — and that role is not a bottleneck, it is your value.

Taste. What looks right, what sounds right, what feels off. AI can generate. It cannot curate with your specific sensibility and market understanding.

Accountability. You carry the consequences. This is not a burden unique to OPC — it is true of any founder. But in an OPC it is explicit: there is no one else to blame and no one else to protect you. That clarity is actually an advantage.

What AI does — reliably, at scale:

First drafts of everything — proposals, emails, research summaries, decks, documentation. Administration — scheduling, tracking, invoicing, reminders, financial categorisation. Research — market scans, competitor analysis, background on prospects, regulatory updates. Content — social posts, newsletters, case studies. Process — checklists, SOPs, templates. Memory — storing, retrieving, and connecting information across time and sessions.

The pattern is consistent: AI handles tasks where the output can be checked and corrected. You handle tasks where the output is the judgment — where there is no obvious right answer to verify against, only your experience, your relationships, and your accountability.

What OPC Is Not

Three things worth naming clearly, because the confusion costs people time.

OPC is not doing everything yourself. The whole point is that you are not doing everything. You are deciding everything. The execution — the first drafts, the research, the admin, the tracking — is largely handled by your AI stack. If you are doing everything yourself, you are not running an OPC. You are just burnt out.

OPC is not a stepping stone. The dominant assumption in startup culture is that solo founder status is temporary — something you grow out of as fast as possible by raising money and hiring people. For some companies, that is the right path. But OPC is a deliberate model, not a waiting room. You are not failing to grow. You are choosing to grow differently.

OPC is not only for small ambitions. The Catalini paper identifies a structural force it calls the collapse of the firm's minimum efficient scale — the smallest viable company is getting smaller as AI absorbs more execution. One-person companies are already competing with and winning against firms with twenty, fifty, a hundred people. The model does not cap your ceiling. It raises it.

The One-Paragraph Definition

Here is the definition you can use when someone asks what you are building:

An OPC — One Person Company — is a company built around a single decision-maker who uses AI to handle the execution layer that would otherwise require a team. The human provides intent, judgment, relationships, and verification. AI provides scalable execution. Together, they can do the work of a company. The model is not a compromise. It is a deliberate architectural choice — one made possible by a structural shift in what one person can hold.

→ Next: 1.2 Why now: what AI actually changed

The question worth asking before you commit to any model is: why is this the right moment? New ideas fail not because they are wrong but because they arrive too early or too late. So before you build an OPC, you should understand why 2025 and 2026 are the specific years when this became real — not theoretical, not aspirational, but actually executable.

Four things converged. Each one alone would have been interesting. Together, they are a structural shift.

1. The Tools Became Genuinely Good

For most of the last decade, AI assistants were impressive in demos and unreliable in practice. They hallucinated. They were inconsistent. They required so much correction that the time saved on the first draft was lost in the editing. Using them for real work felt like managing an enthusiastic but unreliable intern — possible, but not necessarily net positive.

That changed decisively between 2023 and 2025. The jump in capability — particularly in reasoning, instruction-following, and context retention — moved the tools from novelty to workhorse. The test is simple: can you give it a real task, from your real work, and get something you can actually use with one round of editing? For a growing list of tasks, the answer is now yes.

This is not about a single breakthrough. It is about the compounding of many improvements — longer context windows, better reasoning, multimodal input, tool use, memory — reaching a threshold where the tools are reliable enough to build a system around. An OPC is a system. You cannot build a system on unreliable components. The components are now reliable enough.

The specific tools that matter for an OPC — a strong language model for thinking and writing, a knowledge base for memory, a CRM for pipeline, a light automation layer for connecting them — all crossed usability thresholds within the same two-year window. This is not a coincidence. It is an ecosystem maturing together.

2. The Cost Floor Collapsed

Building a company used to require significant upfront investment in people and infrastructure. A solo founder who wanted a research capability hired a research analyst. A founder who wanted a marketing function hired a marketing manager, or a freelancer, or an agency. A founder who wanted operations support hired an operations person. These were not luxuries — they were functional requirements.

The cost floor for those capabilities has collapsed.

What used to require a €60,000 salary or a €5,000/month agency retainer now requires a €200/month AI subscription and the judgment to use it well. That is not a marginal improvement. It is a category change. It means a one-person company can access capabilities that previously required either significant funding or significant compromise.

This changes the fundraising logic entirely. The traditional pressure to raise capital — to hire people to build capability — is dramatically reduced when capability can be accessed at near-zero marginal cost. An OPC can reach the point of genuine commercial traction before needing outside capital. That is a new thing. It was not possible five years ago in the same way.

It also changes the risk profile of going independent. The downside of betting on yourself is smaller when the infrastructure costs are lower. You do not need to generate €150,000 in revenue to cover a team before you can pay yourself. The breakeven is much lower — and therefore the bet is much safer.

3. The Minimum Viable Company Got Smaller

Related to cost, but distinct: the smallest unit that can do serious, credible, enterprise-grade work has shrunk.

This matters because enterprise buyers — pharma companies, financial institutions, large corporates — historically bought from companies that looked like companies. A vendor with one employee was a vendor with a credibility problem. The question was always: what happens if you get hit by a bus? What is the continuity plan? Where is the team?

Those questions have not disappeared. But they are easier to answer now. An OPC with a well-documented operating system, AI-assisted delivery, and clear partner relationships can present a credible continuity argument. The outputs — the proposals, the research, the deliverables — look and read like the output of a team, because in a functional sense, they are. The AI is part of the team.

This is the structural force the Catalini paper calls the collapse of the firm's minimum efficient scale. The smallest viable company is getting smaller in every sector where execution can be partially automated. In knowledge-intensive sectors — consulting, data, research, strategy, creative — that process is well underway.

For an OPC founder selling to enterprise buyers, this means: you are arriving at the right moment. The scepticism is still there, but it is softening. And the founders who establish credibility now — before the model is normalised — will carry a first-mover advantage into a market that is about to get crowded.

4. The Cultural Shift Is Real

Something less tangible but equally important: the stigma around solo founding is fading.

For most of the startup era, the solo founder was a transitional figure — the person who hadn't found a co-founder yet, who hadn't raised enough to hire, who was managing alone until the real company started. The ambition was always to graduate out of it. Building a company of one was a phase, not a destination.

That assumption has quietly inverted. The founders who are choosing OPC are not choosing it because they cannot do anything else. They are choosing it because they have seen what building a team actually costs — in time, in energy, in equity, in the specific kind of exhaustion that comes from being responsible for other people's livelihoods as well as your own. They have done the calculation and decided the trade-off is not worth it.

This is particularly visible among women, for reasons the introduction to this manual explains. But it is not limited to women. The generation of founders entering the market now has watched the previous generation burn out in pursuit of growth-at-all-costs. They are choosing differently. They are building companies that fit their lives, not lives that fit their companies.

The OPC model validates that choice — and now gives it a serious operational framework to stand on.

The Window

These four forces — tool maturity, cost collapse, shrinking minimum viable company, cultural shift — are all moving in the same direction at the same time. That alignment does not happen often.

It creates a window. Not indefinitely open. As the tools commoditise and the model normalises, the advantage of being early will compress. The founders who build OPCs now — who figure out the operating system, establish the client relationships, and develop the judgment that AI cannot replicate — will have something that later entrants will have to work much harder to acquire.

The window is open. This manual is about how to walk through it.

Part of The OPC Manual · By Adine Tjeenk Willink

The shift from AI-as-tool to AI-as-team-member is the single most important conceptual move in the OPC operating model. It changes how you brief the work, how you govern the work, how you review the work, and how the work compounds over time. This section is about that shift — what it means in practice, what it requires structurally, and what it does not change.

Why "tool" is the wrong frame

When AI is framed as a tool, the founder's mental model is tool-shaped. You open it, you ask it something, you get an answer, you close it. The interaction is transactional and stateless. Each session starts from zero. The output quality is bounded by what you remembered to put into the prompt.

This is not wrong, exactly. It is just a small fraction of what AI can do, and it is the fraction that produces the smallest compounding effect on the company.

When AI is framed as a team member, the mental model is colleague-shaped. A team member has context — they know the company, the customers, the rules, the recent decisions, the in-flight work. A team member operates inside a defined role with defined permissions. A team member is briefed on what to do and how to do it, and is reviewed against a defined output. A team member's work product is reusable and compounds: the third proposal is better than the first because the first informed the second.

Nothing about the underlying technology forces one framing or the other. The founder chooses. The OPC operating model chooses team-member, deliberately, because it is the framing that produces compounding leverage instead of one-off productivity.

What a team-member framing actually requires

Four structural commitments separate AI-as-tool from AI-as-team-member. Without these, the framing is aspirational; with them, it is operational.

1. A persistent context document. A single, maintained document that loads the company into every session — the legal entity, the commercial position, the active prospects, the working style, the rules. Every session starts by loading this document. The session does not start with "let me re-explain what the company does." It starts with the document already in scope. (Detailed in 7.3.)

2. Defined roles. AI does not do "everything." It does specific work, in specific modes, with specific expectations. Briefing prep is one role. Proposal drafting is another. Outreach copy is another. Financial narrative is another. Each role has its own conventions — input format, output format, voice, level of detail. The roles are written down. The founder pulls AI into the right role for the right work, the same way you would pull a colleague into a meeting where their expertise is relevant.

3. Explicit permissions and limits. AI as a team member with access to live tools — calendar, inbox, knowledge base — needs explicit rules about what it can read, what it can write, and what it can never do. Read freely. Write carefully. Send never without the founder. These rules live in the context document and are loaded at the start of every session. (Detailed in 3.2.)

4. A correction-and-learning loop. When AI gets something wrong, the correction does not stay in the session — it gets written into the context document as a rule for the future. This is the loop that makes AI compound. Without it, the same error recurs. With it, the error is paid for once.

These four together convert AI from a tool that produces sessions into a team member that produces continuity. The continuity is the asset.

The role catalogue

The roles AI plays in an OPC are not infinite. In my experience, they cluster into eight, and each one has a different operating mode.

The researcher. Pulls together what is known about a market, a competitor, a buyer, a regulatory framework. Operates best with a tightly scoped question, a defined output format, and clear sources. Bad at open-ended "tell me about X"; good at "produce a one-page brief on X with sources cited."

The drafter. Produces first drafts of structured outputs — proposals, decks, one-pagers, outreach sequences, internal docs. Operates best with a brief, an example of the desired voice, and a defined audience. The founder edits; AI does not finalise external work.

The pre-mortem partner. Stress-tests decisions before they are made. Operates best with a stated decision, a stated preferred option, and an explicit ask to surface failure modes. Used correctly, this role compresses what would otherwise require a board meeting into thirty minutes.

The reviewer. Reads a draft, a deck, a contract clause, a piece of strategy and pushes back. Operates best with a specific question — "what is weakest here?" — rather than a generic "what do you think?" Generic reviews produce generic feedback.

The synthesiser. Takes a pile of inputs — a meeting transcript, ten emails, three documents — and produces a structured summary or set of action items. Operates best when the inputs are clean and the output format is specified. The OPC's institutional memory is largely produced by this role.

The drafter-of-internal-systems. SOPs, templates, processes, checklists. The work that is necessary infrastructure but tedious to produce by hand. AI in this role takes the founder's lived experience and turns it into reusable structure.

The teacher. Explains a domain the founder needs to learn — a regulation, a technical concept, a financial mechanism. Operates best with the founder's current level of knowledge stated upfront, so the explanation is calibrated.

The operator. AI connected to live tools, executing defined actions: drafting an email in the inbox, surfacing the daily briefing, querying the knowledge base. This is the role with the highest stakes; it requires the most explicit permissions and the most disciplined governance.

The roles are not separate AIs. They are separate operating modes for the same AI, invoked by the founder. The founder's job is to know which role is needed for which work, and to brief AI accordingly.

The brief is the unit of work

In a tool framing, the unit of work is the prompt. In a team-member framing, the unit of work is the brief.

The difference: a prompt is a question. A brief is a piece of structured input that contains the role being invoked, the context, the deliverable, the format, and the success criteria. A prompt produces an answer. A brief produces work product.

A usable brief contains, at minimum:

The role — what kind of work is being asked for (researcher, drafter, reviewer, etc.)

The context — what AI needs to know about the company, the situation, the prior decisions; usually loaded automatically via the context document, with situation-specific additions

The deliverable — what specifically is being produced, in one line

The success criteria — what makes this output good vs. bad; the tests AI should run against its own draft before presenting it

The format — length, structure, tone, audience

Five lines or ten. Not paragraphs. The brief is the discipline of stating the work clearly. If you cannot write the brief, you do not yet know what you want — and AI will not figure it out for you.

The most valuable thing a founder can do in an AI session is spend the first three minutes writing the brief. The next ninety percent of the session is then much shorter and much sharper. The cheapest mistake in an AI session is to skip the brief and "just start." The output will look fine and will be subtly off, and the founder will not know why.

Session discipline

A team-member framing implies that AI sessions are managed work, not casual interactions. The session has a beginning, a middle, and an end, and each one has its own discipline.

Beginning. Load the context document. State the role and the brief. Confirm the success criteria before starting. If the founder cannot articulate success criteria, the session is not yet ready to start; the work is upstream.

Middle. AI works against the brief. The founder's job is to read what AI produces, push back where it is weak, request specific changes, and verify against the success criteria. Not to chat. The session is goal-directed.

End. Capture the output where it belongs (Notion, draft, doc, wherever). If anything went wrong, write the lesson — what AI got wrong, what should be added to the context document to prevent it next time. Close the session.

This is not bureaucratic. It is the difference between a session that produces a usable artefact and a session that produces forty minutes of conversation. The discipline takes practice; once internalised, it costs almost no overhead and produces dramatically better output.

What does not change

The team-member framing changes how AI is operated. It does not change three things, and conflating these is a common error.

Final responsibility. The founder is responsible for everything that leaves the founder's hands, regardless of whether AI drafted it. AI does not own a deliverable. The founder does.

Final judgment. AI is a competent debugger and a poor decider. It will tell you what is weak; it will not tell you what is right when the right answer requires gut, taste, or a read of a relationship that AI cannot have. The founder decides.

Send authority. Nothing leaves the company without the founder's hand on it. This is absolute. It is the line that separates AI-as-team-member (productive) from AI-as-autonomous-agent (not yet trustworthy at the stakes that matter).

These three are non-negotiable, regardless of how good AI gets. They are the founder's contribution to the partnership.

What goes wrong, and how to catch it

Three patterns to watch:

Context drift. The context document becomes stale. AI is operating off old assumptions — old prospects, old positioning, old rules — and producing output that looks fine but is subtly wrong. The fix: update the context document weekly, ideally as part of the operate-day rhythm. Stale context is the single most common reason AI quality degrades over time.

Role collapse. The founder asks AI to do everything in one session — research, draft, review, decide — and the output is muddled because the modes are mixed. The fix: one role per session, or explicitly switched roles within a session with the switch named out loud ("now switch to reviewer mode"). Mode discipline is what produces clean output.

Lesson erosion. AI gets something wrong. The founder corrects it. The correction does not get written into the context document. Two weeks later, the same error recurs. The fix: a Lessons Log inside the context document, updated after every meaningful correction. The discipline is small; the compounding is large. (Detailed in 7.3.)

The principle underneath

Framing AI as a team member is not anthropomorphism. It is a decision about how to organise the work so that the work compounds. A tool does work for you. A team member does work with you, against context that grows over time, under rules that improve over time, in roles that sharpen over time.

For an OPC, this distinction is the one that decides whether AI is a productivity gain (small, real, but bounded) or an operating model (large, compounding, defining). The OPC operating model chooses the second framing — deliberately, structurally, and from day one.

The rule is short: persistent context, defined roles, briefed sessions, written lessons.

Get that right and AI becomes the team that the company does not have to hire. Get it wrong and AI becomes a faster way to do the same work the founder was already doing — useful, but not transformative.

→ Next: 2.2 Building the stack: what to add and when

Part of The OPC Manual · By Adine Tjeenk Willink

Every OPC needs a stack. The question is not whether to have one — it is which tools, in what order, at what cost. This section is the framework. The decision rules for adding new tools are in 2.3. The specific Stratum example is in 2.4.

Why this section exists

Most stack advice for early-stage companies is wrong for an OPC. It is written for teams. It assumes someone other than the founder will configure the tools, train new joiners on them, and absorb the cost of switching when the choice turns out badly. None of that applies when there is one person doing all of it.

The OPC constraint is different. The founder is also the IT department, the procurement function, the integration layer, and the person who has to remember why a tool was chosen six months later. Every tool added to the stack is paid for not just in subscription cost but in attention, context-switching, and the ongoing work of keeping it useful.

A well-built OPC stack is small. Smaller than it should be on paper. The discipline is in what is deliberately not in it.

The organising principle

Buy only what generates revenue or prevents a compliance failure. Everything else waits.

This 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 AI and the human layer cannot cover it. When a gap appears that those cannot fill, that is when a tool conversation happens. Not before.

The two tests catch most premature additions. The third test — covered in 2.3 — is the trigger: every tool on the "not yet" list should have a defined event that would justify adding it. "When we hit fifty active deals." "When we sign the first enterprise contract." "When the founder is spending more than two hours a week on this manual step." Without a trigger, "not yet" becomes "never" — or worse, "whenever I feel like it."

The three-layer mental model

The OPC stack organises around three layers. Every tool belongs to exactly one. If a tool does not fit cleanly into one layer, that is a signal it may not belong.

Input. Where data enters the system. Meeting capture, lead enrichment, prospect research, document intake.

Brain. Where information is stored, processed, and turned into decisions. The knowledge base. The AI layer. The CRM if it is separate from the knowledge base.

Output. Where decisions become action. The pipeline tool. The accounting and invoicing layer. The contract signing layer. The communication layer.

What connects the layers is the AI layer itself: a general-purpose AI connected to the other tools moves data between them inside a working session, rather than a separate scheduled automation platform wiring them together in the background. (More on this in 4.3.)

The value of the mental model is not the labelling. It is what the labelling exposes. If a layer has six tools in it, that layer is over-built. If a layer is empty, the work in that layer is happening manually — which may be fine, or may be a signal that the next tool to add belongs there.

What every OPC stack needs

The minimum viable OPC stack has five things. Anything beyond this is optional and should pass the organising-principle test before being added.

A general-purpose AI layer. Not a task-specific tool — the intelligence backbone. Used in structured sessions for research, drafting, analysis, planning. This is the highest-leverage tool in the stack. Pick one and commit to it. Multiple AI tools used shallowly produce worse output than one AI tool used deliberately.

A knowledge base that is also an operating system. One place where decisions, context, SOPs, and pipeline live. The exact tool matters less than the discipline of using it as the single source of truth. Most OPCs use Notion. The reasoning and architecture is in 3.2.

A meeting capture layer. Every call automatically transcribed and summarised. The output flows into the knowledge base. Without this, the founder's institutional memory lives in scattered notes and the meeting itself becomes the bottleneck.

A pipeline management layer. This can be inside the knowledge base or a separate CRM. At OPC scale, a structured database inside the knowledge base is usually sufficient. The case for a dedicated CRM tool opens when there is a sales team, or more than fifty simultaneously active deals — neither of which applies for most OPCs in the first two years.

An accounting and invoicing layer. Locally compliant, integrated with banking, capable of producing invoices and basic financial reports. This is the only layer where premature optimisation is worth it: the cost of fixing accounting mistakes after the fact is significantly higher than the cost of choosing well early.

That is the minimum. Five tools, covering five distinct functions. The total cost should be well under €300 per month at this stage.

What every OPC stack does NOT need

The tools below appear on most "early-stage SaaS stack" lists. They do not belong in an OPC stack at the start. Each has a trigger that would justify adding it — but until that trigger fires, they are noise.

Customer success software. Not needed until you have three or more active customers simultaneously and the customer success playbook in the knowledge base is no longer sufficient.

Marketing automation. Not needed until there is an inbound motion. Until then, all commercial activity is outbound and handled by the AI layer plus the pipeline tool.

BI and data visualisation. Not needed until there is data to visualise. A spreadsheet plus the AI layer covers the reporting needs of the first eighteen months.

HR tools. Not needed until there is a hire beyond the current team. The OPC by definition has no HR function until it stops being an OPC.

Project management software (as a separate tool). The knowledge base already does this. A separate PM tool creates a second source of truth, which means no source of truth.

Dedicated sales enablement tools. Sequencer software, intent data platforms, sales engagement layers. At OPC scale, the lead enrichment tool plus the AI layer plus the pipeline tool covers what these promise. Add only when the founder is spending more than half a day per week on manual outreach steps that one of these tools would automate.

A second AI tool to do what the first one already does. Pick one, learn it deeply, push it hard before adding another.

How the stack evolves

The stack changes shape as the company changes shape. There are three rough stages.

Pre-revenue / proof-of-concept. Minimum viable stack only. AI layer, knowledge base, meeting capture, pipeline inside the knowledge base, accounting. Total cost: under €100 per month, often closer to free tiers.

Active commercial / first contracts. Lead enrichment is added, connected to the AI layer so prospect data flows into the work without manual copying. The accounting tier upgrades from free to paid. Total cost: €200–500 per month.

Post-first-contract / scaling commercial. A dedicated demo or product stack appears if the company sells software-adjacent products. Contract signing software is added. The pipeline may move from inside the knowledge base to a dedicated CRM. Total cost: €500–1,000 per month, still well under one fractional employee.

Each stage has triggers. The discipline is to wait for the trigger, not to anticipate it. Anticipating it produces a stack you are paying for capability you cannot yet use.

The cost discipline

A useful target: keep the stack under €500 per month until the first revenue-generating contract is signed. The reasoning is not parsimony for its own sake. It is that every euro spent on tools before revenue is a euro that cannot be spent on the things that produce revenue — outreach, partnerships, founder time on commercial work.

After the first contract, the cost ceiling can rise. But the discipline does not change: every tool added has a trigger, and every tool already in the stack is reviewed at least annually. Tools that have stopped earning their place are removed, not kept on the assumption that they might be useful again.

→ Next: 2.3 The stack decision framework: what to add and when

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

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.

The four-question test

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.

A tool that passes all four questions earns a place. A tool that fails any of them waits.

Triggers, not budgets

The wrong way to grow a stack is by budget — "I can spend €X on tools per month, what is the best use of it." That framing produces noise: every tool sounds reasonable in isolation, and the stack drifts toward whatever was most recently advertised.

The right way is by trigger — a specific event in the business that signals a tool is now needed.

Examples of triggers from the Stratum stack:

A meeting scheduling tool — added when calendar back-and-forth crossed three exchanges per booking. Trigger: the third exchange.

A lead enrichment tool — added when manual prospect research became the bottleneck on outbound volume. Trigger: research time per prospect exceeding the value of the next conversation.

A dedicated e-signature tool — not added until the first contract that the existing accounting tool's e-sign cannot handle. Trigger: a buyer requirement that breaks the current workflow.

A customer success tool — not added. Trigger has not happened. Will be added when the third active buyer simultaneously requires structured success management.

Writing triggers down has a second benefit: it converts "we should probably get X" from background noise into a specific waiting condition. When the trigger fires, the decision is already made. When it has not fired, the conversation is over.

The integration test

Before committing to a tool whose value depends on connecting to other tools — almost everything beyond standalone editors — there is one additional test, learned the hard way:

Test the integration end-to-end on a small batch before committing.

Tools sold as having seamless integrations often do not. The marketing material describes what is possible; the actual implementation describes what works. The gap can be wide enough to make the tool useless at the integration layer that matters to you, even if the standalone product is competent.

The procedure:

Set up the tool on the lowest-cost tier or trial.

Run a small, real workflow through the integration — not a synthetic test, an actual piece of work that mirrors how you would use it in production.

Watch what happens at every handoff. Where does data get lost, transformed incorrectly, duplicated, or fail to arrive at all?

Contact support with any failure. Note the response and the response time.

Decide based on what you observed, not what was promised.

If the integration is broken, the right move is almost always to drop the downstream tool — the one that depends on the integration — rather than build workarounds. Workarounds compound. They start as a small script or a manual step and end as a parallel system that nobody understands. The cost of dropping a tool is bounded; the cost of accumulating workaround debt is not.

This is generalisable beyond integrations. Any tool whose actual behaviour differs materially from its advertised behaviour gets one fix attempt, then exits the stack. There are too many tools that do work as advertised to spend energy salvaging ones that do not.

When to drop a tool

Dropping is harder than adding. Sunk cost is real — you have configured the tool, learned its quirks, integrated it into your flow. The instinct is to keep it.

Three clear signals that a tool should leave the stack:

The exit condition has fired. You wrote one when you added the tool. It has triggered. Drop it.

The tool's actual behaviour differs from what it was bought for. Not a small gap — a structural one. A core feature does not work, an integration is unreliable, the support model is non-functional. Give it one good-faith fix attempt. If that does not resolve it, drop it.

You have stopped using it. If a tool has not been opened in four weeks of normal operation, that is data. The tool is not paying its complexity cost. Drop it. The reverse is also true: if a tool is being used heavily, it is justified by its usage, regardless of price.

The procedure for dropping is the mirror of the procedure for adding. Document the decision: what triggered the drop, what is replacing the capability (often nothing, or AI, or an existing tool), and any lessons that should travel forward into the next tool decision. The drop is not just an operational change — it is a lesson, and lessons are an asset.

A worked example: the CRM decision

In April 2026, I dropped a dedicated CRM tool from the Stratum stack. The decision is documented in detail in 3.4 (Decision-making alone). Here it is reframed through the stack framework:

Original trigger to add it: Pipeline visibility was getting messy with five-plus active enterprise conversations. The CRM was supposed to provide structured stages, automated enrichment, and clean reporting.

Four-question test at time of adding: Question 1 (specific bottleneck): yes, pipeline visibility. Question 2 (could AI plus existing tools cover it): partially — the existing knowledge base could have been used, but at the time the CRM seemed cleaner. Question 3 (revenue or compliance): yes, revenue. Question 4 (exit condition): "drop if integration with the lead enrichment tool fails reliably."

Exit condition fired: The integration was confirmed by vendor support as a known bug, with no roadmap to fix. Question 4's pre-written exit condition triggered.

What replaced the capability: The existing knowledge base, with a properly structured pipeline database. The capability that was lost — automated enrichment from the integration — was already not working, so nothing was actually lost in the move.

The lesson — generalisable: the cost of pre-writing an exit condition is roughly zero. The cost of not having one is months of workarounds before the founder admits the tool is no longer earning its place. Always write the exit condition at the moment of adding.

What goes wrong, and how to catch it

Three patterns to watch:

Stack creep. Tools accumulate one by one, each justified in isolation, none reviewed against the whole. The fix: a quarterly stack review. Every tool gets the four questions re-applied. Tools that no longer pass exit. The review takes 30 minutes and saves significant ongoing cost.

Free-tier blindness. A tool's free tier is in the stack because it costs nothing, so it never gets evaluated for whether it deserves to be there. Free tiers cost zero in money and non-zero in attention. Apply the same four-question test to free tools as paid ones.

Premature optimisation of the stack. A founder spends two days configuring a stack "the right way" before doing any commercial work. The stack is well-architected for a company that does not yet exist. The fix: inverse priority. Do the work first; let the bottlenecks emerge; add the tool that resolves the bottleneck. The stack discovers itself.

The principle underneath

The stack is not the company. The stack supports the company. When the stack starts to feel like the company — when configuring tools feels productive while no commercial output is produced — the relationship has inverted, and the framework above is the way back.

The rule is short: add by trigger, test the integration, write the exit condition, drop without sentiment.

Get that right and the stack stays lean, the cost base stays bounded, and the founder's attention stays on the work the stack is supposed to support. Get it wrong and you will spend a meaningful share of your week serving software you bought to serve you.

→ Next: 2.4 A real example: the Stratum stack

The Stratum Stack — A Real Example

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.

The Organising Principle

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.

The Mental Model

Before the tool list, the model. The stack is organised around three layers:

Input → Brain → Output

Input: Where data enters the system. Granola (meeting transcripts), Clay (lead enrichment), LinkedIn (prospect research).

Brain: Where information is stored, processed, and turned into decisions. Notion (knowledge base, operating system, and CRM), Claude (AI layer).

Output: Where decisions become action. The Notion pipeline (pipeline management), MoneyBird (accounting and invoicing), DocuSign (contracts).

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.

The Stack, Layer by Layer

The AI Backbone

Claude (Pro) is the AI backbone. Not a specific task tool — the general intelligence layer. Research, drafting, proposals, SOPs, financial narrative, outreach copy, meeting prep, competitive intelligence, data analysis, session planning. It is used in a structured way: every session has a brief, a context document, and a clear output goal. Without structure, AI becomes a time sink. With structure, it is a force multiplier.

It is also the connective layer. Through its connections to the other tools, Claude is the operator that moves data between them — pulling enrichment from the prospecting tool, writing records to the knowledge base, drafting into the inbox — rather than a separate automation platform doing the wiring.

The CLAUDE.md — a plain-language document that explains the company's context, rules, and working conventions to Claude at the start of every session — is the single most important document in the operating system. More on this in Part 3.

The Knowledge Base

Notion (Plus) is the single source of truth. Not a notes app, not a documentation tool — the operating brain of the company. Every SOP, every pipeline entry, every client note, every financial assumption, every piece of competitor research lives here. It is also the integration hub: meeting notes come in from Granola, and Claude reads context from here at the start of every session and writes back to it during the work.

Building a Notion workspace that actually functions as an operating system takes deliberate architecture. The common failure mode is a workspace that becomes a graveyard of half-used pages — well-intentioned structure that nobody maintains. The discipline is: every page has an owner, every page has a purpose, and if neither is true, the page does not exist.

The CRM

Notion (already in the stack, no added cost) manages the buyer pipeline as a structured database inside the existing workspace. This is the setup after an earlier experiment with a dedicated CRM was dropped. The reason: an integration the vendor advertised as seamless was, in practice, unreliable — confirmed by their own support as a known bug — and the separate CRM became a tool that added context-switching cost without a compensating benefit. At OPC scale, well under fifty active deals, a relational Notion database with the fields that track each prospect — buyer type, source, sentiment, last contact, notes — is fully sufficient.

The CRM is the left side of the bow tie made operational. Every prospect has a record, a next action, and a date. The pipeline is reviewed weekly. Nothing lives in email or in someone's head. The case for a dedicated CRM tool reopens when there is a sales team, or more than fifty simultaneously active deals — neither of which applies yet.

The Meeting Layer

Granola (Business) captures every meeting. No bot, no intrusive recording notice — Granola transcribes from your device, AI-enhances the notes, and extracts action items. The output flows directly into Notion. The result: no meeting disappears into someone's personal notes. Every call becomes institutional memory.

Cal.com (free) handles scheduling. A shareable booking link for buyer and partner calls. It removes the back-and-forth from every calendar conversation and integrates directly with Google Calendar and Granola.

The Money Layer

MoneyBird (Unlimited) handles accounting, invoicing, and partner proposal signing. VAT-compliant Dutch accounting, e-sign on partner proposals, auto-conversion of quotes to invoices.

DocuSign (Personal) handles e-signature for enterprise contracts. Not needed until the first enterprise deal closes — MoneyBird covers everything else. The DocuSign line item is zero until the trigger event.

The Lead Enrichment Layer

Clay (Starter) enriches contacts and builds the research signal for outreach. It chains data sources — LinkedIn, company databases, news — and produces a per-prospect research note. Claude reads that enriched data directly from Clay when drafting outreach; the founder reviews and approves every message before it sends. (The full loop is in 4.3.)

The Demo Stack

Lovable + Supabase + Anthropic API + Vercel are used for building buyer-facing demos. This is not a mockup workflow — it produces a real, hosted, interactive product that a buyer can use independently, built in a couple of hours by one non-technical founder for a few tens of euros.

The demo stack is a commercial tool, not an infrastructure tool. It belongs to the sales process — not the product build. The full methodology is in 4.6 Building a demo that sells: validate before you build.

The governing principle: validate with the demo tool first. Bring in a technical partner only when you have proof of demand — a buyer who has used the demo and wants the real thing. The demo is the spec. The signed letter of intent is the trigger. The technical partner builds from there.

Presentations

Gamma (free → Plus) builds decks from prompts in under a minute. Use the free tier for internal and early-stage decks. Upgrade to Plus to remove branding before sending to enterprise buyers. Export to PPTX for buyers who require a file.

What Is Deliberately Not in the Stack

As important as what is in the stack is what is not. These are tools that many founders reach for too early:

A customer success tool (Gainsight, Vitally) — not needed until the first buyer reaches active delivery. Until then, the customer success playbook in Notion and the meeting log cover it. Revisit when managing three or more active buyers simultaneously.

Marketing automation (Mailchimp, Brevo) — not needed until there is an inbound motion. At this stage, all commercial activity is outbound.

BI / data visualisation (Looker, Metabase) — not needed until there is data to show. A spreadsheet and Claude cover the reporting needs.

HR tools (Personio, HiBob) — not needed until there is a hire beyond the current team.

A separate automation platform (the kind that wires apps together on a schedule) — not needed while the AI layer is connected to the tools directly and run in a session. The case for one opens only if the company needs work to happen on a timer, with no founder in the loop — which is past the point where this is still an OPC.

LinkedIn Sales Navigator — start without it. The enrichment tool pulls from other sources first. Add only when a specific data gap appears in prospect enrichment.

The pattern: every tool on the "not yet" list has a defined trigger. It is not "we'll add it when we can afford it" — it is "we'll add it when this specific thing happens." Triggers prevent premature scaling and keep the cost base lean.

The Cost Structure

The full stack runs at well under €300/month — covering the AI layer, the knowledge base, meeting capture, accounting, and lead enrichment, plus minor tool costs.

For context: the equivalent capability five years ago — a research function, a CRM, a pipeline management layer, a meeting capture system, an accounting system — would have required either significant software spend or significant headcount. The current stack delivers all of it for less than most companies spend on one software seat.

The cost target: keep the stack under €500/month until the first enterprise contract is signed. Add tools only with clear triggers tied to revenue milestones.

What This Stack Produces

The output of a well-functioning stack is not a set of tools. It is a set of flows:

A new lead is enriched in Clay → Claude reads it and creates the contact in the Notion pipeline → Claude drafts the outreach → the founder reviews and sends.

A call is booked via Cal.com → Granola captures it → notes flow directly into the Notion meeting log → the founder processes actions, Claude assists with follow-up drafts.

A contract is signed via DocuSign → MoneyBird issues the invoice → the buyer moves to onboarding in the Notion pipeline → the customer success playbook activates.

The flows are defined. Nothing falls through the gap between tools. That is what a stack is for.

→ Next: Part 3 — The Operating System

Your Notion as a Brain: How to Build It

Every OPC needs a knowledge base. Not a notes app. Not a project management tool. A single place where the operating logic of the company lives — where anyone (including AI) can find the context they need to do the next piece of work.

Notion is the most common choice for this, and it is the one this manual is built around. But the tool is less important than the architecture. A well-structured workspace in any tool is useful. A poorly structured Notion workspace is a graveyard — full of half-finished pages, orphaned databases, and context that exists nowhere because it exists everywhere.

This chapter is about the architecture. What to build, in what order, with what rules.

What a Brain Needs to Do

Before building anything, get clear on what the workspace needs to do. Four things:

Store decisions. Not just the outcome, but the reasoning. Why did you choose this positioning? Why did you decide not to pursue that partner? Decisions made in January are invisible in September unless you wrote them down. And if you use AI regularly, those decisions need to be accessible to the AI — which means they need to be written, not just remembered.

Track actions. What is happening, who owns it, by when. Not in someone's inbox. Not in a WhatsApp thread. In a place where the full picture is visible at a glance.

Hold context for AI. This is the distinctive requirement of an OPC. You will be using AI heavily. AI has no memory between sessions. Every session starts from zero unless you give it context. Your Notion workspace — specifically, a document called CLAUDE.md (or the equivalent for whatever AI you use) — is what makes your AI sessions coherent rather than repetitive.

Serve as the single source of truth. One place. Not two. Not one place for strategy and another for operations and another for the pipeline. When there are two sources of truth, there is no source of truth.

The Stratum Architecture

The Stratum Notion workspace took roughly three months of active building to reach a functional state. Not three months of full-time work — three months of iterating: building a page, using it in practice, finding where it breaks, rebuilding it.

The architecture that emerged has six layers:

Layer 1: The Homepage

A single page that links to everything. Not a dashboard with live data — a navigational anchor. When you open the workspace, you should be able to get to any page within two clicks from the homepage. If you cannot, the homepage needs work.

Layer 2: The Operating Context (CLAUDE.md)

A plain-language document that explains to Claude — at the start of every session — what Stratum is, what stage it is at, what the current priorities are, what language and framing to use, and what has been decided previously. This is the highest-leverage document in the workspace. When it is current, AI sessions are fast. When it is stale, every session starts with catch-up.

More on CLAUDE.md in 7.4. The key discipline: update it every time something significant changes. It is not documentation — it is a live brief.

Layer 3: The Commercial Layer

Everything to do with buyers. The pipeline database. The meeting log. The go-to-market page. The qualification framework. The proposal templates. This layer is organised around the bow tie: left-side tools on one side, right-side playbooks on the other.

The Stratum commercial layer took the most iteration to get right. The first version was a set of flat pages with no linking logic. The second version introduced a Buyer Pipeline database with stages mapped to the bow tie, a Meeting Log with meeting types distinguished by left or right side, and a Customer Success & Delivery playbook as the operating manual for everything after the contract is signed.

Layer 4: The Operations Layer

Everything to do with running the company. The toolstack page (what tools, what they do, who owns them, when to add more). The team page (who does what). The financial model. The compliance notes. The partner pipeline (supply-side relationships, distinct from the buyer pipeline).

Layer 5: The Intelligence Layer

Everything that informs strategy. The competition page. The assumption testing framework. The market research. The regulatory landscape. This is the layer that most founders neglect — because it feels less urgent than commercial or operations work. But the decisions you make at the strategic level depend on the quality of the intelligence underneath them.

Layer 6: The Inbox

A single page that serves as the unstructured entry point. When something comes in — a new idea, a piece of market news, a meeting note that hasn't been processed yet — it goes to the Inbox first. The founder processes the Inbox in the weekly operating rhythm. Nothing stays there longer than a week.

What Stratum Learned (The Hard Way)

Three months of active building produced a set of lessons that are worth passing on directly. These are not theoretical. They are the specific mistakes that cost time.

1. Page titles are navigation tools.

Every page title should tell you exactly what is in the page. Not "Commercial" — "Go-to-Market / Sales & Marketing." Not "Notes" — "Meeting & Conversation Log." When you are in a session with Claude and need to point it at a page, an ambiguous title creates ambiguity in the work. Title precision is a small discipline with compounding returns.

2. Every database needs a purpose before it has a schema.

The Stratum workspace has two pipeline databases: Buyer Pipeline (demand side) and Partner Pipeline (supply side). These were built separately because they serve different purposes — different stages, different metrics, different owners. Building one database for everything would have created a mess. The temptation to merge is strong. Resist it until you are certain the purposes are the same.

3. The bow tie must be visible in the database structure.

The Buyer Pipeline Stage field now runs from Target through to Renewed, with Closed — Won as the knot in the middle. This is not decorative. When you look at the pipeline board, you can immediately see how much of your commercial activity is on the left side versus the right side. If everything is on the left side, you have no recurring revenue. The structure makes the imbalance visible — which is the first step to fixing it.

4. Separate acquisition meetings from delivery meetings.

The Meeting Log has a Meeting Type field. Left-side types: Intro Call, Demo, Negotiation, Partnership. Right-side types: Check-in — Active Buyer, Expansion, Renewal. This distinction matters because the work before and after a meeting is completely different. An Intro Call requires prospect research and a qualification checklist. A Check-in requires a review of the last period's delivery and a prepared agenda. If your meeting log does not distinguish between them, the pre-meeting preparation becomes generic and the notes lose their usefulness.

5. The right-side playbook must be written before you have any buyers.

This is the counterintuitive one. Most founders write the customer success process when they have customers to manage. By then, you are improvising under pressure — which is the worst time to design a system. The Stratum Customer Success & Delivery page was written before the first contract was signed. The onboarding SOP, the check-in cadence, the first impact definition, the expansion playbook — all of it existed as a documented system before it was needed. When the first buyer signs, the system activates. Nothing is invented on the fly.

6. Metrics must cover both sides of the bow tie.

The Stratum Traction & Metrics page tracks left-side and right-side metrics separately. Left-side: qualified opportunities, conversion rates, sales cycle, contracts signed, contracted value. Right-side: time to first impact, buyer satisfaction, renewal rate, NRR, expansion proposals. If you only measure left-side metrics, you will optimise for closing and neglect delivery. Both sides are the business.

7. The CLAUDE.md is the highest-leverage page in the workspace.

When it is current, AI sessions take minutes to orient and hours to produce. When it is stale, every session starts with twenty minutes of catch-up. The rule: update CLAUDE.md every time something changes that would affect how Claude should approach its work. New strategic decision. New tool. New information about a prospect. New lesson from a mistake. Keep it current. It compounds.

8. Inline links over manual duplication.

When one page needs to reference another, use an inline link. Never copy content between pages. Copied content diverges. Linked content stays current. This sounds obvious and is routinely ignored. Every time you catch yourself copy-pasting content from one Notion page to another, you are creating a maintenance problem. Link instead.

9. One database per distinct purpose. Not one database for everything.

The Stratum workspace has the Buyer Pipeline, the Partner Pipeline, the Meeting Log, and the Granola Notes database (which syncs from Granola automatically). Each has a distinct purpose, a distinct schema, and a distinct owner. The temptation to consolidate is a simplification trap. The databases are simple individually. Their coordination is handled by links and shared context, not by merging them.

10. Don't build what you won't maintain.

The graveyard principle. Every page in the Stratum workspace exists because someone owns it and uses it. When a page stops being maintained, it is either archived or deleted. An unmaintained page is worse than no page — it creates the impression of information that may be stale. When in doubt: archive, don't keep.

The Session Discipline

A Notion workspace is only as good as the discipline around using it. The Stratum operating model runs on sessions — structured blocks of work with a defined context, a defined goal, and a defined output. Before a session starts:

The CLAUDE.md is current.

The relevant Notion pages are open and ready to reference.

The session goal is written down (not just understood).

The output format is agreed (a page update, a draft document, a database entry, a list of decisions).

Sessions without structure produce outputs that are hard to integrate into the workspace. Sessions with structure produce outputs that land in the right place and stay useful.

The session discipline is covered in detail in 3.2. The Notion architecture is what makes it possible.

What to Build First

If you are starting from scratch, build in this order:

Homepage — even if it links to nothing yet. The navigation anchor comes first.

CLAUDE.md — your AI context document. Even a rough version is better than nothing.

Inbox — the unstructured entry point. Everything goes here until it has a home.

Pipeline database — the bow tie made operational. Left side stages, knot, right side stages.

Meeting Log — with Meeting Type field distinguishing left-side from right-side meetings.

Customer Success playbook — before you have customers. Write the system before you need it.

Metrics page — with left-side and right-side metrics defined, even if the current values are all zero.

Everything else — the intelligence layer, the detailed operations pages, the financial model — can be added as the need appears. The seven pages above are the minimum viable OPC workspace.

→ Next: 3.2 Working with AI: sessions, not searches

Part of The OPC Manual · By Adine Tjeenk Willink

The difference between an OPC that compounds and one that stalls is not which AI tools they use. It is how they use them. Most people treat AI like a search engine — one question, one answer, move on. The OPC model treats AI differently: as a connected operator with access to your calendar, your inbox, your knowledge base, and your rules. This section is about how to set that up, and how to govern it properly.

The shift: from prompts to infrastructure

When you first use Claude, you ask it questions. You get answers. It feels useful.

Then you hit the ceiling. Every session starts from scratch. Claude doesn't know your company, your pipeline, your priorities, or your voice. You spend the first ten minutes re-explaining context that should already be there. The output is generic because the input is generic.

The OPC operating model solves this by treating AI not as a search tool but as infrastructure — connected, governed, and embedded in your working rhythm. This requires three things:

A context file — a reusable brief that loads your world into every session (see 7.3 — CLAUDE.md template)

Connected tools — giving Claude read and write access to your calendar, inbox, and knowledge base under clear rules

Governance — explicit rules for what Claude can and cannot do with that access

This section covers points 2 and 3. Point 1 is covered in 7.3.

Connecting Claude to your live tools

Claude can be connected to Google Calendar, Gmail, Notion, and other tools via integrations in Claude.ai. Once connected, Claude can read and act on live data — not just answer questions about hypothetical situations.

This is powerful. It is also where things go wrong if you don't govern it properly.

The tools worth connecting first, in order of value:

1. Google Calendar

Claude can read your schedule, create events, update existing ones, and calculate travel times. The risk: without clear rules, Claude can modify the wrong event. Always verify before writing.

2. Gmail

Claude can search your inbox, summarise threads, draft replies, and flag spam. The risk: without clear rules, Claude could send email on your behalf. Define explicitly what requires your confirmation — especially sending.

3. Notion

Claude can read and update your knowledge base, create pages, and search across your workspace. The risk: without clear rules, Claude might update the wrong page or move information between spaces it shouldn't cross (e.g. internal company information into a public-facing document).

4. MoneyBird / accounting tools

Useful once connected for invoice status, outstanding payments, and financial summaries. Add once the other three are stable.

The governance layer: tool access ethics

Before you give Claude access to live tools, write the rules. Not after something goes wrong — before.

Here is the framework I use, built from real experience:

Calendar rules

Read freely. Write only on explicit instruction.

Claude may read and search calendar events freely

Claude may only create, update, or delete events when explicitly instructed

Before any write action: Claude states the event title, date, time, location, and any other fields — and waits for confirmation

Claude never modifies an existing event unless the instruction explicitly names that event

Claude always verifies the event ID maps to the correct event title before writing — if uncertain, fetches and confirms first

After any write action: Claude reads back the confirmed details and flags any discrepancy immediately

Claude never infers or assumes event details — if anything is ambiguous, it asks first

What went wrong before these rules existed:

I asked Claude to add a location to a newly created event. Claude updated a different event — a critical meeting with an enterprise prospect — instead, because it reused a stale event ID from a failed creation. The error was caught and reversed, but it illustrated the risk clearly. Verify the event ID. Always.

Gmail rules

Read and draft freely for priority contacts. Never send autonomously.

Always permitted — no confirmation needed:

Read and search emails

Summarise threads or inbox

Draft emails for priority contacts (saved to drafts, never sent)

Extract action items or follow-ups from threads

Flag spam and promotional content with a suggested action

Requires explicit confirmation before acting:

Applying labels or archiving

Marking as read/unread in bulk

Unsubscribing from mailing lists

Deleting any email or thread

Absolute rule — no exceptions:

Claude can never send an email. You must physically press send. Always.

Claude may not feed email content into external systems without stating the intent first

Defining priority email

Not all email is equal. Define upfront which email Claude should draft proactively — so it is not arbitrary.

Priority email = any email where commercial progress, partner relationships, or professional reputation is at stake.

For an OPC in early commercial phase, this typically means:

Active prospects and enterprise buyers in the pipeline

Supply-side partners (in my case, data partners)

Technical partners — anything touching delivery

Inbound leads — anyone reaching out about the business

Time-sensitive follow-ups — where a delayed response risks losing momentum

Fund or investment correspondence (if applicable)

Claude does not draft proactively for:

Personal email

Anything where you haven't yet decided what you want to say

The daily briefing

Once your tools are connected and governed, you can ask Claude for a daily briefing that pulls from all of them.

The prompt:

"Claude, give me my daily briefing. Check my calendar, inbox, and Notion and tell me what matters today and in what order."

What the briefing covers:

What's on the calendar today

What's in the inbox that needs attention (priority emails first, flagged spam separately)

What's open in Notion that is time-sensitive or commercially relevant

Prioritisation logic:

Time-sensitive external commitments first — calls, meetings, deadlines

Commercial momentum second — anything that risks going cold

Internal and admin last

Format: short narrative, not a list. The goal is to understand what matters and why — not to produce another to-do list.

This is a manual trigger. Run it at the start of your working day. Do not automate it — the value is in the decision to orient yourself, not in the output appearing automatically.

What to write into your CLAUDE.md

All of the above — the tool access rules, the priority email definition, the daily briefing prompt — belongs in your CLAUDE.md context file. Not as a one-off instruction, but as a standing operating procedure that loads with every session.

The tool access ethics section of your CLAUDE.md should cover:

Calendar: read vs. write rules, verification requirements, confirmation protocol

Gmail: permitted actions, confirmation-required actions, the absolute no-send rule

Priority email definition: specific to your commercial context

Daily briefing: the prompt and the prioritisation logic

Lessons log: every error that happens with connected tools goes here, with the rule that prevents it recurring

See 7.3 for the full CLAUDE.md template including this section.

The principle underneath all of this

AI connected to live tools is not more dangerous than AI without access — it is more powerful, which means the cost of a mistake is higher. The governance layer does not exist to limit what Claude can do. It exists to make sure that what Claude does is always what you intended.

The rule is simple: read freely, write carefully, send never without you.

Get this right and Claude becomes a genuine operator in your business. Get it wrong and you are cleaning up errors in places that matter.

→ Next: 3.3 The weekly rhythm of an OPC

Part of The OPC Manual · By Adine Tjeenk Willink

A one-person company does not run on heroics. It runs on rhythm. The week has a shape, the days have defaults, and the founder is not deciding from scratch every morning what to work on. This section describes the rhythm I use, why each piece exists, and what it is replacing.

Why rhythm matters more in an OPC

In a traditional company, the calendar is shaped by other people. Standups, all-hands, one-to-ones, board meetings — the structure exists because there are humans who need to be coordinated. The founder does not have to design it; it imposes itself.

In an OPC, no structure imposes itself. There are no standups because there is no team. There are no all-hands because there is one set of hands. The founder either designs the rhythm deliberately, or works reactively — and reactive work is what kills OPCs. Not lack of effort. Reactivity.

The weekly rhythm is the antidote. It is the layer that decides in advance what kind of work happens when, so the founder does not spend daily energy choosing between depth work, commercial work, and admin. The choice is already made.

The organising principle

Each day of the week has one dominant mode. The mode is decided in advance. The day's work conforms to the mode.

This is the test. If on Tuesday you are doing the kind of work that is supposed to happen on Friday, the rhythm is not working. Either the rhythm is wrong, or the discipline is wrong. Both are fixable, but only if the deviation is visible.

The modes I use:

Monday — orient. Plan the week, review the pipeline, write the week's brief.

Tuesday and Thursday — build. Deep work on the things only the founder can do: proposals, strategy, partner conversations, product decisions.

Wednesday — operate. The internal cadence: financial review, Notion hygiene, SOPs, the things that keep the company running but generate no immediate output.

Friday — sell. All discovery calls, all buyer conversations, all partner intros are clustered here.

Weekend — write or rest. Either generative work that needs uninterrupted time, or genuine rest. Not catch-up.

The rest of this section is about why each mode exists and how to make it stick.

Monday: orient

The purpose of Monday is to load the week into your head before doing any of the week's work.

What happens on Monday:

Pipeline review. Every active prospect, every partner conversation, every contract in flight. What stage are they at? What is the next action? What is the next action date? If a row in the pipeline has no next action with a date, that is a problem to fix on Monday — not Friday.

Week's brief. A short document — three to five lines — answering: what is the one outcome that defines a successful week? Everything else is in service of it.

AI session: weekly priorities. Load CLAUDE.md, paste the brief, ask Claude to surface what's missing — risks, dependencies, things going cold.

What does not happen on Monday: discovery calls, deep proposal work, anything reactive. Monday is the cheapest day to spend on orientation, because it is the most expensive day to lose to other people's agendas.

Tuesday and Thursday: build

These are the deep work days. The work that only the founder can do — that AI cannot draft from scratch, that an assistant cannot ghost-write, that requires the founder's specific judgment.

The categories:

Commercial deliverables that move money. Proposals, decks, financial models, contract structures, pricing decisions.

Strategic decisions. Positioning shifts, partner selection, hiring decisions, fundraising prep.

Founder-required conversations. Calls that cannot be delegated — investor updates, senior buyer conversations, partner negotiations.

The discipline is: protect these days from meetings. Not all meetings — meetings that genuinely require the founder are fine. But the slow drift where every day becomes 60% calls is what destroys these days. The default state of a Tuesday or Thursday morning should be: closed door, AI session open, one document on screen.

The test: at the end of a build day, can you point to a deliverable that did not exist that morning? If you cannot, the day was not a build day, and you need to know that before letting it happen again.

Wednesday: operate

Wednesday is the internal day. The work that does not generate revenue but without which the company cannot function.

What happens on Wednesday:

Financial cadence. Cash position, outstanding invoices, this month's costs, runway. Not a full month-end — a weekly check.

Notion hygiene. The knowledge base needs maintenance. New pages get owners, stale pages get archived, the operating system stays usable.

SOPs and templates. Anything you have done twice that you will do again — write it down once. The cost of writing the SOP is paid back the third time you use it.

Tooling decisions. New tool experiments, integration testing, stack adjustments.

Personal admin that has nothing to do with the company but is taking up mental space. Bills, appointments, filing. Get it off the list.

The reason this gets its own day: if it does not have its own day, it gets injected randomly into build days and ruins them. Wednesday absorbs the operational drag so the rest of the week stays clean.

Friday: sell

All commercial conversations cluster on Friday. Discovery calls, buyer follow-ups, partner intros, anything that involves another human being on a video call about the business.

Why Friday specifically: it forces preparation across the rest of the week. If a buyer call is on Friday, the proposal supporting it has to exist by Thursday evening. The deadline is real, weekly, and self-imposed. It also concentrates external energy in one block, leaving four uninterrupted days for the work that requires solitude.

Mechanics:

One booking link. Cal.com, exposing only Friday slots. The link goes in every signature, every outreach message, every follow-up.

Default slot length. 30 minutes for a discovery call, 45 for a follow-up, 60 only when explicitly required. The default is the floor, not the ceiling — most calls get shorter, not longer, when you constrain the slot.

Granola on every call. No exception. The call's institutional memory is created in the act of taking the call, not after.

End-of-Friday review. Twenty minutes at the end of Friday, before the weekend: every call's notes go into Notion, every next action gets a date, every prospect's stage gets updated. The pipeline ends Friday clean. It is the cheapest hygiene work you will ever do.

The test: at 6pm on Friday, is the pipeline a true reflection of where every active conversation stands? If yes, Monday morning is fast. If not, Monday morning is the wrong day to find out.

Weekend: write or rest

The weekend has two legitimate uses, and only two.

Generative work that benefits from uninterrupted time. Long-form writing, deep strategy, learning. Things where the cost of starting and stopping is high, and where two uninterrupted hours is worth four interrupted ones during the week.

Actual rest. Off. Not a low-energy version of work. Genuinely off.

What the weekend is not: catch-up. If the weekend is being used to finish what the week did not finish, the week was wrong, and the next week needs to be reshaped. Catch-up weekends are a leading indicator of an unsustainable rhythm. Treat them as a signal, not a solution.

The daily layer beneath the weekly layer

The week has a shape. The day has a smaller shape underneath it.

Morning: daily briefing. Before doing anything else, run the daily briefing prompt against Calendar, Inbox, and Notion. Five minutes. Tells you what matters today and in what order. (Detailed in 3.2.)

Mid-morning to early afternoon: the day's dominant mode. Build, operate, sell — whatever the day is for, this is the block where it actually happens.

Late afternoon: AI session for tomorrow. Twenty minutes. Load context for tomorrow's mode. Draft what can be drafted. Stage the day so tomorrow morning starts in motion, not in choice.

End of day: pipeline and briefing closeout. Five minutes. What moved today, what didn't, what's tomorrow's one priority.

The daily layer is short. The point is not to schedule every minute. The point is to bookend the day with orientation and review, so the middle of the day is protected for the work itself.

What goes wrong, and how to catch it

Three failure modes show up reliably:

Mode contamination. A Friday call gets accepted into a Tuesday slot because the buyer is only available then. One exception is fine. A pattern of exceptions means Friday is not actually Friday anymore. Catch this by counting, weekly: how many exceptions did I make this week? If the answer is more than one, the rhythm is leaking.

Operate-day drift. Wednesday becomes the day where everything that does not fit elsewhere lives. It bloats. Catch this by deciding, in advance, the three things Wednesday must produce. If those three things are not done by end of Wednesday, the rest is overflow and goes to next Wednesday.

Build-day collapse. A build day starts with two hours of "just one quick call," then a Slack thread, then a check on a partner integration, and by noon there is no deliverable in sight. Catch this by writing the day's intended deliverable on Monday — the brief — and checking it before going to bed. If you cannot point to it, the day was not a build day.

The rhythm is not enforced by willpower. It is enforced by visibility. If you can see when it leaks, you can fix it the following week.

What this rhythm is replacing

The weekly rhythm replaces three things that traditional companies provide automatically:

Coordination structure — replaced by the day-mode contract

Forced prioritisation — replaced by the Monday brief and the daily briefing

End-of-week closure — replaced by Friday pipeline closeout and weekend boundary

If the rhythm is doing its job, you should not need willpower to choose between deep work and meetings, between strategic and operational, between selling and building. The choice is already made by the calendar. The founder's energy goes into the work, not into the meta-decision about what the work should be.

→ Next: 3.4 Decision-making alone (without losing your mind)

Part of The OPC Manual · By Adine Tjeenk Willink

The hardest part of running an OPC is not the work. The hardest part is the absence of the room. There is no one across the table to push back, no co-founder to disagree, no team meeting where the bad version of the idea gets killed before it ships. Every decision is yours, and the cost of a wrong one falls fully on you. This section is about how to make good decisions in that condition — and how to recognise the ones that should not be made alone.

The problem

In a normal company, decisions are made in rooms. The room does work. It surfaces the assumption you missed, the option you did not see, the version of the plan that is technically feasible but commercially absurd. The room is a debugger.

In an OPC, the room is gone. You can simulate it with AI, you can borrow it from advisors, you can rent it from peers. But the default state is: you are alone with the decision, and the decision is yours.

This creates two failure modes that show up over and over:

Premature commitment. A decision feels obvious because there is no one to ask the second question. You execute. Two weeks later, the assumption was wrong.

Permanent deferral. A decision feels too big to make alone. You park it. Two months later, the cost of not deciding is larger than the cost of any of the available options.

The goal of this section is not to prevent wrong decisions — that is impossible. The goal is to surface decisions correctly, route them to the right method, and avoid the two failure modes that compound.

The first move: classify the decision

Not all decisions are equal. The first move, before any deliberation, is to classify what kind of decision is in front of you. The classification determines the method.

Three categories:

Reversible decisions. A tool you can swap, a draft you can rewrite, a meeting you can rebook, an outreach message you can recover from. Cost of being wrong is low. Cost of deliberation is higher than cost of trying.

Reversible-but-costly decisions. A pricing change you announced, a partnership you pitched, a positioning shift you put in a deck. You can walk it back, but it costs reputation, time, or a relationship. Cost of being wrong is moderate. Cost of deliberation is justified.

Irreversible decisions. A signed contract, a hire, a public commitment, a partner you formally selected, a name you trademarked. Cost of being wrong is high. Cost of deliberation is almost always lower than cost of being wrong.

The rule:

Reversible: decide fast, alone, with AI as a sanity check.

Reversible-but-costly: deliberate alone with structured method, then sleep on it.

Irreversible: never decide alone. Always pull a human into the room.

The failure mode is treating an irreversible decision like a reversible one because it feels urgent. Urgency is not a category of decision. Urgency is an emotional state.

The structured method for reversible-but-costly decisions

This is the largest category, and the one where AI helps the most.

The method has four steps. Each one takes ten to thirty minutes. Done in sequence, the whole thing takes a single AI session.

Step 1 — State the decision in one line. Not the topic. The decision. "Should I switch CRM from X to Y?" is a decision. "Thinking about CRM" is not. If you cannot write the decision in one line, you do not yet have a decision — you have a topic, and the work is upstream.

Step 2 — State the options. All of them, including the ones you do not like. Including the option of not deciding yet. Three to five options is healthy. One option means you have already decided and are looking for confirmation, which is a different (and worse) exercise.

Step 3 — Run each option against three tests.

The reversibility test. If this turns out wrong, what does it cost to undo? Hours, money, relationships, reputation? If the cost of undoing is bounded, the decision is lower-risk than it feels.

The asymmetry test. What is the upside if it works, and the downside if it does not? An option with high upside and bounded downside is a different shape from an option with moderate upside and unbounded downside, even if both feel comparable.

The information test. What would I need to learn to make this decision well, and can I learn it in a week? If yes, the right move may be to delay the decision and run a small test. If no, you decide on the information you have.

Step 4 — Sleep on it. Not metaphorically. Literally. Reversible-but-costly decisions get a minimum 12-hour gap between draft conclusion and execution. The gap exists because the version of you at 11pm and the version of you at 8am the next morning will see the decision differently, and one of them is more reliable than the other for these decisions. (It is the morning one. Always.)

AI as the room — used correctly

The seductive use of AI is to ask it for the answer. "Should I switch CRMs?" Claude will give you a competent answer, and the answer will feel useful, and you will execute on it, and you will be no better off than if you had asked a smart friend who knows nothing about your business.

The correct use of AI for decisions is structurally different. AI is the room. It does the work the room does. Which means: it pushes back, surfaces assumptions, offers the option you did not see, and stress-tests the version of the plan you are committed to.

Three session formats that actually work:

The pre-mortem. State the decision and ask: "Imagine it is six months from now and this decision was wrong. Walk me through the most likely failure mode." Read the answer. Then ask: "Now do the second-most-likely failure mode. Then the third." The third one is usually the most useful, because the first two were already in your head.

The steel-man of the option you rejected. State the decision and your preferred option. Then ask: "Make the strongest possible case for the option I am about to reject." If the steel-man is weak, your decision is solid. If the steel-man is uncomfortably strong, you have not finished thinking.

The narrow-it-to-three test. When there are too many options or the framing is fuzzy, ask: "Given my context, what are the three options I should be choosing between, and what would I need to believe for each one to be right?" The framing question is more valuable than the answer. It forces you to make the assumption explicit.

What AI is not for: the irreversible decisions. AI is a competent debugger and a poor priest. It will not tell you that your gut is wrong. A human will.

What never gets decided alone

Irreversible decisions need a human in the room. Not to make the decision for you — to be the person who hears your reasoning and asks the second question that AI did not ask.

The shortlist of decisions that, in my experience, must always involve at least one trusted human:

Hiring or formally engaging a partner. Including technical partners, agencies, fractional roles. The cost of getting this wrong is months and significant money.

Signing a contract over a meaningful threshold. Define your threshold in advance. For an OPC in early commercial phase, anything that locks you in for more than three months or commits more than one month of expected revenue qualifies.

Public positioning shifts. A new website headline, a new pitch deck, a new one-line description of the company. Easy to change in theory, very expensive to change once buyers and partners have anchored on it.

Pricing decisions. Once a number is in a buyer's head, it is hard to move. Pricing is reversible-but-costly to expensive depending on stage.

Naming, trademark, and brand decisions. The cost of changing a name once it is in market is much higher than the cost of waiting an extra two weeks to decide it.

Anything that touches the cap table. Without exception.

The humans you call: an advisor with relevant experience, a peer founder one stage ahead, a coach, a fractional operator. Not your partner, not your friends, not strangers on the internet. Specifically, the smallest possible group of people who have made similar decisions and have a track record of doing so well.

A worked example: the CRM decision

In April 2026, I was running outbound through a CRM I had paid for and integrated. The integration with my lead enrichment tool — sold as seamless — turned out to be unreliable. Vendor support eventually confirmed it was a known bug, with no fix on the roadmap.

The decision: keep building workarounds, switch CRMs, or drop the dedicated CRM and use the database tool I already had.

Classifying it: reversible-but-costly. The cost of switching CRMs again later was bounded — a week of data migration. The cost of staying with broken infrastructure was unbounded — every leaked deal compounded.

Running it through the four steps:

Decision in one line: Should I drop the dedicated CRM and operate the pipeline inside the database tool I already have?

Options: (a) Keep current CRM, build workarounds. (b) Switch to a different dedicated CRM. (c) Drop dedicated CRM entirely; use existing database tool.

Reversibility: Option (c) was the most reversible — I could re-add a dedicated CRM later when scale demanded it. Option (a) was the least reversible because it locked me into compounding workaround debt.

Asymmetry: Option (c) had a small downside (less polished CRM features) and a large upside (one fewer tool, one fewer integration, one fewer point of failure).

Information test: Did I need more information? No. The bug was confirmed by vendor support; further data would not change the decision.

Slept on it. Decided in the morning. Dropped the CRM, moved the pipeline into the existing database, documented the SOP, moved on.

The decision took a single AI session and a night. The compounding cost of not making it would have been weeks of leaked information.

The lesson — generalisable beyond CRMs: when a tool that was sold as a seamless integration turns out not to be, the right move is almost always to drop the downstream tool and rebuild the workflow on infrastructure you already trust. Workarounds compound. They do not stabilise.

What goes wrong, and how to catch it

Three patterns to watch:

Decision drift. A decision is half-made, then revisited weekly without resolution. The signal: the same item appears on the Monday brief three weeks running. The fix: classify it (reversible? irreversible?), run the method, decide. The cost of the wrong decision is almost always lower than the cost of three more weeks of drift.

False urgency. A reversible decision feels irreversible because it is in front of you right now. The fix: write the decision down, classify it, and notice that the urgency is emotional, not structural. Reversible decisions can be made fast. They cannot be made under panic.

Solo execution on irreversible decisions. You skip the human-in-the-room step because pulling someone in feels like a hassle, and the decision feels obvious. It is not. The cost of one phone call to an advisor before signing is always lower than the cost of being wrong. Make the call.

The principle underneath

Deciding alone is not the same as deciding without help. The OPC operating model gives you AI as a thinking partner and a small set of trusted humans for the irreversible work. Used correctly, you can run a one-person company without making one-person mistakes.

The rule is short: classify the decision, match the method, never alone on irreversible.

Get that right and the absence of the room stops being a constraint. It becomes a feature — fewer cooks, faster cycles, sharper accountability. Get it wrong and the cost of a single bad decision can erase a quarter of work. The discipline is upstream of the decision: knowing what kind of decision you are looking at before you start to deliberate.

→ Next: 3.5 When to bring humans in — and what kind

Part of The OPC Manual · By Adine Tjeenk Willink

An OPC is one founder, AI, and a small set of carefully chosen humans. The founder and AI are the constants. The humans are the variable — and choosing the right kind of human at the right time is one of the most consequential decisions an OPC makes. This section is about how to think about that decision: what categories of human exist, when each one is appropriate, and how to avoid the most common mistake — bringing in the wrong kind of help and assuming any help is better than no help.

The starting position

Most founders default to one model of bringing humans in: the employee. You hire when there is too much work, you fire when there is not enough money, and the headcount line on the financial model is the proxy for whether the company is growing.

The OPC operating model rejects this default. Headcount is not a proxy for growth — it is a cost that compounds and a complexity that compounds faster. AI plus the right small humans can replace many roles that would have required hiring five years ago. The question is not "when do I make my first hire?" The question is "what is the smallest, sharpest human layer that lets the founder operate at full leverage?"

The answer is almost always: not an employee. Not yet, and possibly not for a long time. The OPC stays lean by being deliberate about which kinds of humans are added, in which order, for which reasons.

The five categories of humans

There are five distinct kinds of humans an OPC will engage with — beyond the founder. Each one is a different commitment, a different cost structure, and a different role in the company. Confusing them is the source of most early-stage hiring mistakes.

1. Technical partners. Specialist firms or individuals who build the product or core infrastructure that the founder cannot build alone. The relationship is a defined deliverable, often with a multi-month engagement, sometimes with equity or revenue share. Not employees — partners.

2. Fractional operators. People with senior-level skill who work part-time across multiple companies. Fractional CFO, fractional CMO, fractional ops. They are bought in for specific functional capability that the founder lacks and that AI cannot replace.

3. Advisors. People with relevant experience and network who give time and judgment in exchange for a small equity stake or a fee. Their role is not to do work — it is to be in the room when irreversible decisions are made.

4. Trusted intermediaries. People in your network who facilitate access — to buyers, to investors, to other founders, to specialised expertise. The relationship is reciprocal and informal. Not contracted, not paid; sustained by trust and by the founder's own contribution back into the network.

5. Service providers. Lawyers, accountants, designers, specific technical contractors. Bought in for defined work, paid for outputs, no ongoing operational involvement. Important but not a strategic question — they get hired when they are needed and replaced when they are not.

The ordering matters. The first three are strategic — they shape what the company can do. The fourth is relational — it shapes who the company can reach. The fifth is operational — it gets work done that the founder will not do themselves.

The order in which they appear

In the OPC operating model, these categories appear in a roughly predictable sequence, driven by what the company needs to do at each stage.

Earliest stage — building proof. The first humans are usually technical partners and trusted intermediaries. Technical because the founder needs to build the product or demo and cannot do it alone. Intermediaries because the founder needs warm access to the first customers and partners, and intermediaries are the highest-bandwidth way to get it.

Commercial stage — closing the first deals. Service providers come in: a lawyer for the first contracts, an accountant for the first invoices, possibly a designer for the first proposal-grade collateral. These are bought-as-needed, not retained.

Scaling stage — capacity stretches the founder. Fractional operators come in. The founder hits a function — finance, marketing, operations — that AI cannot fully cover and that genuinely requires a skilled human. The fractional model exists exactly for this stage: senior skill, part-time cost, no equity dilution, no employment overhead.

Advisors throughout. Advisors should be in the picture from the earliest stage. They are not a scaling function; they are a quality-of-decision function. The cost of acquiring good advisors early is low; the cost of acquiring them when you need them in a crisis is high.

Employees, possibly, eventually. A first employee is a major event in the life of an OPC and should be treated as such. The trigger is not workload. The trigger is when there is a function that is core to the company, ongoing, full-time, and requires institutional knowledge that the founder cannot afford to outsource. Until that trigger fires, the answer is some combination of the four categories above.

The four-question test for any human commitment

Before engaging any human in any of the five categories, run the commitment through four questions. The questions are similar to the stack framework — and the parallel is intentional. Adding a human is a higher-stakes version of adding a tool.

Question 1 — What specific work does this person do that the founder plus AI cannot do?

Not a vague mandate. A defined deliverable or capability. "Help with marketing" is not a mandate; it is the symptom of a founder who has not articulated what they actually need. "Build the demand-generation engine for the next two quarters" is a mandate. If the answer to Question 1 is fuzzy, the engagement will be fuzzy, and the founder will end up paying for capacity rather than capability.

Question 2 — Why is this the right category of human?

If the work is one-off, it is a service provider. If the work is ongoing but part-time, it is a fractional. If the work is the building of the core product, it is a technical partner. If the work is judgment in moments of irreversible decision, it is an advisor. If the work is access to people the founder cannot reach directly, it is an intermediary. Mismatching the category is one of the most expensive mistakes an OPC can make. A fractional hired to do advisor work is paying for the wrong thing; an advisor asked to do fractional work will under-deliver. Match the category to the work.

Question 3 — What is the trigger to end or change this engagement?

Every commitment needs an exit condition, just as every tool does. For technical partners: when does the engagement end and what does the handoff look like? For fractionals: at what stage do they roll off, and into what? For advisors: what is the term of the relationship, and how does the equity vest? For intermediaries: what is the implicit contract, and how is the founder reciprocating? Writing this down at the start protects the relationship. Relationships that end well have the end designed in advance.

Question 4 — Has this person done this specific thing before, with a track record I can verify?

This is the unsexy question that prevents most expensive mistakes. Specifically: has this person done this specific work, in a context comparable to the founder's, with an outcome the founder can validate? "Senior at a big company" is not a track record for fractional work in an early-stage OPC. "Has done fractional CFO for three other companies my size, two of whom I can call" is. The bar is reference-checkable, recent, and specific.

How to use each category well

The category-by-category playbook for getting value out of each kind of human:

Technical partners. The relationship works when the founder owns the product and the partner owns the build. The founder defines what the product does, what schema or data model underlies it, what the user experience must feel like. The partner builds it. The most common failure mode is the founder abdicating the design to the partner — the partner builds something competent but generic, and the founder later has to rebuild it. The defence: the founder retains design authority, even when the technical work is fully outsourced.

Fractionals. The relationship works when the fractional has a defined two-quarter or three-quarter mandate, a measurable outcome, and a clear handoff plan. It fails when the fractional drifts into permanent part-time staff — the company grows dependent, the fractional disengages from other clients, and the cost stops being justified. Re-evaluate every quarter. Roll off when the function can be either internalised, automated, or graduated to a different model.

Advisors. The relationship works when the advisor is consulted on irreversible decisions, before they are made, with enough context to add value. It fails when the advisor is informed of decisions after the fact, or when the founder uses advisors as social validation rather than as challenge. Pull advisors in when the decision is hard, not when it is comfortable. Their value is in the friction they create.

Trusted intermediaries. The relationship works when the founder gives at least as much as they take. Introductions are reciprocated; warmth is maintained outside of the moments when the founder needs something. The single most reliable way to destroy intermediary relationships is to surface only when there is an ask. Invest in these relationships in the gaps between asks. The asks compound when the relationship is healthy.

Service providers. The relationship works when scope is tight, deliverables are clear, and the founder does not try to make a service provider into a strategic partner. The lawyer is not your CGC. The accountant is not your CFO. Use them for what they are good at, pay for the work, and move on.

What goes wrong, and how to catch it

Three patterns to watch:

Category confusion. A founder hires a fractional to do advisor work, or an advisor to do fractional work, and gets the worst of both. The fix: before any engagement, write the category and the mandate. If they do not match cleanly, redesign the engagement before signing.

Premature scaling of the human layer. A founder feels overstretched and the instinctive solution is more humans. Sometimes that is right. More often, the right solution is better AI workflows, sharper prioritisation, or dropping work that is not paying for itself. Test the AI-and-systems answer before testing the human answer.

Drift into permanent dependency. A fractional, technical partner, or service provider becomes embedded in the operating model in a way that was not planned. They are no longer fractional, no longer project-based — they are functionally an employee at non-employee terms. The fix: quarterly review of every human commitment, with the four questions re-applied. Engagements that have drifted get redesigned or ended.

The principle underneath

The OPC model is not an anti-people model. It is a model that is deliberate about which people are added, in which categories, for which reasons. The founder's job is not to minimise human involvement — it is to maximise leverage per human added.

The rule is short: right category, right mandate, written exit condition, verifiable track record.

Get that right and the human layer of the OPC stays sharp — small, specialised, complementary to the founder and to AI. Get it wrong and the company ends up with the cost structure of a traditional company without the coordination benefit of one.

→ Next: Part 4 — The Commercial Layer

The default assumption in B2B sales is that pipeline requires a sales function. A BDR to generate leads. An AE to run the process. A CSM to handle what comes after. The handoffs, the CRM hygiene, the follow-up sequences — all of it designed for a team, with specialisation at each stage.

An OPC has none of that. One person owns the full arc. From the first contact to the signed contract to the renewal three years later — it is all you, supported by AI and a light operations layer.

This sounds like a disadvantage. In some ways it is. But it comes with a structural advantage that most founders underestimate: you are always the most credible person in the room. There is no SDR making a cold call on your behalf. No AE who only half-understands the product. No CSM who has to re-learn the relationship at handoff. The person who built the thing is the person having the conversation. That matters — particularly in enterprise B2B, where trust is the primary purchase criterion.

The challenge is not credibility. The challenge is capacity. How do you hold a commercial pipeline — with all the follow-up, the relationship management, the proposal writing, the negotiation — as one person, without it consuming the time you need to actually deliver?

The answer is the bow tie.

The Bow Tie Model

The bow tie is a commercial framework developed by Jacco van der Kooij and the team at Winning by Design. It is built around a simple and important insight: the traditional sales funnel ends at the signed contract. The bow tie begins there.

In a recurring revenue business — which is what most serious OPCs should aim to build — the signed contract is not the finish line. It is the midpoint. The left side of the bow tie is acquisition: everything from first contact to the moment a deal closes. The knot is the signed contract. The right side is delivery: onboarding, first impact, expansion, renewal. In a well-functioning recurring business, 80% or more of total contract value comes from the right side — from buyers who renew and expand, not from new logos.

This reframes the entire commercial logic.

Most founders spend almost all their time on the left side. They optimise for closing. They celebrate the signed contract. And then they wonder why renewal rates are low, why expansion never happens, why every year feels like starting from zero.

The bow tie forces a different question: what happens after the contract? If the answer is "we figure it out," the right side of your bow tie is broken. And a broken right side means you are spending all your energy refilling a leaking bucket.

The Left Side — Acquisition

The left side of an OPC pipeline follows the same stages as any B2B sales process, compressed into one person:

Target → Contacted → Responded → Meeting Booked → Proposal Sent → Negotiating → Closed — Won

As an OPC, the left side is where AI does the most visible work:

Research: AI can build a detailed picture of a prospect — their organisation, their stated priorities, their relevant publications or public statements, their role — in minutes. What used to take an SDR a morning takes you twenty minutes of prompting.

Outreach: First drafts of emails, LinkedIn messages, and follow-ups. AI writes them; you edit for tone, accuracy, and relationship specificity. The human layer is the judgment about what to say, not the typing.

Proposals and decks: AI can produce a first draft of a proposal or pitch deck from a structured brief. Your job is the thinking that goes into the brief, and the review that goes into the final version.

Follow-up sequencing: AI can draft follow-up messages for every stage of the pipeline, so the next step is always ready before you need it.

The critical OPC discipline on the left side is qualification speed. You do not have a sales team to run parallel tracks. Every prospect you spend time on is time you are not spending on the rest of your work. Ruthless qualification — identifying fast who is and is not a real opportunity — is not optional. It is the left-side operating principle.

→ The Stratum qualification framework uses a 100-point scoring model across five dimensions: research need, data type match, budget reality, decision-making authority, and urgency. Any prospect below 50 points is dropped immediately. This is not aggressive — it is kind. It saves both parties the time of a process that was never going to close.

The Knot — Closing

The knot is the signed contract. For an OPC, closing looks different than in a traditional sales process:

You are the negotiator. There is no legal team, no sales director, no procurement specialist on your side. You need to know the deal well enough to negotiate it, which means understanding your walk-away points before the conversation, not during it.

The close is also the handoff — to yourself. There is no CSM taking over. The relationship you built on the left side is the relationship you will manage on the right side. Do not let the post-close transition feel like a different experience for the buyer.

The knot is fully closed when: contract countersigned, initial payment received, onboarding call scheduled. All three. Not two of the three.

The Right Side — Delivery, Impact, Expansion

The right side is where OPCs most commonly fail — not because the delivery is poor, but because the right side is not systematised. It is improvised. And improvised right sides collapse when the left side gets busy.

The right side has three stages:

Stage 1 — Onboarding

Goal: get the buyer to their first meaningful interaction with what you have delivered, as fast as possible. Every day between signing and first value is a day where doubt can accumulate. Onboarding is not administrative. It is the first chapter of the right side.

Systematise it. The same onboarding sequence for every buyer. A documented checklist. A scheduled onboarding call. A first deliverable with a built-in feedback loop. Nothing improvised.

Stage 2 — First Impact

First impact is the moment the buyer can point to something concrete — an output, an insight, a result — that your work enabled. It is the renewal anchor. If a buyer reaches first impact within the first 90 days, the probability of renewal is high. If they do not, you are in recovery mode, and recovery is expensive.

The OPC discipline here is to define first impact explicitly, at the onboarding call. Not "we'll see how it goes." A specific outcome. A specific timeframe. A shared definition of what success looks like at 90 days.

Stage 3 — Expansion

Expansion is the easiest commercial conversation you will ever have — if it is triggered by a buyer outcome. "Now that you've seen this work, what would you want to do next?" That question, asked at the right moment, after the buyer has achieved first impact, is the most natural commercial conversation there is. It does not feel like sales. It feels like service.

Define your expansion routes before you need them. For each buyer type, what are the natural next steps? A larger scope? A second team within the organisation? A new use case? Know the routes before the conversation.

→ Stratum's expansion routes: larger cohort size, additional data signals, second therapeutic area, second internal team within the buyer organisation, co-publication.

The OPC Constraint on the Right Side

The specific risk for an OPC is that the right side collapses when the left side is active. When you are deep in a sales process — writing proposals, doing discovery calls, following up with five prospects simultaneously — the buyers who have already signed get less attention. Not intentionally. Just because there are only so many hours.

The mitigation is not heroics. It is systematisation:

Every buyer gets the same onboarding sequence, documented in advance.

Check-in cadences are calendar-blocked at contract signing, not scheduled reactively.

Expansion triggers are defined upfront and monitored passively — the buyer does not have to raise their hand.

Your operations layer (human or AI) handles the administrative layer: scheduling, note-logging, follow-up tracking, risk flagging.

The right side is a system, not a relationship. The relationship is yours. The system keeps the relationship alive when you are busy with something else.

What This Looks Like in Practice

The Stratum pipeline is built around this model:

Buyer Pipeline database tracks every prospect through the full bow tie sequence, from Target to Renewed. Every stage is named. Every stage has a definition. Nothing lives in your head.

Meeting Log distinguishes left-side meetings (Intro Call, Demo, Negotiation) from right-side meetings (Check-in, Expansion, Renewal). The type of meeting determines the agenda.

Customer Success & Delivery is the right-side operating playbook: onboarding SOP, check-in cadence, first impact tracker, expansion playbook, renewal playbook, risk flags. Everything that would otherwise be improvised is written down.

Traction & Metrics measures both sides of the bow tie. Left-side health: qualified opportunities, conversion rates, sales cycle length, contracts signed. Right-side health: time to first impact, buyer satisfaction, renewal rate, NRR.

The bow tie is not a concept. It is an operating structure. Every part of the commercial system — the database, the meeting types, the playbook, the metrics — maps to a stage on the bow tie.

The Founder-Seller Advantage

One more thing worth naming, because it is easy to miss when you are worried about capacity.

Enterprise buyers buy from people they trust. Trust is built through consistency, expertise, and the sense that the person across the table has skin in the game. As the OPC founder, you have more skin in the game than any account executive at a vendor with fifty clients. The buyer knows it. They can feel it in how you respond to their questions, how you handle the difficult conversations, how you show up at the renewal.

This is your structural advantage. The bow tie is the system that lets you hold it at scale.

→ Next: 4.3 Outreach: CRM → AI → Gmail Drafts

Part of The OPC Manual · By Adine Tjeenk Willink

Once you have a CRM, a prospect list, and a value proposition, the next bottleneck is throughput: how do you reach a meaningful number of qualified people, without a sales team, without sounding generic, and without spending your days writing near-identical emails? This section describes the loop I actually run — AI connected directly to the tools, drafting into the inbox, with the founder pressing send.

The shape of the loop

The outreach loop has four moving parts and one rule.

The parts: a prospecting source that finds and enriches people, a CRM that holds them as the single source of truth, an AI layer that drafts the outreach, and an email client where drafts land for review. The rule: the human presses send. Always. Nothing leaves the company on a schedule or without a person reading it first.

What makes this work at one-person scale is not a chain of automation tools wired together. It is that the AI layer is connected to the other tools directly and operated in a session. The AI reads from the prospecting source, writes to the CRM, and drafts into the inbox — because it has been given access to each, under explicit rules. The founder runs the session, reviews the output, and sends.

This is the AI-as-team-member model from 2.1, applied to commercial work. The AI is not a feature inside one tool. It is the operator that moves between tools, with the founder supervising.

Why connected AI replaced the automation-chain approach

There is an older way to build this loop: wire the tools together with an automation platform (the kind that watches one app for a trigger and pushes data to another on a schedule). The CRM holds prospects; the automation platform fetches them on a timer; it calls an AI model through an API to draft each email; it drops the result in the inbox and updates the CRM. It works. Many teams run exactly this.

For an OPC, the connected-AI approach is usually better, for three reasons.

Fewer moving parts. The automation-chain approach means building, testing, and maintaining scheduled scenarios — and every scenario is a thing that can break silently when an API changes underneath it. The connected-AI approach has no scheduler to maintain. The founder opens a session when there is outreach to do.

The human is already in the loop. The whole point of the automation chain was to remove the human from the repetitive middle. But an OPC founder should not be removed from outreach — the judgment about who to contact and how is the founder's core commercial work, not overhead to automate away. A session where the founder directs the AI keeps that judgment where it belongs, while still removing the blank-page and data-entry drudgery.

No second intelligence to configure. In the automation-chain version, the AI lives inside the scheduler as an API call with a pasted-in prompt — separate from the AI the founder actually talks to. The connected-AI version uses one AI, in one place, that already has the company's context loaded. The draft it writes is informed by everything in the context document, not just the fields a scenario happened to pass it.

The tradeoff is real and worth naming: connected AI runs when you run it, not on a timer. If your model depends on contacting hundreds of net-new people a week with no founder involvement, you have outgrown this approach and the automation chain (or a sales hire) is the right answer. Most OPCs are nowhere near that point, and the founder-in-the-loop session is both cheaper and better.

The connections you need

Three connections turn the AI layer from a chat window into an operator. Each is set up once, through the AI tool's own integrations or connector settings.

The prospecting source → AI. Your enrichment tool (the one that finds people, verifies emails, and builds a research signal on each) connects to the AI so the AI can pull enriched prospect data directly into a session. You do not export a spreadsheet and paste it in. You ask the AI to retrieve the prospects, and it reads them from the source.

The AI → CRM. Your knowledge base / CRM connects to the AI with read and write access, so the AI can create a contact record, populate its fields, and update it later as the conversation progresses. The CRM stays the single source of truth; the AI is just able to write to it directly.

The AI → email client. Your inbox connects to the AI so it can create drafts — and only drafts. This is the connection that carries the highest stakes, and the governance around it is covered in 3.2. The non-negotiable rule: the AI may create a draft; it may never send.

With those three connections live, the loop runs inside a single session.

The loop, step by step

This is the sequence in one outreach session. The founder directs each step; the AI executes; the founder reviews before anything is committed.

Step 1 — Pull the prospects. Ask the AI to retrieve a batch of enriched prospects from the prospecting source — for example, the people most recently enriched, or a named segment. The AI reads them directly, including the research signal the enrichment tool generated for each.

Step 2 — Write them to the CRM. Ask the AI to create a record for each prospect in the CRM, populating the fields you actually use — name, company, role, the type of buyer they are, where they came from, and the research note into a notes field. The CRM is now the source of truth for this batch. (On what fields a CRM at this stage actually needs, see 3.1.)

Step 3 — Draft the outreach. Ask the AI to draft a personalised email for each prospect, using the research signal as the hook. The draft is informed by the company context the AI already holds — the value proposition, the voice, the things never to say — because that context is loaded at the start of the session, not pasted into a one-off prompt. (On loading context, see 7.3.)

Step 4 — Land the drafts in the inbox. The AI creates each email as a draft in your email client, pre-addressed to the prospect, with a subject line and body. It does not send. The drafts simply appear in your drafts folder.

Step 5 — Review and send. You open each draft, read it, adjust a line where the AI's version is slightly off, and press send. This is the step that cannot be delegated and should not be. The founder's read is what keeps the outreach honest and on-voice.

Step 6 — Update the record. After sending, the AI updates each CRM record to reflect that the person has been contacted and the date — and notes the next action, so nothing goes cold. (The follow-up discipline that hangs off this is covered in 4.4.)

The whole loop is one session. No scheduler fires in the background. The founder decides when to run it, and the AI does the parts that are repetitive while the founder does the parts that are judgment.

What the AI does, and what stays with you

The split is the same one that runs through the whole manual.

The AI does: the retrieval, the data entry, the first draft, the record-keeping. The work that has a pattern — pulling fields, populating a database, producing a personalised-but-structured email, logging a contact date. This is exactly the work that used to require an assistant or a sales-development hire, and exactly the work an OPC should not be doing by hand.

You do: the choice of who to contact, the read on whether a draft is right, the edit that makes it sound like you, and the act of sending. The research signal tells the AI what to hook into; your judgment decides whether the hook is appropriate and whether this person is worth the outreach at all. The AI removes the typing. It does not remove the thinking.

A note on qualification. It is tempting to have the AI score every prospect and auto-discard the low scores. At OPC scale, where you are reviewing every draft anyway, an explicit scoring step is usually unnecessary machinery — your review is the qualification. Add a scoring step only if the volume genuinely exceeds what you can review by reading. Most OPCs never reach that point, and a scoring model you do not need is just one more thing to maintain and second-guess.

Governing the connections

Connecting AI to your inbox and CRM is powerful, which means the cost of a mistake is higher than with an AI that only talks. The governance is covered in full in 3.2; the headline rules specific to outreach are short.

The inbox connection drafts, never sends. This is absolute. The value of the loop is that the founder still presses send on every message. An AI that could send autonomously would not save meaningful time — the review is fast — and would carry real risk to relationships and reputation. Draft-only is the design, not a limitation.

The CRM connection writes only what you have confirmed. The AI can create and update records, but the founder should be able to see what was written and correct it. The CRM is the company's memory; polluting it with a wrong field or an invented detail is expensive to unwind. (On why even internal records demand the same no-invention discipline as external emails, see 6.1.)

The prospecting source is read-only into the session. The AI pulls enriched data; it does not need to write back to the prospecting tool. Keep that connection one-directional.

What goes wrong, and how to catch it

Three patterns show up reliably.

Generic drafts that pass review. The AI produces a competent, on-structure email that is also forgettable — and because it reads fine, it gets sent. The fix is upstream: the quality of the draft is bounded by the quality of the research signal the AI hooks into. A thin signal produces a generic email. Invest in the enrichment, and require the draft to reference something specific to the person, not just their job title.

Silent CRM drift. The AI writes a record with a field slightly wrong — a misattributed company, an expanded initial that was never confirmed. Over a batch, the CRM accumulates small errors. The fix is to spot-check the records the AI creates, especially early on, and to hold the AI to the rule that an unknown detail is flagged, never guessed.

The loop becomes the work. Because the loop is fast, it is easy to run it constantly and mistake outreach volume for commercial progress. Contacting more people is not the same as advancing deals. The discipline from 4.4 applies: a conversation is progressed when a next step is confirmed, not when a message is sent. Run the loop in service of the pipeline, not as a substitute for working it.

The principle underneath

The outreach loop is the clearest example in the manual of AI as a connected operator rather than a tool you visit. The AI reaches into the prospecting source, the CRM, and the inbox — and does the repetitive middle of commercial outreach — while the founder keeps the two things that matter: the judgment about who and how, and the hand on the send button.

The rule is short: AI connects and drafts; the founder decides and sends.

Build it that way and one person can run a credible outbound motion that used to require a small team. Build it the other way — fully automated, founder removed — and you get volume without judgment, which in early-stage enterprise sales is worse than no outreach at all.

Part of The OPC Manual · By Adine Tjeenk Willink

Most deals are not lost on the pitch. They are lost in the silence after it. The follow-up is where commercial momentum is built or destroyed, and where most founders — especially solo ones — leak the most opportunity. This section is about how to build a follow-up system that runs reliably, costs minimal time, and never lets a conversation go cold by accident.

Why follow-up is the bottleneck for OPCs

A founder running solo has a structural disadvantage in commercial conversations: there is no SDR, no junior salesperson, no team chasing leads back to life. Every follow-up is the founder's job, and the founder is also doing the building, the partner conversations, the financials, and the outreach.

The predictable failure mode: a strong call happens. The founder feels good about it. The next morning, the inbox demands attention, a partner pings, a deadline shifts. The follow-up that was supposed to go out within 24 hours goes out in five days. Or seven. Or never. By the time it lands, the buyer has moved on, lost momentum, or quietly assumed you were not serious.

This is not a discipline problem. It is a system problem. Discipline cannot scale across forty active conversations. A system can.

The organising principle

A conversation is only progressed when a concrete next step is confirmed — not when a message is sent.

This is the test, taken from session discipline and applied to commercial work. "I followed up" is not a status. "They have a calendar invite for Tuesday" is a status. The follow-up system is built around producing the second one, not the first.

From that, three rules:

Every conversation has a defined next action with a date.

Every next action with a date has an owner — usually the founder, sometimes the buyer.

If a date passes with no action, the system flags it before the founder remembers.

Nothing else in this section is more important than these three rules. The rest is implementation.

The structure: where follow-ups live

Follow-ups live in one place. Not the inbox, not the calendar, not memory. One database, one source of truth.

In my setup, this is the Buyer Pipeline database in Notion. Every active conversation is a row. Every row has, at minimum:

Stage — where in the cycle this conversation sits

Next action — the specific thing that needs to happen

Next action date — when it needs to happen by

Last contact — when the last meaningful exchange was

Sentiment — your read on the conversation, updated after each touch

The single most important field is Next action date. If a row has no next action date, it is invisible to the system. It will go cold. Treat a missing next action date as a structural error, not a soft to-do.

The weekly rhythm enforces this. Friday closeout: every row in the pipeline must have a populated next action date by 6pm Friday. No exceptions. The cost of doing this is twenty minutes per week. The cost of not doing it is conversations that quietly die.

The cadence: when to follow up

The right cadence is buyer-stage dependent. There is no universal "follow up after three days" rule that works.

For enterprise buyers in early-stage conversations:

Within 24 hours of a call — a recap message with the agreed next step. Always. This is the most leveraged message in the entire cycle. It anchors what was decided before memories diverge.

Within 5–7 days if no response to the recap — a single, light nudge. Not a re-pitch. A short check-in or value-add (a relevant article, a clarification, an update on something they asked about).

Within 14 days if still no response — a sharper, more direct message naming the silence and asking explicitly whether the timing is wrong or the priority has shifted. This is the message that either restarts the conversation or surfaces the no.

Beyond 14 days — the conversation is at risk of going cold. Decide actively whether to keep it warm with a slow cadence (one touch every six weeks with genuine value), or to mark it inactive and free up attention.

For active deals in commercial progression — proposals out, contract conversations underway — the cadence tightens. Same logic, shorter intervals: 24 hours after a call, 3 days for a nudge, 7 days for a sharper message.

For partner conversations on the supply side, the cadence loosens. Partners are usually founders themselves; they are not buying anything. The follow-up is collegial, not transactional. Twice the patience, half the urgency.

The principle: cadence matches stake, not stage of relationship. A high-value buyer in early discovery gets a tighter cadence than a low-value buyer in late-stage talks.

The recap message: the highest-leverage follow-up

Within 24 hours of any meaningful commercial call, a recap message goes out. This is non-negotiable.

The recap has three jobs:

Confirm what was agreed — the next step, owner, and date. If the buyer is the owner, name what they committed to. If you are the owner, state what you will deliver and by when.

Resolve any open questions raised on the call — usually one or two. Resolve them in writing if you can; if not, name them and commit to a date.

Anchor on momentum — one short line that signals confidence and forward motion, without overselling.

What the recap is not: a re-pitch, a long thank-you, or a wall of text. The buyer was on the call. They do not need to be re-sold. They need to know what happens next, by when, and that you are organised.

Length: 80 to 150 words. If you are over 150, you are doing more than recapping.

This is the single message I draft most carefully and run through the most filters before sending. It is the message that decides whether the conversation has momentum or not.

AI in the follow-up loop

The follow-up system is one of the highest-leverage places to use AI in an OPC, because the work is repetitive, the format is structured, and the cost of a generic message is high.

What AI does well:

Drafts the recap message from a meeting transcript. Granola captures the call, transcript flows to AI, AI drafts the recap in your voice using prior follow-ups as reference. You edit, approve, send.

Drafts the 5–7 day nudge. Templates are dangerous (they sound like templates) but AI generating a nudge in context — referencing what was actually discussed — is not. Three sentences, specific, light.

Surfaces the silent ones. Ask AI weekly: "Of these active conversations, which have not had a touch in over 14 days?" Cross-check against the pipeline. The system flags drift.

Generates the sharp 14-day message. This is the hardest message to write because it requires honesty without confrontation. AI is genuinely useful here — it removes the emotional charge from the draft.

What AI does badly, and which you must do yourself:

Reading the room. Whether to send the sharp message at all, or whether the buyer's silence is signalling something the data does not show.

Calibrating warmth. A buyer you have known for two years gets a different message than one you just met. AI defaults to a middle register.

Choosing not to follow up. Sometimes the right move is to stop. AI will keep producing follow-ups. The founder decides when the conversation is over.

The rule: AI drafts, founder decides, founder presses send. Always.

Owner ambiguity: the silent killer

The single most common reason a follow-up gets dropped is that no one is sure whose turn it is.

A call ends. The buyer says "let me think about it and come back to you." Two weeks pass. Whose turn was it?

The rule: the call is not over until the next-step owner is named explicitly. If the buyer is the owner, name a date by which you will check back in if you have not heard from them. "I'll send a short ping on the 15th if I haven't heard back" — said on the call, written into the recap, logged in the pipeline as the next action.

This converts every conversation into one where someone has the ball, the ball has a date, and the system does not have to guess.

What goes wrong, and how to catch it

Three patterns to watch:

Recap drift. The 24-hour recap window slips. One slip is fine. Two becomes a habit. The fix: pre-block the 30 minutes after every call as a "recap" slot in the calendar. Not optional.

Cadence inflation. "I followed up" becomes a substitute for actual progress. The pipeline is full of conversations that have been touched recently but have not moved stage in months. The fix: a quarterly review of the pipeline that asks of every row, "has this moved stage in the last 60 days?" If not, it is either inactive (mark it, move on) or it needs an unblocking action — not another touch.

Nudge fatigue. The same buyer gets the same kind of nudge every two weeks for three months. The buyer notices. The relationship cools. The fix: every third touch must contain new substance — a relevant data point, a market update, something that genuinely advances their thinking. If you cannot produce new substance, the conversation may not be ready for another nudge.

The principle underneath

A follow-up system is not a CRM. It is a discipline expressed as infrastructure: every conversation has a next step, every next step has a date, and the system catches drift before the founder does.

For an OPC, this discipline is the difference between a pipeline that compounds and one that leaks. There is no team to catch what the founder misses. The system is the team.

The rule is short: next step, with a date, every time.

Get that right and the founder's commercial energy goes into the conversations that matter, not into remembering the ones that have gone quiet. Get it wrong and a one-person commercial motion will quietly run at half capacity, and the founder will not know which half.

→ Next: 4.5 Proposals, decks, and one-pagers — made with AI

The instinct when you have a product idea is to build it. Find a developer, scope the infrastructure, set a timeline, spend the money. Then, once it exists, take it to buyers and see if they want it.

This is the wrong sequence. It is expensive, slow, and it answers the wrong question. You do not need to know if you can build the thing. You need to know if anyone will pay for it.

The right sequence: build a demo first. A real, interactive, buyer-facing demo — not a slide deck, not a Figma mockup, not a video walkthrough. Something a buyer can actually use. Then take it to buyers. If they want the real thing, build the real thing.

This is not a compromise. It is a competitive advantage. An OPC that validates before building is faster, cheaper, and more commercially credible than a funded team that built something nobody asked for.

What a Demo Actually Is

A demo in this context is not a presentation. It is a working prototype that a buyer can interact with independently — without you in the room, without explanation, without context.

The test: could you send the demo URL to a buyer you have never spoken to, with a one-paragraph briefing note, and have them understand what the product does and want to request access? If yes, the demo is working. If no, it is still a sales tool that requires you to be present — which means it is closer to a deck than a product.

The distinction matters because the async version of the demo — the one that works without you — is the one that gets forwarded. Enterprise buyers do not make decisions alone. When you send a demo to one stakeholder, you want that stakeholder to be able to share it with three others without having to explain it. A demo that requires the sender to explain it will not travel.

Lovable or Claude Code?

Two AI tools come up when a non-technical founder wants to build something. They are not interchangeable.

Lovable is an AI app builder. You describe what you want in plain English and it generates a working, hosted web application. No terminal, no local setup, no deployment configuration. The output is a live URL you can share immediately. The right tool when you need something a buyer can interact with and you need it fast.

Claude Code is an AI coding assistant. It helps you write, edit, and debug code — but you still need to run that code yourself, manage a local development environment, and handle deployment. The right tool when you are a developer who wants AI assistance, or when you need precise control over an existing codebase.

For an OPC founder building a demo, the answer is almost always Lovable. Here is the decision in one line: if you need a shareable URL by the end of the week and you are not a developer, use Lovable.

The one exception: if you have already built something in code and want to iterate on it, Claude Code is useful. It is also the right tool once you have exported your Lovable demo to GitHub and want to make precise edits before handing it to a technical partner.

The two tools are complementary, not competing. Lovable to build fast. Claude Code to refine later if needed. For the demo build, start with Lovable.

The Tool: Lovable

The tool that makes this possible for a non-technical OPC founder is Lovable. Lovable generates a full-stack React application from a plain English prompt. No code required. No developer required. The output is a real, hosted, interactive web application with a live URL.

What Lovable is not: a production-grade infrastructure tool. It is not what you use to build the thing you eventually sell. It is what you use to prove that the thing is worth building.

The distinction is important. Lovable demos and production infrastructure serve different purposes and have different standards. A demo needs to look real, feel real, and answer the buyer's question. It does not need to scale, comply with enterprise security standards, or survive an audit. The technical partner who builds the production version has a different job than the demo.

The Build Sequence That Works

Building a demo with Lovable follows a specific sequence. Deviating from it costs credits and time.

Step 1 — Connect Supabase before writing a single prompt.

Lovable has native Supabase integration. Connect it first. Lovable will create the database tables automatically from your prompt. If you connect Supabase after the fact, you have to rebuild.

Step 2 — Write one comprehensive prompt.

Describe the entire application in a single prompt: the purpose, the user, the data, the interactions, the design, and any AI integration. Front-load the specification. Iterating from a skeleton costs more credits and produces worse structural results than getting it right in the first pass. Think of the prompt as a product brief, not a conversation starter.

→ A copy-paste ready prompt template is in 7.4 (AI session prompts library), Demo building section.

Step 3 — Gate the demo behind an email capture form.

Every visitor should submit their work email, name, organisation, and role before entering. The form writes to a Supabase table. This turns the demo into a lead generation tool: every person who explores it is logged. Once the demo is live, you can pull those submissions into your CRM in a working session — ask the AI to read the new sign-ups and create the corresponding records.

Step 4 — Set up the Anthropic API and connect it to your demo.

If your demo includes an AI assistant or chat feature, connect it to the Anthropic API directly — not Lovable's built-in AI, which powers the builder, not the product. These are two separate things. Lovable's built-in AI will not work reliably for external visitors.

How to set up the Anthropic API (takes 5 minutes):

Go to console.anthropic.com and create an account. Choose Individual when asked for account type.

Go to Settings → Billing → Buy credits. Add a card and purchase $5–$10 in credits. This is prepaid — you only pay for what you use.

Go to Settings → Limits and set a monthly spend limit of $10. This prevents any unexpected overrun.

Go to API Keys → Create Key. Name it something recognisable (e.g. "demo-key"). Copy the key the moment it appears — it starts with sk-ant- and you will not see it again. Save it immediately in your password manager.

In Lovable, go to the Secrets panel (Cloud → Secrets). Add a new secret named exactly ANTHROPIC_API_KEY and paste the key as the value. Save.

The demo will now call the Anthropic API directly when a visitor uses the chat interface. Use Claude Haiku — it is the fastest and cheapest model, and for a demo chat interface it is more than capable. The cost per visitor session is a few cents at most.

Do not hardcode the API key in the application code. Always store it as a Lovable secret. This keeps it out of the codebase and out of GitHub when you export.

Step 5 — Publish to a clean subdomain.

Lovable publishes to a subdomain (e.g. yourproduct-demo.lovable.app). Remove Lovable branding before sharing with buyers. The URL is shareable immediately — no login required, no infrastructure to manage.

Step 6 — Export to GitHub after the build.

Once the demo is built and working, export the code to GitHub and deploy to Vercel (free tier). This decouples the demo from the Lovable subscription — it runs indefinitely at zero cost after the build month.

What to Put in the Demo

The demo should answer one question for the buyer: what would I do with this?

Not: what is this. Not: how does it work. What would I do with it.

This means the demo should be built around the buyer's research question or workflow, not around your product architecture. The buyer does not care how the data is structured. They care whether the data answers their question.

Three elements that every effective B2B demo has:

A way to explore. A filter or query interface that lets the buyer define their own parameters and see results respond in real time. This gives the buyer agency — they are not watching a demo, they are using a tool.

A way to go deeper. A drill-down from aggregate to individual. From population to profile. From summary to detail. The moment a buyer goes from a cohort of 40,000 to a single record and says "that's a real person" — that is the moment the demo lands.

A way to ask questions. An AI chat interface that lets the buyer ask natural language questions about the data. This is the highest-impact feature in a data product demo. It shows the buyer a future where they do not need to know SQL or build queries — they just ask.

The demo that contains all three is the demo that gets forwarded.

The Data in the Demo

Synthetic data is not a weakness. It is a requirement. You cannot use real customer data in a demo — legally or commercially. Synthetic data, designed thoughtfully, is better than real data for demo purposes: it is clean, it is complete, it tells the story you need it to tell, and it contains no surprises.

The discipline: make the synthetic data feel real. Real data is messy. People start things and stop. Symptoms get worse before they get better. Interventions sometimes work and sometimes do not. A synthetic dataset that is too clean — where every patient improves on a smooth curve, where every intervention works — does not feel like data. It feels like a slide.

Build the synthetic data around the buyer's actual use cases. If you know the buyer is interested in a specific research question, make sure the demo data contains a credible answer to that question. The demo is a commercial tool. The data should serve the commercial goal.

The Cost

Building a production-quality buyer-facing demo costs approximately €32:

Lovable Pro: ~€23 for one month (the build month — cancel after exporting to GitHub)

Anthropic API credits: ~€9 one-time top-up for the AI chat feature

Supabase: €0 (free tier handles thousands of submissions)

Vercel: €0 (free tier for ongoing hosting after GitHub export)

This is the total cost. There is no ongoing subscription once the demo is built and exported.

For context: the equivalent — a developer building a working interactive prototype — would cost €5,000–€15,000 and take four to six weeks. Lovable produces the same commercial output in two hours.

The Async Version

Every demo should work in two modes: live (you walk the buyer through it on a call) and async (the buyer explores it independently before or after a call).

The live version can be more exploratory. You are present to explain, redirect, and respond to reactions. The async version needs to be self-explanatory. Every label, every section, every interaction needs to make sense without narration.

The async version is the one that gets forwarded inside a buyer organisation. Enterprise decisions involve multiple stakeholders. The person you spoke to will share the link with people you have never met. Those people will form their first impression of your product from the async demo — without your context, without your pitch, without you.

Design the async version first. If it works without you, it will definitely work with you.

The Sequence: Demo to LOI to Build

The demo is not the end goal. It is the commercial instrument that generates the evidence needed to justify building the real product.

The sequence:

Build the demo with Lovable

Share with 3–5 qualified buyers

Collect reactions — not just "interesting" but "I would use this" and ideally "what does a contract look like?"

Use buyer reactions to refine the demo and sharpen the use case

Convert the strongest reactions into letters of intent

With LOIs in hand, brief the technical partner on the production build

The demo code is handed over as a reference implementation — the interaction model, the data structure, the UX — and either rebuilt properly or retired

This sequence protects you from the most common OPC failure mode: spending time and money building infrastructure before confirming that anyone wants what you are building.

The demo is cheap. The production build is expensive. Do the cheap thing first.

→ Next: Part 5 — The Money

The financial model is not a spreadsheet. It is a set of beliefs about your business, written down in a form that forces you to be honest with yourself.

Most founders build models to impress investors. They start with the number they need — a revenue target that justifies a valuation — and work backwards to find assumptions that produce it. The result is a document nobody believes, including the person who made it.

An OPC model has a different job. With no board to report to and no co-founder to challenge you, the model is your mirror. It tells you whether the business you are building is structurally sound, how long your runway actually is, and which single variable, if moved, would change everything. The goal is not optimism. The goal is clarity.

What a pre-seed OPC model needs to do

At pre-seed, a financial model serves three purposes — and only three.

First, it forces you to articulate what drives revenue. Not "we will grow" but: how many customers, paying how much, retained at what rate, acquired at what cost. These are not projections. They are hypotheses. The model makes them explicit so they can be tested.

Second, it tells you when you run out of money. Cash flow is not optional knowledge. An OPC with near-zero fixed costs can survive a long time on very little — but only if you know the numbers. "I think I have twelve months" is not the same as knowing you have fourteen.

Third, it is what sophisticated buyers and investors will probe in your first serious meeting. Not the revenue number — the assumptions behind it. When a procurement lead asks why you have 10% churn, you need a real answer. The model forces you to have one.

The architecture: five layers

A functional OPC financial model has five layers. Each one feeds the next. Build them in order.

Layer 1 — Assumptions

This is the only sheet where you type numbers directly. Every other sheet pulls from here. If you hard-code a number anywhere else in the model, you will regret it when you need to run a scenario.

Before you open a spreadsheet, answer these questions. They become your Assumptions sheet.

Revenue inputs

What is your price per unit, per contract, or per year? What is the low, base, and high version of that number?

What is your revenue model — subscription, project fee, usage-based, revenue share, or a combination?

If you have a marketplace or data business: what percentage goes to supply-side partners? What percentage to technology partners? What is left for you?

Customer growth

How many customers will you realistically close in Year 1? Not the pipeline — the closes.

What is your expected growth rate in Year 2 and Year 3?

What percentage of customers will you lose each year (churn)?

Sales cycle

How many months does it take from first contact to signed contract in your market?

What is the minimum realistic number, and the maximum?

Cost inputs

What will you pay yourself? Put a real number here. Founders who exclude their own salary are lying to themselves and to investors.

What does ops or admin support cost — part-time, fractional, or full-time?

What are your technology costs — infrastructure, APIs, tools, any revenue share to a technical partner?

What does each new customer actually cost to acquire? Include travel, time, proposals, events.

What are your compliance, legal, and G&A costs?

Cash position

What is your starting cash?

What is the minimum cash balance you will not let yourself fall below?

Write the answers down before you open Excel. This is your model architecture. Everything else is arithmetic.

Layer 2 — Revenue model

This sheet answers one question: how much money comes in, and when?

Build it customer by customer, not as a lump sum.

The formula structure is:

Beginning customers + new customers − churned customers = ending customers

Ending customers × price = gross revenue

Gross revenue − revenue shares = net revenue

Questions to answer as you build it:

Are all customers paying the same price, or do you have tiers? If tiers, model them separately.

Is revenue recognised when a contract is signed, or when work is delivered? This matters for cash timing.

If you have a supply-side (data providers, partners, subcontractors who must be paid), how does their share relate to each contract? Is it a fixed percentage or a variable amount?

What does Year 2 look like if you close zero new customers and only retain existing ones? That is your floor.

The output of this sheet is net revenue per year — the money that is actually yours after you have paid everyone with a claim on the contract value.

Layer 3 — Cost structure

This sheet answers: what does it cost to run this business and acquire customers?

Organise costs into three buckets:

People and sales

Your salary. Any ops or admin support. Any sales or customer success hires — with start dates, not just annual totals. Variable acquisition costs per new customer (travel, events, proposals). Fixed marketing spend.

Operations and compliance

Legal setup costs in Year 1 (entity, contracts, data agreements). Ongoing compliance. G&A — coworking, software, insurance, team travel.

Technology

Infrastructure, APIs, dev tools. Any external technical resource — fractional, outsourced, or on revenue share. Note: if your technical partner takes a revenue share (captured in Layer 2), their cost may not appear here. Make sure it is captured somewhere and not double-counted.

Questions to answer as you build it:

Have you included your own salary? If not, add it now.

Which costs are fixed (exist regardless of revenue) and which are variable (scale with customers)? Label them. This ratio matters.

When do people join? A hire in Q3 Year 2 costs half what an annual figure suggests. Use start dates.

What is the EBITDA at the bottom of this sheet? Is it positive in Year 3? If not, which cost is the problem?

Layer 4 — Cash flow

This sheet answers the only question that determines whether you survive: when does cash run out?

Structure:

Starting cash + net revenue − operating expenses = ending cash, quarter by quarter.

Questions to answer as you build it:

What is your ending cash at the close of each quarter in Year 1? Not each year — each quarter. Revenue timing is uneven. Costs are not.

At what point does ending cash fall below your minimum reserve?

How many months of runway do you have at current burn if no new revenue comes in?

Does the model require external funding to survive, or is it self-sustaining from starting cash?

The cash flow sheet will often show something the annual view hides: that Year 1 is cash-negative even if the annualised EBITDA looks positive. This happens because costs are incurred from day one and revenue arrives months later, once your sales cycle completes. If you have a six-month sales cycle and your year starts in January, your first contract closes in July at the earliest. Seven months of costs before a euro of revenue. The model must show this.

Layer 5 — Scenarios

This sheet answers: what happens to the model if the most important assumption is wrong?

Build three scenarios: conservative, base, optimistic. For each one, vary only the inputs that matter most. Do not change every assumption — change the two or three that drive the outcome.

Questions to identify which variables to stress-test:

If your price is 40% lower than expected, does the model survive?

If your sales cycle is two months longer than assumed, what happens to Year 1 cash?

If you close half the expected customers in Year 1 but full cost structure remains, how long is your runway?

Is there a build-vs-partner decision in your model — a choice between investing upfront in infrastructure versus paying an ongoing revenue share? Model both over three years before choosing.

The conservative scenario is not pessimism. It is the version of the model you could defend in a room full of people who want to find the flaw. If the business survives it, the model is structurally sound.

The quarterly layer: the sheet most founders skip

Once you have the five layers, add one more: a quarterly breakdown of Year 1.

Take your sales cycle assumption from Layer 1 and apply it to a timeline. If your sales cycle is seven months and you start conversations in January, your first close is August. Model that. Do not model four customers paying for twelve months in Year 1 if the contracts close in the second half of the year.

This sheet will typically show a loss in Year 1 even if the annualised view shows a profit. That is not a problem — it is information. The question is whether your starting cash survives it. If ending cash stays above your minimum reserve, the model is viable. If it does not, you either need more starting cash, a faster first sale, or lower costs in the first two quarters.

The financial model is not finished until the quarterly cash view is honest.

How to build this with Claude: the integration workflow

The model above was not built by sitting inside a spreadsheet. It was designed in conversation with Claude, built in Excel, and then reviewed through Claude — with the file uploaded directly into the chat.

This is a meaningful shift in how a solo founder works with financial models. Instead of navigating between tabs, debugging formulas, and trying to hold the entire logic in your head at once, you upload the file once and ask questions in plain language. Claude reads every sheet, holds the full structure in context, and responds directly. You talk to your model instead of living inside it.

Step 1 — Design the architecture before you build

Before opening a spreadsheet, have this conversation with Claude. Use this prompt exactly, filling in your own business details:

I am building a financial model for my business from scratch. Before I open a spreadsheet, I want you to help me design the full architecture.

Here is my business: [2–3 sentences. What you sell, to whom, at what price, and how revenue flows — subscription, project fee, usage-based, data licensing, revenue share, or a combination.]

Here is what I know about costs: [Your main cost categories. Your own salary. Any ops or admin support. Technology costs. What it costs to acquire a customer. Compliance or legal spend.]

Here is my cash position: [Starting cash. Any committed funding. The minimum cash balance you will not fall below.]

Please do the following:

1. Tell me what sheets this model needs and what each one does

2. List every assumption that should go in the Assumptions sheet — with a suggested starting value and the rationale for each

3. Describe the formula logic for the Revenue Model sheet — what connects to what

4. Identify the top 3 variables that will have the biggest impact on my financial outcome and explain why

5. Tell me what I am probably not thinking about yet

Do not build the model yet. Just give me the architecture so I can review it before we build anything.

Read Claude's response carefully. This is the moment to challenge assumptions before they are baked into formulas. If something looks wrong, say so and iterate. This step typically surfaces at least one thing you had not considered — a cost category, a revenue timing issue, or a structural choice you were about to make incorrectly.

Step 2 — Build it in Excel or Google Sheets

Once you have the architecture, build the model. One Assumptions sheet. All other sheets pull from it. Blue cells for inputs, formula cells for everything else. Nothing hard-coded outside the Assumptions sheet.

If you want help with specific formulas during the build, paste the relevant rows into the chat and ask Claude to complete or fix them. Do not describe what you want in vague terms — paste the actual cell content.

Step 3 — Upload the file and interrogate it

Save the finished model as an .xlsx file and upload it directly into a new Claude conversation. Claude will read all sheets in full. Use this prompt to start the interrogation session:

I am attaching my financial model. Please read all sheets carefully before responding.

Once you have read it, do the following:

1. Summarise the model in plain language. Revenue trajectory, cost structure, EBITDA margin, and cash position at the end of each year. Write this as if explaining it to someone who has not seen the model before.

2. Identify the biggest risks. Which assumptions, if wrong by 30–50%, would most damage the outcome? Rank them by impact.

3. Check the Year 1 quarterly reality. My sales cycle is approximately [X months]. Apply that timing to revenue recognition. When do my first contracts realistically close? What does that do to Year 1 cash? Does my starting cash survive it?

4. Flag anything that looks wrong or inconsistent. Broken formula logic, assumptions that contradict each other, cost categories I appear to have missed, or numbers that seem disconnected from the rest of the model.

5. Tell me what an investor or enterprise buyer will challenge. Which numbers will get pushback in a serious conversation, and what is my strongest defence of each?

After this session, I want to be able to answer any question about this model in a meeting without opening the file.

This session is the interrogation, not the validation. The goal is not to confirm that the model looks good. The goal is to find every weak assumption before someone else does.

What this workflow changes

Most founders either avoid their financial model because it feels technical and anxiety-inducing, or they over-invest in building it — spending days on formatting and scenario tabs instead of testing assumptions with real buyers.

The Claude-as-interface approach removes both failure modes. You spend time on the questions that matter: what drives revenue, where the cash risk sits, which assumption is the most fragile. Not on tab navigation and formula debugging.

For an OPC, this is a structural advantage. You do not have a CFO to pressure-test your numbers. Claude is not a CFO — but it is a capable, tireless interrogator that will find inconsistencies you missed and ask the questions you have been avoiding.

The condition for this to work is that the model itself is well-built. A clean, assumption-driven model gives useful answers. A model with hard-coded numbers scattered across sheets gives noise. Build it properly first. Then upload it and let Claude do the work.

Part of The OPC Manual · By Adine Tjeenk Willink

This part of the manual is about the limits. Where AI cannot reach. Where the founder, and only the founder, has to do the work. If the first five parts argue for what is possible with an AI-first operating model, this part draws the line that the model does not cross.

Why this section exists

The rest of this manual has been deliberately bullish on what an AI-augmented founder can do. The argument has been: more is possible than the previous generation of founder advice acknowledges, and the people most able to act on this are the ones least represented in current founder demographics.

That argument is correct. It is also incomplete. There is a part of the work that does not respond to AI augmentation — not because the technology is not advanced enough, but because the work itself is not the kind of work AI does. Pretending otherwise produces founders who burn out chasing leverage in places where no leverage exists.

This section is the map of where leverage stops. Not as a warning. As a planning input. If you know where the human layer is, you can design around it instead of being surprised by it.

The organising principle

AI compresses the work that has a pattern. It does not compress the work that is the pattern.

Most knowledge work has patterns. Drafting, structuring, summarising, comparing, formatting, researching, translating — these are tasks where the underlying logic recurs across instances. AI compresses these dramatically. A draft that took two hours takes twenty minutes. A research synthesis that took a week takes an afternoon.

Some knowledge work does not have patterns in this sense. It is the work of generating the pattern in the first place — establishing the thing that other work then iterates on. A first principles judgment about positioning. The decision to walk away from a partner that looks good on paper. The taste call about whether a draft sounds like you. These are not faster with AI. They are not slower either. They are simply not the kind of work where AI is the bottleneck — the founder is.

This is not a deficit of AI. It is a property of the work. Recognising the distinction is what lets the founder spend AI-augmented time on the right things, and unaugmented time on the right things.

What stays on the human layer

Five categories of work are, in practice, irreducibly human for an OPC founder. There are others, but these are the ones that show up reliably and that founders most often try to delegate to AI before discovering they cannot.

Generative judgment under genuine uncertainty. The kind of decision where there is no precedent to draw on, no comparable case to anchor against, and no amount of additional information that would resolve it. Whether to take a particular partner. Whether to change the company name. Whether to accept a difficult board member because the cheque is right. AI is useful here for surfacing considerations, structuring the decision, and red-teaming the options — but the call itself is not delegable. It is the founder's call because it is the founder's company.

Taste calls on external work. Whether a draft sounds like you. Whether a deck has the right energy. Whether a positioning statement lands or feels off. AI can produce many candidate versions; you have to choose. The choosing is not a search problem with a correct answer. It is a judgment about what you want the company to feel like. That is not in the training data.

Relationships at depth. This is the subject of 6.2 and gets its own section. The headline: trust, the kind that produces multi-year commercial commitments, is built through accumulated experience of the human, not the company. AI can support every relationship — research the person, surface what matters to them, draft the follow-up, prepare the talking points. It cannot be the relationship.

The long narrative. The story of why this company exists, where it is going, what it is becoming. Not the deck — the underlying conviction that the deck represents. AI is exceptional at expressing a narrative once you know what it is. It cannot find the narrative for you. The discovery is the founder's work, and it tends to happen in slow, accumulated ways — in conversations, in writing for yourself, in noticing what you keep coming back to. Compressed AI sessions do not produce this. Sustained reflection does.

Selective high-stakes work where the cost of an AI error exceeds the time saved. Legal documents that will be signed. Contracts that bind the company for years. Public statements that cannot be retracted. Financial commitments above a certain threshold. AI is useful as a first reader, a checker, a structurer — but the human reads every line. The discipline is that the founder, not an automation, presses send on the irrevocable things.

Why this matters more in an OPC

In a traditional company, the human layer is distributed across many people. The CEO does the deep judgment calls. The head of sales does the high-stakes relationships. The general counsel reads the contracts. The chief of staff catches the things the CEO would miss. The distribution is invisible because it is so total — every role exists in part to hold a piece of the human layer that someone has to hold.

In an OPC, all of it concentrates on one person. The leverage on the AI-augmentable work is enormous. The leverage on the irreducible human layer is zero. Two hours of deep judgment work takes two hours regardless of how many AI tools the founder has access to. A relationship-building lunch takes the length of a lunch.

The practical implication: the founder's calendar has to be designed with this in mind. The AI-augmented work — drafting, research, analysis — can fit into compressed sessions. The irreducible human layer needs uncompressed time. Deep judgment calls do not happen well in twenty-minute slots between meetings. Real relationships are not built in optimised contact cadences.

The rhythm in 3.3 reflects this: protected build days, a deliberate clustering of external conversations, weekends used for either deep generative work or genuine rest. The structure is not about productivity. It is about leaving room for the work that cannot be compressed.

What goes wrong when the layer is denied

The failure mode is recognisable. A founder fully embraces the AI-first model, builds an excellent stack, achieves real leverage on the patterned work — and then notices, over months, that something is degrading. The decisions are less sharp. The relationships are less deep. The product or service has lost some indefinable thing that used to define it.

What happened is that the AI-augmentable surface area expanded to fill the available time, and the irreducible layer got squeezed. Drafting got faster, so there was more drafting. Research got faster, so there was more research. Outreach got faster, so there was more outreach. The founder spent more time on the work that responded to leverage, and less time on the work that did not — because the latter felt slow, and the former felt productive.

The correction is not less AI. The correction is to identify the irreducible layer explicitly, allocate uncompressed time to it, and protect that time from the more-of-everything pressure that AI augmentation creates. A founder who works only the human layer is too slow to survive. A founder who only works the AI layer is hollowed out. The integration is the work.

How to know if you have the balance wrong

Three signals show up reliably.

The output is more polished but less distinctive. AI is excellent at making things competent. If everything coming out of the company is technically good but no longer recognisable as yours, the taste layer is being skipped. The fix is to slow down and choose, not to add another AI tool.

Major decisions feel rushed. A genuine first-principles call needs sitting time. If every important decision is happening at the speed AI lets the surrounding work happen, the decisions are being compressed into a timescale they do not fit. The fix is to deliberately stretch the decision timeline, even when the rest of the work could move faster.

Relationships are shallow but numerous. AI lets you maintain contact with many more people than you could otherwise. If the number of conversations is up and the depth is down, something is wrong with the model of what relationships are for. The fix is to choose fewer relationships and go deeper, not to maintain the count.

→ Next: 6.2 Relationships AI cannot replace

Part of The OPC Manual · By Adine Tjeenk Willink

AI changes most things about how a founder works. It does not change what relationships are. This section is about which relationships actually move the company forward, why they cannot be optimised in the way drafting and research can be optimised, and how to design for them deliberately rather than letting them happen by accident.

Why this section exists

AI augmentation creates a tempting illusion: that all founder work, including the relational work, can be made more efficient. The mechanics certainly can. Follow-ups can be drafted faster. Notes from a conversation can be processed faster. The CRM can be updated faster. A founder using AI well can maintain contact with three to five times the number of people a previous-generation founder could.

The illusion is that the contact is the relationship. It is not. The contact is the surface. The relationship is what is happening underneath — the accumulating sense, in another person, that this founder is competent, trustworthy, and worth committing to. That accumulation is not faster with AI. In some ways it is slower, because the founder using AI heavily can mistake activity for depth and miss the signals that a relationship is actually progressing.

This section is about which relationships matter, why they matter in the way they do, and how to act on the distinction.

The organising principle

The relationships AI cannot replace are the ones where the other person is choosing the founder, not the company.

Most commercial relationships have two layers. There is the company layer — the offering, the price, the contract terms, the capability. And there is the founder layer — the human across the table, the specific person who built this thing and will be the one running it for the foreseeable future.

At early stage, the founder layer is the decisive layer. The buyer or partner is committing not just to the product but to the person. They are betting that this founder will make good decisions when things get hard, will be honest when things go wrong, will be there in a year. The commitment is to the human first.

This is the relationship category AI cannot replace. The company layer is fully AI-augmentable — better materials, sharper proposals, faster turnarounds. The founder layer is not, because what is being evaluated is the founder, not the surrounding apparatus.

Which relationships sit on this layer

Five categories of relationship are, in practice, founder-layer for an OPC. They follow different logics from the rest of the relationship portfolio and need different treatment.

Early enterprise buyers. Specifically, the buyers in the first wave — before the company has reference customers, public traction, or independent third-party validation. These buyers are taking a risk that no rational procurement department would normally accept. They are doing so because something about the founder convinces them it is the right risk. Every subsequent buyer benefits from these early ones. The early relationships do not scale, and they are not supposed to.

Strategic partners who hold something the company cannot build. Distribution access. Regulatory standing. A specific dataset. A specific institutional relationship. The partnership only works if both founders are willing to make it work — which means it depends on a level of mutual trust that takes time to establish and cannot be transferred. The partnership conversation is a series of human-to-human meetings, with the deal mechanics following the relationship, not leading it.

Investors who write the foundational cheques. Pre-seed and seed investors who are taking the same kind of bet the early buyers are. They are choosing the founder. Their cheque is, in part, an act of personal endorsement. The relationship continues through every subsequent round, and is the foundation on which later raises sit. Treating early investors as transactional is the most common version of this mistake.

The technical co-founder or first technical hire. If the company has a build component, the founder needs a counterpart on the technical side. Not a service relationship — a partnership. The trust between these two people is the most consequential trust in the company for the first two to three years. It is built through working together on hard problems and seeing how each handles them. It cannot be substituted.

Senior advisors with skin in the game. Two or three people, usually older, who have done the relevant thing before and who care personally about the founder's outcome. They are not on a retainer. They are on a relationship. Their willingness to take a 9pm call when something has gone wrong is what defines the value of their involvement — and that willingness is built by years of accumulated mutual respect, not by quarterly check-ins.

What these relationships are not

Clarifying the negative is useful. The five categories above are not:

Casual contacts. People the founder has met once and connected with on LinkedIn. These are weak ties. They have their own value — for warm intros, for opportunistic information — but they are not the relationships under discussion here. AI is excellent for maintaining weak ties; it is the wrong tool for the strong ones.

Buyers in the second wave onward. Once the company has reference customers and external validation, the buyer relationship shifts. It becomes more about the company layer and less about the founder layer. AI augmentation works much better here. The discipline is to recognise the shift when it happens — to stop treating later buyers as if they require the same founder-time investment as the early ones, because they do not and the founder cannot scale that level of attention.

Service providers. Lawyers, accountants, fractional specialists. These are transactional. The relationship can be cordial, even warm, but the structure is service-for-fee. AI is helpful for managing these efficiently. Founder time spent over-investing here is misallocated.

The team. Once the OPC stops being an OPC and there are hires, the team relationships are their own category — important, but governed by different logic than the external relationships above. This manual does not cover the team layer in depth because most OPCs are not yet there.

Why AI augmentation can degrade these relationships

The specific failure mode is worth naming. It is not that AI does damage. It is that AI lets the founder maintain a surface form of contact that feels like the relationship is fine, while the underlying relationship is starving.

The pattern looks like this. The founder uses AI to keep up with a partner — drafting check-in messages, surfacing news about their company, prompting follow-up at the right intervals. The contact cadence stays high. The CRM looks healthy. The relationship dashboard, if there were one, would be green.

Meanwhile, the partner has not actually spoken with the founder in eight months. The substance of the relationship — the slow accumulation of mutual understanding through actual conversation — has stopped. Two outcomes are possible. Either nothing comes up that tests the relationship, and the founder discovers nothing is wrong. Or something does come up — a competitive offer, a strategic question, a hard moment — and the partner realises the relationship is hollower than the contact cadence suggested, and acts accordingly.

This is not a hypothetical. It is the most common version of how AI-augmented founders lose ground on the relationships that matter most. The contact is up. The substance is down. The gap is invisible until the moment it matters.

How to design for the relationships AI cannot replace

Four practices, derived from doing this badly and then doing it less badly.

Name them explicitly. Make a list — fewer than ten people. These are the relationships that, if degraded, would meaningfully damage the company. The list is short. Most founders have at most six to eight names that genuinely belong on it. The act of naming forces the recognition that they are different from the rest of the portfolio.

Allocate real time, not optimised time. Each named relationship gets a real conversation — voice or in person — at a defined cadence. Monthly for the closest. Quarterly for the broader set. Not a check-in message. Not a comment on a LinkedIn post. An actual conversation, long enough for the substance to surface.

Do not delegate the founder layer to AI. AI prepares the founder for the conversation — research, talking points, recent news. AI does not have the conversation. AI does not write the follow-up that goes to a person in this category. The follow-up is short, in the founder's voice, and obviously written by the founder. The signal value of "I personally wrote this" is the point.

Notice when the relationship is decaying. Specific signals: the other person stops initiating. Responses get shorter. The cadence slips and is not corrected. When these show up, the response is not to lean on AI to re-establish contact. The response is to make a direct effort — a call, a visit, a deliberate investment of unaugmented time — to repair what has thinned.

What this means for how the OPC scales

The relationship layer is one of the load-bearing reasons most OPCs cannot scale infinitely with AI alone. There is a ceiling on how many founder-layer relationships one person can maintain — probably in the range of fifteen to twenty-five at full depth, well below the number an AI-augmented contact apparatus would suggest is possible.

The implication is not that the founder should try to push past the ceiling. It is that the founder should choose the right fifteen to twenty-five, and accept that everything else is on the company layer. The choice is strategic. The mistake is to try to keep every relationship at founder-layer intensity and run out of capacity for the ones that genuinely require it.

Growing beyond this ceiling — if the founder ever wants to — is one of the reasons to bring on a second person. Not because the company has more work than one person can do, though that may also be true. Because the founder has more relationships than one person can hold at the level those relationships require. That is the moment the OPC stops being an OPC, and it is a legitimate moment to choose deliberately. More on the related question in 3.5 and 6.3.

→ Next: 6.3 Designing a company that fits your life

Part of The OPC Manual · By Adine Tjeenk Willink · Artefact

A blank template for designing your own stack. Use it alongside 2.2 (what the stack needs), 2.4 (the Stratum example), and 2.3 (the decision framework for adding new tools).

How to use this template

Copy this template into your own Notion workspace. Fill in each layer with your current tools. Then ask three questions of each row:

Does this tool generate revenue or prevent a compliance failure? If neither, why is it here?

Could AI plus my human layer cover this function without the tool? If yes, why is it here?

If I removed this tool tomorrow, what specifically would break? If the answer is vague, the tool is not earning its place.

Anything that does not survive all three questions is either removed, downgraded to a free tier, or replaced by a process that uses tools already in the stack.

Then review the "not yet" section. Every tool listed there should have a defined trigger — a specific event or threshold that would justify adding it. "When we hit X." "When the founder spends more than Y hours per week on this manual step." "When the first contract closes." Without a trigger, "not yet" decays into "never decided."

Layer 1 — Input

Where data enters the system. Meeting capture, lead enrichment, prospect research, document intake.

Function	Tool	Tier	Monthly cost	Owner	Trigger that justified adding it
Meeting capture	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Lead enrichment	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Document intake	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]

Layer 2 — Brain

Where information is stored, processed, and turned into decisions.

Function	Tool	Tier	Monthly cost	Owner	Trigger that justified adding it
AI layer	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Knowledge base	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
CRM (if separate)	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]

Layer 3 — Output

Where decisions become action. Pipeline management, accounting, contract signing, communication.

Function	Tool	Tier	Monthly cost	Owner	Trigger that justified adding it
Pipeline management	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Accounting & invoicing	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Contract signing	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]
Scheduling	[TOOL]	[TIER]	[COST]	[OWNER]	[TRIGGER]

Automation layer

Sits across all three layers. Connects them so data flows without manual copying.

Tool	Tier	Monthly cost	Owner	Scenarios live
[TOOL]	[TIER]	[COST]	[OWNER]	[NUMBER]

Total monthly stack cost

[TOTAL] per month, covering [NUMBER] tools.

Cost target until first contract signed: under €500 per month.

Deliberately not in the stack

Every tool listed here should have a trigger that would justify adding it. If a row has no trigger, decide one now or remove the row.

Tool / category	Why not yet	Trigger that would change this
Customer success software	[REASONING]	[TRIGGER]
Marketing automation	[REASONING]	[TRIGGER]
BI / data visualisation	[REASONING]	[TRIGGER]
HR tools	[REASONING]	[TRIGGER]
Dedicated sales enablement	[REASONING]	[TRIGGER]
[OTHER]	[REASONING]	[TRIGGER]

Review cadence

This page is reviewed every [QUARTER / SIX MONTHS]. Each review answers:

Which tools have stopped earning their place? Remove.

Which triggers have fired since the last review? Decide on addition or defer.

Which functions have grown into bottlenecks the current stack does not address? Identify the function before searching for the tool.

→ Related: 2.2 Building the stack · 2.4 A real example: the Stratum stack · 2.3 The stack decision framework

Part of The OPC Manual · By Adine Tjeenk Willink · Artefact

A blank starter structure for the operating brain of an OPC. Use it alongside 3.1 (the reasoning behind the architecture).

How to use this starter structure

This is the minimum viable OPC workspace. Seven pages, in a defined order, with defined purposes. Everything else — the intelligence layer, the detailed operations pages, the financial model — is added as need appears.

The sequence matters. Build in the order below. Skipping ahead produces a workspace that looks complete but does not function as an operating system.

For each page, the template includes: the page's purpose, the minimum content it needs, the owner, the maintenance cadence, and the failure mode to watch for. Fill in the bracketed sections as you build.

Page 1 — Homepage

Purpose: a single page that links to everything. A navigational anchor, not a dashboard with live data. When you open the workspace, you should be able to get to any page within two clicks from the homepage.

Minimum content:

Links to the six other pages below

A one-line description of what each page is for

The current week's brief (linked from the weekly rhythm)

Owner: [FOUNDER]

Maintenance cadence: reviewed weekly. If a page is added to the workspace, the homepage gets the link the same day.

Failure mode to watch: the homepage stops being the entry point. People (including AI) start navigating by search instead. When that happens, the homepage has become decorative — rebuild it as a real navigation tool.

Page 2 — Operating Context (your CLAUDE.md or equivalent)

Purpose: a plain-language document that explains to your AI — at the start of every session — what the company is, what stage it is at, what the current priorities are, what language and framing to use, and what has been decided previously.

Minimum content:

What the company does (one paragraph, plain language)

Current stage and immediate priorities

Key decisions already made (so AI does not re-litigate them)

Working style preferences (tone, format, level of detail)

Tool access ethics (what AI may do autonomously, what requires confirmation)

Lessons log — corrections and patterns to avoid repeating

Owner: [FOUNDER]

Maintenance cadence: updated every time something significant changes. New strategic decision, new tool, new lesson from a mistake.

Failure mode to watch: the document goes stale. Every AI session starts with twenty minutes of catch-up. When this happens, the document has stopped being a live brief and become documentation. Reload it from scratch if needed.

See: 7.3 CLAUDE.md template

Page 3 — Inbox

Purpose: a single page that serves as the unstructured entry point. When something comes in — a new idea, a piece of market news, a meeting note that hasn't been processed yet — it goes to the Inbox first.

Minimum content:

A single page or database for inbound items

A clear processing rule: nothing stays in the Inbox longer than one week

Owner: [WHOEVER PROCESSES IT]

Maintenance cadence: processed at least weekly. Items are either: filed to the right home, turned into actions, or deleted.

Failure mode to watch: the Inbox becomes a graveyard. Items accumulate and nothing gets processed. When this happens, either the processing cadence is too slow or items are being added that should not be in the workspace at all.

Page 4 — Pipeline database

Purpose: the operational view of every active commercial conversation. Where every prospect is, what the next action is, who owns it, and what it is worth.

Minimum schema:

Field	Type	Purpose
Name	Title	The prospect or account
Stage	Select	Left-side stages (Target → Qualified → Proposal → Negotiation → Closed Won) through to right-side stages (Onboarding → Active → Expansion → Renewal)
Sentiment	Select	Cold / Warm / Hot — the founder's read on how the conversation is going
Contract value	Number	Expected annual contract value
Probability	Number (%)	Founder's estimate of close probability
Weighted value	Formula	Contract value × probability
Next action	Text	The single next step
Next action date	Date	When the next action is due
Last contact	Date	When the prospect was last contacted
Owner	Person	Who is moving this forward

Owner: [FOUNDER OR COMMERCIAL LEAD]

Maintenance cadence: reviewed weekly on the orient day. Every active row must have a next action with a date. End-of-Friday closeout updates anything that moved during the week.

Failure mode to watch: rows without next actions. When this happens, the pipeline has stopped being operational and become a list of contacts. Rebuild the discipline: every row, every week, has a defined next step.

Page 5 — Meeting Log

Purpose: every meeting captured, with notes, action items, and a clear meeting type distinguishing acquisition meetings (left-side) from delivery meetings (right-side).

Minimum schema:

Field	Type	Purpose
Title	Title	Meeting name and date
Date	Date	When the meeting happened
Meeting type	Select	Left side: Intro Call, Demo, Negotiation, Partnership. Right side: Check-in — Active, Expansion, Renewal.
Related account	Relation	Links to the Pipeline database
Notes	Text	What was discussed (or a link to the captured transcript)
Action items	Text	What needs to happen next

Owner: [FOUNDER OR COMMERCIAL LEAD]

Maintenance cadence: every meeting logged within 24 hours.

Failure mode to watch: meetings get logged but the Meeting Type field stays blank. The distinction between left-side and right-side meetings is the point — without it, the log loses analytical value.

Page 6 — Customer Success & Delivery playbook

Purpose: the operating manual for everything that happens after a contract is signed. Onboarding SOP, check-in cadence, first-impact definition, expansion playbook.

The discipline: write this before you have any customers. By the time you have customers to manage, you are improvising under pressure — which is the worst time to design a system.

Minimum content:

Onboarding SOP: the first 30 days after a contract signs

Check-in cadence: how often you talk to active buyers and what each check-in covers

First impact definition: what "working" looks like for a buyer

Expansion playbook: when and how to propose additional scope

Renewal playbook: when and how the renewal conversation starts

Owner: [FOUNDER OR DELIVERY LEAD]

Maintenance cadence: reviewed after every active buyer's first 30 days. Lessons feed back into the playbook.

Failure mode to watch: the page exists but does not get activated when the first buyer signs. The first buyer should be onboarded against this playbook. If the playbook is being invented during the onboarding, it was written too late.

Page 7 — Metrics page

Purpose: a single view of the key numbers, with left-side and right-side metrics tracked separately.

Minimum content:

Side	Metric	Current value	Target
Left	Qualified opportunities	[N]	[TARGET]
Left	Conversion rate (Target → Closed Won)	[%]	[TARGET]
Left	Sales cycle length (days)	[N]	[TARGET]
Left	Contracted value (cumulative)	[VALUE]	[TARGET]
Right	Time to first impact (days)	[N]	[TARGET]
Right	Buyer satisfaction	[SCORE]	[TARGET]
Right	Renewal rate	[%]	[TARGET]
Right	Net Revenue Retention	[%]	[TARGET]

Owner: [FOUNDER]

Maintenance cadence: updated weekly (left-side) and monthly (right-side, once there is delivery to measure).

Failure mode to watch: only left-side metrics tracked. When this happens, the company optimises for closing and neglects delivery. Both sides are the business.

Build sequence

The seven pages above are the minimum viable OPC workspace. Build in this order:

Homepage (even if it links to nothing yet — the navigation anchor comes first)

Operating Context (your AI brief — even a rough version is better than nothing)

Inbox (the unstructured entry point)

Pipeline database (the bow tie made operational)

Meeting Log (with Meeting Type field)

Customer Success playbook (before you have customers)

Metrics page (with both sides tracked, even if the current values are all zero)

Architecture rules to enforce as the workspace grows

Six rules that prevent the workspace from becoming a graveyard.

1. Page titles are navigation tools. Every page title should tell you exactly what is in the page. "Commercial" is ambiguous. "Go-to-Market / Sales & Marketing" is not.

2. Every database needs a purpose before it has a schema. If two databases serve the same purpose, merge them. If they serve different purposes, keep them separate even when the schemas look similar.

3. Inline links over manual duplication. When one page needs to reference another, link. Never copy content between pages — copied content diverges.

4. One database per distinct purpose. Do not build one database to do everything. Buyer pipeline and partner pipeline are distinct purposes and should be distinct databases.

5. Every page has an owner. If no one owns a page, the page does not exist. Archive it.

6. Don't build what you won't maintain. Unmaintained pages are worse than no pages — they create the impression of information that may be stale. When in doubt: archive, don't keep.

→ Related: 3.1 Your knowledge base as a brain · 7.3 CLAUDE.md template · 3.2 Working with AI: sessions, not searches

Part of The OPC Manual · By Adine Tjeenk Willink

Copy this template into a Notion page in your own workspace. Fill in the bracketed placeholders with your own context. Review and update it every 4–6 weeks as your company evolves. The more specific and honest you make it, the better Claude performs.

This is not a one-time setup. It is a living document. Treat it like an onboarding brief you rewrite every quarter.

What is this page?

This is your reusable context brief. Load it at the start of any Claude session to eliminate ramp-up time and get sharper outputs immediately. Update it as your company evolves.

Legal & Entity Structure

[Legal entity name] is the legal entity behind all commercial activity

[Brand / trading name] is the brand name for [your business area] — [note whether it is a legal entity and whether it is trademarked]

[Company name] is [working title / confirmed name] — [note any trademark status or naming uncertainty]

[ your@email.com] is the primary professional inbox

The Company

[Company name] is a [one-sentence description: what it does, for whom, and how].

We are in [stage: pre-revenue / early commercial / growth] phase, targeting [commercial goal and timeline].

We operate as [team structure: solo / 1–3 people / lean team].

The Two Customer Types

(Adapt to your model. If you have one customer type, remove one section.)

[Primary customer — Revenue]

Who: [Description]

What they care about: [3–5 things]

How we sell: [Sales motion]

Qualification filter: [How you decide if they're worth pursuing]

[Secondary customer or Partner — Supply / Distribution]

Who: [Description]

What they care about: [3–5 things]

How we work together: [Partnership model]

Qualification filter: [How you decide if they're worth pursuing]

The Business Model (Plain Language)

[Describe in 4–6 bullet points how value is created and delivered. Write it as if explaining to a smart person who knows nothing about your industry. This is the section Claude will use to reason about your commercial decisions.]

Regulatory or Compliance Position

(Include only if relevant. Delete if not.)

[Describe any regulatory tailwinds, compliance requirements, or frameworks that affect how you operate or sell.]

Competitive Framing

We are not [common misconception 1]

We are not [common misconception 2]

Closest competitors: [Brief description of competitive landscape]

Our edge: [What actually differentiates you]

Key Decisions Already Made

(List your confirmed stack and structural decisions. This stops Claude from suggesting tools or approaches you've already ruled out.)

Legal structure: [Country / entity type]

Accounting: [Tool]

CRM: [Tool]

Knowledge base: [Tool]

Project management: [Tool]

Banking: [Tool]

Contracts: [Tool]

[Add others as relevant]

How I Work

Communication style: [e.g. Direct. Conclusion-first. No fluff.]

Meeting structure: [e.g. Agenda in advance. Action items with owners.]

Decision-making: [e.g. 80/20 bias. Fast on tactics, slow on partner selection.]

AI philosophy: [e.g. AI drafts, I approve. Nothing external without a human read.]

Tasks I use Claude for: [List the 4–6 recurring task types]

My Background (Relevant Context)

(Include only what is relevant to how Claude should interpret your decisions and voice.)

[Founder background: previous companies, roles, sectors]

[Investor or operator experience if relevant]

[Other active roles running in parallel]

[Location / timezone]

Current Priorities

(Update this section every 4–6 weeks. Stale priorities produce stale outputs.)

[Priority 1]

[Priority 2]

[Priority 3]

[Priority 4]

[Priority 5]

Output Preferences

When working with me, Claude should:

Lead with the conclusion or recommendation

Use structured formats (tables, numbered lists for actions, headers for sections)

Flag risks and open questions explicitly — don't bury them

Skip preamble and engagement padding

Assume I know the context — don't re-explain what [company name] is unless I ask

For external comms: apply 100% attention to detail

For internal work: 80/20 is fine

Session Discipline

Operating principles for how Claude works with you. Applies to all substantive work — commercial, technical, and written.

Tradeoff to name explicitly: these guidelines bias toward caution over speed. They apply to reversible-but-costly work (proposals, outreach, financial models, decks, code that touches live systems). For low-stakes, fully reversible work, 80/20 execution wins — don't over-apply this.

Derived in part from Andrej Karpathy's observations on LLM coding pitfalls, adapted for operator work.

1. Think Before Acting

Don't assume. Don't hide confusion. Surface tradeoffs.

Before executing any non-trivial task (3+ steps, commercial decision, outreach strategy, partner evaluation, technical build):

State the plan upfront before executing

State assumptions explicitly. If uncertain, ask.

If multiple interpretations exist, present them — don't pick silently.

If a simpler approach exists, say so. Push back when warranted.

If something is unclear, stop. Name what's confusing. Ask one question at a time.

Write a brief spec or structure before drafting, not after

Flag if the approach changes mid-task — don't keep pushing if something goes sideways

2. Simplicity First

Minimum viable output. Nothing speculative.

No features, sections, or slides beyond what was asked

No abstractions, frameworks, or "configurability" that weren't requested

No error handling or caveats for scenarios that won't occur

For code: if 50 lines would do, don't write 200

For decks and docs: if 6 slides land harder than 12, cut to 6

For outreach: one clear ask per message, not three

The test: "Would a senior operator / senior engineer say this is overcomplicated?" If yes, simplify.

3. Surgical Changes

Touch only what you must. Match existing style.

When editing existing work (Notion pages, decks, code, drafts):

Don't "improve" adjacent content, formatting, or structure that wasn't in scope

Don't refactor or restyle things that aren't broken

Match the existing voice and format, even if you'd do it differently

If you notice unrelated issues, mention them — don't silently fix them

When your changes create orphans (stale cross-references, broken links, unused sections), remove the ones your changes created. Don't remove pre-existing debt unless asked.

The test: every changed line should trace directly to the request.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:

"Draft the [prospect] follow-up" → "Draft a follow-up that (a) confirms the [next step], (b) answers their [open question], (c) lands under [word count]"

"Build the [X] slide" → "Produce a slide that [target audience] could read in 15 seconds and take away [one specific thing]"

"Add validation to the form" → "Write tests for invalid inputs, then make them pass"

For multi-step tasks, state a brief plan with verification checks:

1.[Step] → verify:[check]2.[Step] → verify:[check]3.[Step] → verify:[check]

​

Completion rule: never mark a task complete without confirming it works for its purpose.

External outputs (outreach, proposals, decks): explicitly check tone, framing, factual accuracy before presenting

Commercial tasks: a prospect is only "progressed" when a concrete next step is confirmed — not when a message is sent

Strong success criteria let Claude loop independently. Weak criteria ("make it work") require constant clarification — so define the criteria up front.

5. Self-Improvement Loop

After any correction, note the pattern to avoid repeating it

Review the Lessons Log at the start of sessions involving sales, proposals, or partner outreach

Write rules that prevent the same mistake from recurring

Tool Access Ethics

Rules for how Claude interacts with connected tools that touch live external systems. These rules are non-negotiable.

Calendar

Principle: Read freely. Write only on explicit instruction.

Claude may read and search calendar events freely

Claude may only create, update, or delete events when explicitly instructed

Before any write action: state the event title, date, time, location, and any other fields — wait for confirmation before proceeding

Never modify an existing event unless the instruction explicitly names that event

Always verify the event ID maps to the correct event title before writing — fetch and confirm if uncertain

After any write action: read back the confirmed details and flag any discrepancy immediately

Never infer or assume event details — if anything is ambiguous, ask first

Gmail

Principle: Read and draft freely for priority contacts. Never send autonomously.

Always permitted — no confirmation needed:

Read and search emails

Summarise threads or inbox

Draft emails for priority contacts (saved to drafts, never sent)

Extract action items or follow-ups from threads

Flag spam and promotional content with a suggested action

Requires explicit confirmation before acting:

Applying labels or archiving

Marking as read/unread in bulk

Unsubscribing from mailing lists

Deleting any email or thread

Absolute rule — no exceptions:

Claude can never send an email. You must physically press send. Always.

Claude may not feed email content into external systems without stating intent first

Priority Email — Definition

Priority email = any email where commercial progress, partner relationships, or professional reputation is at stake.

Claude drafts proactively for:

[Active prospects and enterprise buyers]

[Supply-side or distribution partners]

[Technical or delivery partners]

[Inbound leads relevant to the business]

[Time-sensitive follow-ups where delay risks momentum]

[Any other fund, investment, or professional correspondence]

Claude does not draft proactively for:

Personal email

Anything where you haven't yet decided what you want to say

[Any other roles or inboxes you want to exclude]

Daily Briefing

Trigger prompt — run manually each morning:

"Claude, give me my daily briefing. Check my calendar, inbox, and Notion and tell me what matters today and in what order."

Briefing covers:

What's on the calendar today

What's in the inbox that needs attention (priority emails first, flagged spam separately)

What's open in Notion that is time-sensitive or commercially relevant

Prioritisation logic:

Time-sensitive external commitments first

Commercial momentum second

Internal and admin last

Format: short narrative, not a list.

How to Get Better Output from Claude

Load context at session start — state the goal, any background not in memory, and the desired output format

State the decision, not just the topic — "I need to decide X" produces sharper output than "help me think about Y"

Specify output mode — thinking partner (exploratory) vs. ready-to-use output (draft/doc/analysis)

End sessions with a lesson — write the Lessons Log entry before closing

Use Socratic framing for high-stakes prep — ask Claude questions about the problem before asking for deliverables

Claude's questioning rules

Ask clarifying questions mid-task when anything is unclear — don't assume

Ask one question at a time, never batch multiple questions

Lessons Log

Updated after corrections. Review before sales, outreach, and proposal work.

#	Lesson	Context
—	(no entries yet — add after first correction)	—

Template version: March 2026. Part of The OPC Manual by Adine Tjeenk Willink. See 3.2 for the full tutorial on working with AI as connected infrastructure.

Part of The OPC Manual · By Adine Tjeenk Willink

These are the prompts I use regularly. Copy, adapt, make them yours. The more specific you make them to your own context, the better the output.

Daily operating prompts

Daily briefing

Run at the start of your working day. Pulls from calendar, inbox, and Notion.

"Claude, give me my daily briefing. Check my calendar, inbox, and Notion and tell me what matters today and in what order."

What it returns: A short narrative covering today's calendar, priority inbox items, and open Notion tasks — prioritised by time-sensitivity, then commercial momentum, then admin.

Session start

Use when opening a working session with a specific goal.

"I'm starting a session on [topic]. The goal is [specific output]. Background: [any context not in CLAUDE.md]. Format: [narrative / draft / structured doc / thinking partner]."

End of session — lessons log

Run before closing any session where a correction was made.

"Before we close: summarise any corrections you received this session and write a Lessons Log entry for the CLAUDE.md file."

Tool access prompts

Calendar — check upcoming events

"What's on my calendar this week?"

Calendar — create event

"Create an event on [date]: [title], [time], [location]. Before you do, tell me exactly what you're going to write and wait for my confirmation."

Gmail — inbox triage

"Check my inbox. Summarise anything priority. Flag any spam or promotional content separately with a suggested action."

Gmail — draft a reply

"Draft a reply to [sender / subject]. Tone: [direct / warm / formal]. Save to drafts — do not send."

Commercial prompts

Pre-call preparation

"I have a call with [role, company] on [date]. Ask me questions about what I want to achieve before you help me prepare."

Follow-up email draft

"Draft a follow-up email after my call with [role] today. Key points covered: [list]. Next step we agreed: [next step]. Tone: direct, professional, warm."

Prospect research

"Research [company name] as a potential enterprise buyer. I need to know: their RWE or real-world data activity, relevant team members, any public statements on digital biomarkers or female health, and how to frame our conversation."

Demo building prompts

Lovable — full demo build prompt

Use this as your first message in a new Lovable project. Replace everything in square brackets with your specifics. Front-load the entire specification — do not iterate from a skeleton.

Build a professional B2B data platform demo called [PLATFORM NAME]. The tagline is: "[ONE LINE DESCRIPTION OF WHAT THE PLATFORM DOES FOR THE BUYER]"

Design direction: Clean, minimal, professional. [PRIMARY COLOUR hex] and white base, single accent colour [ACCENT COLOUR hex]. Sans-serif typography (Inter). No illustrations, no stock photos. Data is the visual. Remove all Lovable branding.

GATE: The very first screen a visitor sees is a full-page email capture wall. No navigation, no content visible behind it. Centre card on a dark background. Show the platform logo at the top.

Headline: "Request access to the [PLATFORM NAME] platform"

Subtext: "[ONE LINE ON WHO USES IT AND WHY]"

Form fields: Full name, Work email (required), Organisation, Role (dropdown: [LIST YOUR BUYER ROLES])

Submit button: "Access Platform"

On submit: (1) validate work email — reject gmail/hotmail/yahoo with inline error "Please use your work email address", (2) save to Supabase table called access_requests with columns: id, full_name, email, organisation, role, created_at, (3) grant immediate access — no confirmation email needed, (4) gate should not reappear for that browser session.

Below the form: "Your data is processed in accordance with GDPR. We will not share your information with third parties."

After the gate — main platform: top navigation with [PLATFORM NAME] logo (text only), [LIST YOUR MODE TABS], and a "Request Full Access" button (accent colour, top right).

MODE 1: [EXPLORER MODE NAME]

[Describe your filter sidebar: what dimensions, what options, what the live cohort number shows]

[Describe your stat cards: what numbers, what labels]

[Describe your data table: columns, pre-populated rows with realistic synthetic data]

[Describe drill-down behaviour: what happens when a row is clicked, what Level 2 and Level 3 show]

MODE 2: [AI CHAT MODE NAME]

Left panel: suggested questions. Right panel: chat interface.

Suggested questions: [LIST 5 QUESTIONS RELEVANT TO YOUR BUYER'S RESEARCH QUESTIONS]

AI integration: Connect to Anthropic API using model claude-haiku-4-5-20251001.

System prompt: "You are the [PLATFORM NAME] Research Assistant. [DESCRIBE YOUR PLATFORM, YOUR DATASET, AND HOW THE AI SHOULD BEHAVE. INCLUDE: dataset size, data types, how to respond — specific, data-grounded, professional. End with: Never break character. Never say you are Claude or an AI."]

API key configured as a constant at the top of the code: const ANTHROPIC_API_KEY = "REPLACE_WITH_KEY"

AI responses must render as formatted markdown — bold, headers, bullet points displaying properly, not as raw asterisks.

Additional pages:

About [PLATFORM NAME]: [ONE PARAGRAPH describing what the platform does, who uses it, and your compliance/trust credentials]

Three icons with labels: [YOUR THREE TRUST SIGNALS e.g. GDPR Compliant / Research-Ready / Longitudinal Data]

Request Full Access modal: Fields: Name, Organisation, Role, Research area of interest (dropdown: [YOUR USE CASES]), Message. Submit saves to Supabase table full_access_requests. On submit: "Thank you. The [PLATFORM NAME] team will be in touch within 2 business days."

Supabase: Use Lovable's native Supabase integration. Create two tables: access_requests and full_access_requests. Both with created_at auto-populated.

Build as a single React app. Tailwind for styling. Fully responsive. No login system needed beyond the gate. Works as a standalone shareable URL. Should feel like a real product your buyer would trust.

What to replace before pasting:

Platform name, tagline, colours

Buyer roles in the gate dropdown

Mode names and descriptions

Synthetic data rows (make these specific to your buyer's use case — not generic)

The AI system prompt (this is the most important thing to customise — the more specific the dataset description, the better the AI responses)

The suggested questions (use questions your buyer actually asked you in a real conversation)

Trust signals and compliance framing relevant to your sector

After the build:

Add your Anthropic API key as a Lovable secret (Cloud → Secrets → name it ANTHROPIC_API_KEY) — do not hardcode it in the code

Test the gate in an incognito window before sharing with any buyer — confirm it blocks access until email is submitted

Check Supabase access_requests table to confirm gate submissions are logging correctly

Test the AI chat interface — ask one question and confirm it returns a formatted response, not raw asterisks

Export to GitHub → deploy to Vercel before cancelling Lovable Pro

Thinking partner prompts

Decision framing

"I need to decide [X]. Ask me questions to help me think it through before you give me a recommendation."

Challenge my thinking

"Here is my current position on [topic]: [position]. Challenge it. What am I missing or assuming?"

Prioritisation

"Here are the things I need to do this week: [list]. Help me prioritise them given my commercial goal of [goal] and my constraint of [constraint]."

Part of The OPC Manual · By Adine Tjeenk Willink · Artefact

A blank template for designing your own week. Use it alongside 3.3 (the reasoning behind the rhythm).

How to use this template

Copy this template into your own Notion workspace. The structure is opinionated but the contents are yours. The exercise has three steps.

Step 1. Decide the dominant mode for each day. The default modes are: orient, build, operate, sell, write or rest. You can use these, or adapt — but each day should have exactly one dominant mode, and the modes across the week should cover the four functions every OPC has to do: planning, doing, maintaining, and selling.

Step 2. For each mode, decide what does and does not happen on that day. Specificity matters more than ambition. "Friday is for sales" is too loose. "All discovery calls cluster on Friday, slot length defaults to 30 minutes, Granola runs on every call, pipeline closeout by 6pm" is operational.

Step 3. Decide your review cadence. Most rhythms drift within two to four weeks if not reviewed. A weekly check (typically as part of the Monday orient session) is usually enough to catch drift early.

Day-by-day mode design

Monday — Orient

Purpose: load the week into your head before doing any of the week's work.

What happens on this day:

[PIPELINE REVIEW: define the scope — buyer pipeline, partner pipeline, fund pipeline, etc.]

[WEEK'S BRIEF: three to five lines answering "what is the one outcome that defines a successful week?"]

[AI SESSION: weekly priorities — what's missing, what's at risk, what's going cold]

[OTHER ORIENTING WORK SPECIFIC TO YOUR COMPANY]

What does not happen on this day:

[LIST THE THINGS THAT DO NOT BELONG ON MONDAY]

Test that the day worked: can you state in one sentence what the week is about? If not, Monday did not do its job.

Tuesday — Build

Purpose: deep work on the things only you can do.

What happens on this day:

[COMMERCIAL DELIVERABLES THAT MOVE MONEY: proposals, decks, financial models, contract structures]

[STRATEGIC DECISIONS: positioning, partner selection, hiring, fundraising prep]

[FOUNDER-REQUIRED CONVERSATIONS: only the ones that cannot be delegated]

What does not happen on this day:

Discovery calls (those cluster on Friday)

Operational admin (that lives on the operate day)

Anything reactive that could happen tomorrow

Test that the day worked: can you point to a deliverable that did not exist this morning?

Wednesday — Operate

Purpose: the internal cadence that keeps the company running.

What happens on this day:

[FINANCIAL CADENCE: weekly check on cash, invoices, costs, runway]

[KNOWLEDGE BASE HYGIENE: new pages get owners, stale pages get archived]

[SOPS AND TEMPLATES: anything done twice that will be done again, write it down]

[TOOLING DECISIONS: tool experiments, integration testing]

[PERSONAL ADMIN: bills, appointments, anything taking up mental space]

The three things this day must produce:

[DEFINE IN ADVANCE]

[DEFINE IN ADVANCE]

[DEFINE IN ADVANCE]

If those three things are not done by end of Wednesday, the rest is overflow and goes to next Wednesday.

Thursday — Build

Purpose: second build day. Same logic as Tuesday.

What happens on this day:

[SAME CATEGORIES AS TUESDAY]

What does not happen on this day:

[SAME EXCLUSIONS AS TUESDAY]

Test that the day worked: same test as Tuesday.

Friday — Sell

Purpose: all commercial conversations cluster here.

What happens on this day:

[DISCOVERY CALLS: default slot length, link, prep cadence]

[BUYER FOLLOW-UPS]

[PARTNER INTROS]

[END-OF-FRIDAY PIPELINE CLOSEOUT: 20 minutes, every prospect's stage and next action updated]

Mechanics:

Booking link exposes Friday slots only: [LINK]

Default slot length: [30 / 45 / 60] minutes

Meeting capture runs on every call: [TOOL]

Pipeline closeout end-of-day: yes / no [REQUIRED]

Test that the day worked: at 6pm Friday, is the pipeline a true reflection of where every active conversation stands?

Weekend — Write or Rest

Purpose: generative work that benefits from uninterrupted time, or genuine rest. Not catch-up.

Legitimate uses:

Long-form writing, deep strategy, learning — work where the cost of starting and stopping is high

Actual rest — off, not a low-energy version of work

Illegitimate uses:

Catch-up on work the week did not finish. If this is happening, the week was wrong; reshape next week, do not absorb on weekend.

Daily layer

Each day has a smaller shape underneath the weekly layer.

When	What	How long
Morning	Daily briefing — Calendar, Inbox, Knowledge Base. What matters today and in what order.	5 minutes
Mid-morning to early afternoon	The day's dominant mode (build, operate, sell)	Block
Late afternoon	AI session to stage tomorrow — load context, draft what can be drafted	20 minutes
End of day	Pipeline and briefing closeout — what moved, what didn't, tomorrow's one priority	5 minutes

Drift signals — watch for these

Three patterns indicate the rhythm is leaking. Catch them on the weekly review.

Mode contamination. A call that belongs on Friday accepted into a Tuesday slot. One exception is fine. A pattern of exceptions means the day's mode is no longer real.

Trigger: more than one exception per week.

Response: either decline future exceptions, or formally redesign the day.

Operate-day drift. Wednesday becomes the day where everything that does not fit elsewhere lives, and it bloats.

Trigger: the three things Wednesday must produce are not being produced reliably.

Response: shorten the Wednesday list, push overflow to next Wednesday.

Build-day collapse. A build day starts with one quick call, then a Slack thread, and by noon there is no deliverable in sight.

Trigger: end-of-day check shows no deliverable for a build day.

Response: write the day's intended deliverable on Monday; check it the night before.

Review cadence

This rhythm is reviewed [WEEKLY / MONTHLY] as part of the Monday orient session. The review answers:

Did the modes hold this week, or did contamination happen?

Are the three Wednesday things being produced reliably?

Are build days actually producing deliverables?

Is the weekend being used for write/rest, or absorbing catch-up?

Adjust no more than one element per review. Rhythms drift faster than they can be redesigned.

→ Related: 3.3 The weekly rhythm of an OPC · 3.2 Working with AI: sessions, not searches · 3.4 Decision-making alone