Building Systems Before You Think You Need Them

There is a predictable moment in the life of an early company, usually somewhere between the twelfth and the eighteenth month, when the work that had been running smoothly on the founder memory begins to slip out of reach.

Magnific.com

Customer requests get answered late or not at all, important conversations are forgotten because no one wrote them down, decisions are made twice because the original decision was never recorded, and the founder, who had felt in control of the company a quarter earlier, begins to feel like the company is running them rather than the other way around. The transition is gradual enough that it does not feel like a crisis, but it is expensive in ways that take months to repair, and most founders who reach it wish they had set up systems earlier than they did.

This piece is about the small operational systems that prevent this transition, the timing of when to build them, and the temptation to wait until the systems are obviously necessary, which is also the moment when they become hardest to introduce.

Why systems get built late

Systems get built late because the work of building them feels unnecessary in the early months, when the company is small enough that the founder can hold everything in their head. The customer list is short enough to remember, the decisions are recent enough to recall, and the open questions are few enough to track without writing them down. In this state, building a system feels like setting up scaffolding for a building that has not yet been imagined, and most founders, reasonably, decide to defer the work until later.

The trouble is that later arrives gradually rather than suddenly, and the founder is usually too busy to notice when later has actually arrived. The customer list grows by one every week, and you only realize you have lost track of customers when you fail to follow up with someone you had promised to call back. The decision log grows by a few per month, and you only realize you have lost track of decisions when you make the same one twice and your team notices. By the time the need for systems is obvious, the company has already incurred the cost of operating without them for a while, and the introduction of systems now requires unwinding the accumulated mess as well as building the systems themselves.

The systems that earn their place early

Not every system needs to be built early, since some of them serve only larger companies, and adding them to a small company creates work without producing value. There are, however, four systems that earn their place much earlier than founders expect, and each of them takes very little effort to set up.

1. The first is a simple customer log, which is just a document or spreadsheet that lists every customer or potential customer you have spoken to, the date of the conversation, the substance of what was discussed, and any open follow ups. The system does not need to be sophisticated, and a single spreadsheet is enough at this stage, but the act of writing down every customer interaction protects you from the most common kind of operational drift, which is letting promising conversations fade because they were not recorded.

2. The second is a decision log, which is a document where you write down the meaningful decisions you make for the company, the reasoning behind each decision, and the date the decision was made. This sounds excessive at the early stage, but the founders who keep one consistently report that it saves them hours of confusion months later, because decisions that seemed obvious at the time often become unclear when you revisit them, and the original reasoning is rarely intact in your memory. A decision log of even a few entries per month is enough to keep the company aligned over time.

3. The third is a weekly review rhythm, which is a thirty to sixty minute block of time each week, usually on a Friday or Sunday, when you sit with the past week work, write down what happened, what you learned, and what the priorities are for the next week. The review does not need a template, and the document does not need to be elegant, but the rhythm of doing it consistently produces a clarity that founders cannot get from any other source, because the weekly review is the only moment in the working week when you are forced to look up from the immediate work and see the larger arc.

4. The fourth is a single document that holds your operating priorities for the quarter, which is a short statement of the two or three most important things the company is trying to learn or build over the next three months. The document does not need to be revisited every day, but having it written down means that every new opportunity, every new feature request, and every new partnership can be checked against it quickly, which is the foundation of saying no with conviction.

"Not every system needs to be built early, since some of them serve only larger companies, and adding them to a small company creates work without producing value. "

The cost of not building them

The cost of operating without these systems compounds quietly.

• Customers who were not followed up with stop responding when you eventually reach out, and you lose deals you could have closed.

• Decisions that were not recorded get made differently the second time, and the team becomes confused about what the company actually believes.

• Weekly priorities that were not written down drift, and the company spends months working on things that do not match the quarter intent.

None of these costs are dramatic on any given week, but together they slow the company in ways that take longer to recover from than the systems would have taken to build.

Founders who introduce these systems early tend to describe the introduction as taking only a few hours of work, while founders who introduce them late tend to describe it as taking weeks, since the late introduction requires reconstructing what had been lost as well as building the systems themselves.

A note on tools

It is worth saying that the tools used to hold these systems matter much less than the discipline of using them. Notion, Google Docs, Apple Notes, a paper notebook, or a single shared spreadsheet are all sufficient for the early stage, and choosing among them is a question of personal preference rather than strategy. The founders who do this well do not have impressive tooling, they have consistent habits, and the habits are what produce the result.

When to add more

The systems described above are usually sufficient until the company has more than three people, more than fifty active customers, or more than a single product line, at which point the operational load grows enough that more specialized tools become useful. Adding more before that threshold is almost always a mistake, since the additional tools require maintenance and the maintenance pulls energy from the work that actually matters at the stage you are in.

The right way to think about it is that systems are not about being impressive or thorough, they are about preserving your attention for the work that matters most, and the founders who get this right tend to feel calmer at month eighteen than founders who relied on memory and good intentions to carry them through.

A closing thought

Building systems before you think you need them is the kind of work that produces no obvious payoff for a few months and then quietly saves you from the kind of operational drift that catches most early companies. Set up the customer log this week, start the decision log next week, hold the weekly review rhythm for a month, and write down your quarterly priorities, because the small amount of work it takes now is much less than the work it would take to introduce these systems after the company has already begun to slip, and the founders who do this early tend to look back on it as one of the easier high leverage decisions of the early years.