ops model
the base code of a company
a company is a program that runs on people. it takes in capital, information, and effort, and it produces goods, services, and — if the program is well-written — returns that exceed its inputs. like all programs, it has architecture. it has dependencies. it has loops, conditionals, error handling, and state. unlike software, most companies never write this code down. the logic lives in people’s heads, in cultural norms, in habits that developed by accident, in the founder’s intuition. when the founder leaves the room, the program degrades. when a key employee quits, entire processes are lost.
so here i am with a pitch for a new concept, im going to call an operating model. tactically it’s a ~50 tab spreadsheet. the operating model is the source code of the company, made explicit.
what it’s not
not a business plan — that’s a marketing document dressed as strategy.
not a pitch deck — that’s a compression artifact, lossy by design.
the operating model is the actual logic of the business: what it believes, how it operates, how it learns, how it breaks, and how it repairs itself. written in plain language, structured in interconnected modules, designed to be read by both humans and machines.
for most of business history, the operating model — to the extent anyone built one — was a biz plan + some sop’s. maybe binder. a wiki. the problem was not that founders lacked the discipline to build these systems. the problem was that the return on articulation was too low.
you could spend forty hours documenting your decision-making framework, your hiring criteria, your integration playbook, your competitive positioning — and the document would sit there, inert. it could not answer questions. it could not reason about its own contents. it could not identify contradictions between tab twelve and tab thirty-seven. it was a reference, not a participant.
in the llm era, the operating model is a participant.
when the entire logic of a business — its thesis, its assumptions, its unit economics, its organizational structure, its feedback loops, its risk register, its hiring scorecards, its lalalala — is written in a structured, machine-readable artifact, it becomes something that did not exist before: an organizational brain that can be queried, stress-tested, and reasoned with. it’s also just ur base code you know.
ask the model: “what happens to our unit economics if acquisition multiples rise from 3.5x to 5x?” the answer is not in any single tab. it lives in the relationship between the thesis tab, the unit economics tab, the capital stack tab, and the exit math tab. an llm can do this natively. it reads the entire codebase at once and reasons across modules.
when i think about what base code actually is in software.
it is not the product. it is the substrate from which the product emerges. the base code defines the architecture — what’s possible, what’s constrained, what’s easy to change and what requires a refactor. good base code makes the first feature and the hundredth feature equally natural to build. bad base code makes every new feature a hack on top of a hack, until the whole system becomes so brittle that a small change in one module breaks three others.
companies work the same way. the “base code” of a company is the set of structures, assumptions, and processes that determine how decisions get made, how information flows, how people are hired and deployed, and how the organization responds to new information. most companies develop this code implicitly, through accumulated precedent. the first hire sets a precedent for how hiring works. the first deal sets a precedent for how deals get structured. the first conflict sets a precedent for how conflict gets resolved. over time, these precedents calcify into “how we do things” — an unwritten codebase that no one can fully read, debug, or refactor.
the operating model is the decision to write the base code explicitly and before execution begins. this is not waterfall thinking. it is not the belief that you can predict the future. it is the recognition that articulated assumptions are infinitely easier to update than tacit ones. you cannot refactor code you never wrote. you cannot debug a process you never documented. you cannot delegate a decision you never framed.
the model is designed to be wrong. its value is not in its accuracy — it is in its specificity (which doesn’t mean not designing in variety — one can be specific while still enabling a lot of variance). every assumption, stated plainly, becomes a surface for learning. every collision with reality updates the codebase. the operating model is not a plan that resists change. it is an architecture that accelerates change by making every piece of new information maximally useful.
in the llm era, the explicit codebase has a second property that the implicit one never could: it is computationally accessible.
consider what this means in practice. a founder builds a fifty-module operating model. each module covers a domain: thesis, validation, team structure, deal flow, unit economics, capital strategy, integration playbook, risk register, hiring criteria, competitive landscape, and so on. the modules reference each other. the thesis module constrains the unit economics module. the capital strategy module constrains the hiring timeline. the hiring timeline constrains the integration capacity. the integration capacity constrains the deal pace. pull one thread and the whole system moves.
now the founder sits down with an llm that has ingested the entire model. the conversation is no longer “help me think about my business.” it is “help me think within my business.” the llm is not reasoning from generic first principles about startups. it is reasoning from this specific architecture — these assumptions, these constraints, these dependencies, these open questions. it can identify tensions the founder hasn’t noticed. it can trace second-order effects across modules. it can simulate scenarios against the actual structure of the business, not against some abstracted version of it.
this is the difference between asking a consultant for advice and handing them your entire codebase and saying “run the tests.” the operating model is the test suite. every assumption is a test case. every dependency is an integration test. every feedback loop is a monitoring system. the llm can run all of them simultaneously, surfacing failures that would take a human team weeks of meetings to identify.
in software, there is a concept called separation of concerns. each module handles one domain. the authentication module does not know about the payment module. the payment module does not know about the notification module. they communicate through well-defined interfaces. this makes the system maintainable, testable, and delegable — any developer can work on any module without understanding the entire codebase.
the operating model applies separation of concerns to a company. each tab is a module. each module covers one domain of decisions. the thesis tab does not contain hiring criteria. the hiring tab does not contain capital strategy. they are connected through explicit dependencies — the thesis constrains the icp, the icp constrains the deal flow, the deal flow constrains the capital needs, the capital needs constrain the hiring timeline — but each module can be owned, updated, and stress-tested independently.
this means the operating model is natively delegable. when you hire a head of operations, you hand them ten modules and say: “these are yours. rebuild them.” they do not need to understand the fundraising strategy to own the integration playbook. they do not need to understand the competitive landscape to build the hiring scorecard. they need to understand the interfaces — the inputs their modules receive from other modules and the outputs their modules provide — but the internal logic is theirs to rewrite.
in the llm era, this modularity has a compounding benefit. each module can be independently queried, analyzed, and improved by an ai. “review the integration playbook for gaps.” “stress-test the unit economics under a recession scenario.” “identify contradictions between the hiring criteria and the team structure.” these are module-level operations that produce system-level insights. the operating model’s architecture makes this possible in the same way that well-structured code makes automated testing possible.
the most important property of base code is that it compounds.
in software, good architecture makes the first feature and the thousandth feature equally cheap to build. each new feature leverages the existing structure rather than fighting it. the codebase becomes more valuable over time, not because the code itself appreciates, but because the decision surface it provides grows richer. every module added makes every other module more useful.
the operating model compounds the same way. each new hire reads the model and orients in days instead of weeks. each advisor conversation updates specific assumptions in specific modules, making the entire system more accurate. each deal closed generates data that refines the unit economics, which refines the capital strategy, which refines the hiring timeline, which refines the integration capacity. the model is not a static document that depreciates. it is a living system that appreciates through use.
in the llm era, this compounding is turbocharged. every conversation with an ai about the model makes the model smarter. every scenario tested surfaces an edge case that gets documented. every contradiction identified gets resolved. the model becomes a flywheel for organizational learning — the more you use it, the more it knows, the more useful every subsequent use becomes.
the best codebases are not the ones that predict every requirement in advance. they are the ones that make change cheap. they have clear interfaces, minimal coupling, explicit assumptions, and well-defined extension points. they are easy to read, easy to modify, and easy to test. they are designed not for the current state of the world, but for a world that has not yet arrived.
the operating model, built properly, has the same property. it does not predict the future of the business. it creates the conditions under which the future can be navigated efficiently. it is not a map of the territory. it is a vehicle for traversing unknown territory — equipped with instruments, feedback systems, and the structural integrity to survive collisions with reality.
every company has a codebase. most are implicit, accumulated by accident, unreadable, and impossible to refactor. the operating model is the choice to write it down — clearly, modularly, falsifiably — so that it can be read by humans, reasoned over by machines, delegated to new team members, stress-tested against scenarios, and continuously improved as reality teaches you what you got wrong.
in the llm era, this choice is no longer just good discipline. it is a structural advantage. the company whose logic is written down can think faster, adapt faster, delegate faster, and learn faster than the company whose logic lives in the founder’s head. the explicit codebase is not just readable. for the first time in the history of organizations, it is executable.
the base code is the business. write it well sir.