Setting up operations in an early-stage startup is not about building the machine you will eventually need. It is about installing the smallest set of working habits so the company stops losing money, people, and decisions to sheer disorganisation while it is still figuring out whether the product works.

If you are the first operator — a founder wearing the operations hat, or an early COO — your real job is sequencing. Build the wrong things too early and you bury a 12-person team in process it does not need. Build nothing and you hit 25 people with no idea where the cash goes, who owns what, or why the same fire keeps restarting.

This guide covers that order: what to set up in the first 90 days, what to leave manual on purpose, and the money, hiring, and decision habits that matter before you have any of the "real" systems. It is the setup companion to what to do once things are working — covered in the startup scaling playbook — and stays deliberately on the earlier problem: getting a company to run at all. For the tech-startup version of this journey specifically, seed to Series B, see tech startup operations.

What operations actually means at 10 people

At an early-stage company, operations is not a department. It is the answer to four boring questions, asked every week: Do we know where the money is? Does work get to the right person? Are we making decisions or re-litigating them? Can a new hire become useful in a week rather than a month?

Strong early operations look almost invisible. Cash position is known to the day, not guessed at month-end. Every recurring task has a named owner, even if that owner is a founder. New hires ship something small in their first few days. Decisions get made in the room and stay made. Weak early operations look busy. Five tools where two would do, three half-configured. Nobody can state the runway without opening four tabs. The same question — who approves this? — gets re-answered every time. People are working hard and the company still feels like it is skidding. The trap is to fix the appearance by buying software: a dashboard does not create clarity, a habit does.

Sequence the build: what comes first

The most useful thing you can do in your first 90 days is refuse to build everything at once. Operations should come online in the order the company will actually feel the pain.

The exact headcounts vary; the direction is what matters. Money and a single place to track work come before management structure. A weekly rhythm comes before dashboards. You document a process once it has run enough times to be worth writing down. Building a departmental org chart at 12 people just creates overhead a team this size will route around.

Money first: know the cash to the day

Cash is the one operational failure that ends the company, so you set it up first and never let it slip. This is not the same as "do the accounting." It is a running, forward-looking view of what you have and how long it lasts.

Strong: you can state, without checking, your current cash, monthly burn, and runway in months, and answer "what does this hire do to runway?" in the meeting. Weak: you know roughly what is in the account and find out you are tight when payroll looms.

Set up three things: real bookkeeping from day one (QuickBooks or Xero, reconciled monthly); a burn-and-runway forecast you update at least monthly; and a few spending controls — who can spend what without asking, one company card instead of personal cards, and a rule that recurring costs above a threshold get a second set of eyes. That threshold might be $500 at seed and $5,000 later; the number matters less than the fact there is one. This discipline is the foundation the harder cost optimization strategy work builds on once you have more to optimise.

Make work legible: one source of truth

The second failure is invisible work — tasks that live only in someone's head or a Slack thread that scrolls away. The fix is one place, agreed by everyone, where work lives.

For a team under 20, resist an elaborate project-management setup. A single shared board — Notion, Linear, Trello, whatever the team actually opens — with clear ownership beats a beautifully architected system nobody updates. The test is not "does the tool have the feature"; it is "does this board tell me the true state of work?" If people keep real status in their heads and the board is theatre, no tool fixes that.

The habit that makes a board work is that every item has one owner — not a team, not "we," one name. Shared ownership at this stage means no ownership. As you approach 30 people and hand-offs multiply, formalise this with a simple RACI-style owner map so cross-team work does not fall through the gaps between people who each assumed someone else had it.

Hire deliberately, onboard fast

Early hiring is operations, because a bad hire in a 10-person company is not a 10% problem — it is a culture-defining event. Set up a process that is light but not sloppy: a written role scope before you post, a consistent short interview loop, and a decision made by the people who will work with the hire, not whoever happened to like them.

Onboarding is where startups quietly waste money. A new hire who takes six weeks to become useful on a 12-month runway is expensive. Strong onboarding gets someone shipping in their first days — tools working on day one, an owner for their first week, a small real task waiting. Weak onboarding hands them a laptop and a wiki and hopes. You do not need HR software for this; you need a checklist and an owner. The software comes later, when the manual version strains.

Install a weekly operating rhythm

Companies drift not because people are lazy but because there is no regular moment where reality gets checked against intent. A weekly operating rhythm is the cheapest, highest-leverage system a first operator can install, and it needs no tooling.

The minimum is one short weekly meeting where the team looks at the same handful of numbers, names what is blocked, and confirms the two or three things that matter this week. Keep it tight and honest — the value is entirely in whether real problems surface. This rhythm is what your wider operator cadence hangs off later, and it is far easier to scale a rhythm that already exists than to add one to a company that has never had it.

Alongside the meeting, adopt one rule: when a decision is made, it gets written down — who decided, what, and by when. A single running decision log, even a shared doc, stops the most exhausting early-stage failure, which is re-deciding the same thing every fortnight because nobody remembers the last conclusion.

Add tools and automation last, not first

Tooling is where first operators over-build, because buying software feels like progress. Pick the smallest stack that covers the core jobs — one communication tool, one accounting tool, one work-tracking tool, one payroll/HR-lite tool — and refuse to add more until something genuinely breaks. Coverage matters, completeness does not. Every extra tool is another place data goes stale. How these pieces fit together as you grow belongs to a proper tech stack blueprint; at setup, the discipline is subtraction.

Automation follows the same logic. You cannot reliably automate a process you do not yet understand, and at ten people most processes have run too few times to encode. Do the thing manually, watch where it breaks, write it down as a simple SOP once it repeats, then automate only the steps that are both frequent and stable. This is the idea behind lean and PDCA (plan-do-check-act): improve a process by observing it, not guessing at it. When repeatable work is clearly slowing the team, a structured process optimization approach earns its keep — but only after you have run the process by hand.

Measure only what changes a decision

Early-stage companies either measure nothing or measure everything, and both are useless. Track a metric only if a bad reading would change what you do next week. For most early startups that is a short list — runway, burn, a growth or usage number that shows whether the product is working, and a rough sense of whether customers stick. Vanity metrics like page views feel good and steer nothing. As the company matures, a fuller view of operational success metrics is worth the effort; at setup, keep the list short enough that everyone can hold it in their head.

Key takeaways

• Early-stage operations is sequencing, not scale: install the smallest set of working habits, in the order the company will feel the pain.
• Set up cash visibility first — current cash, burn, and runway known to the day — because it is the only operational failure that ends the company.
• Give work one home and every task one named owner; a board nobody trusts is worse than a whiteboard everyone does.
• Hire deliberately and onboard fast, so a new hire is an asset within a week rather than an expensive bet on a short runway.
• Install a weekly operating rhythm and a decision log before buying dashboards, and add tools and automation only once the manual version genuinely strains.

Frequently asked questions

When should an early-stage startup set up formal operations? Sooner than most founders think for money and work-tracking, later than most think for structure. Cash visibility and a single source of truth for work should exist from your first few hires. Departments, formal OKRs, and HR software can wait until the pain of not having them is real — usually well past 20 people. Building structure before you feel its absence just creates overhead a small team routes around. What is the very first operational system to build? A running view of cash — current balance, monthly burn, and runway in months — backed by real bookkeeping from day one. Every other operational problem is survivable and fixable; running out of money without warning is not. Get this to where you can answer "what does this do to runway?" in any meeting, then move to the next system. How is setting up operations different from scaling them? Setup is getting a company to run at all with the fewest moving parts; scaling is keeping quality and speed as headcount and complexity grow. At setup you deliberately leave things manual and undocumented until they prove they need structure. Scaling reverses that — you invest in process, layers, and automation precisely because the manual version has become the bottleneck. Do I need a COO to set up startup operations? No. In most early-stage startups the first operator is a founder, an early generalist, or a fractional operator, not a full-time COO. The BLS median wage for chief executives is $206,420 (May 2024), and a company on a short runway rarely needs a hire at that level to install a cash forecast and a weekly meeting. Bring in a dedicated operations leader when the load genuinely exceeds what a founder can carry alongside everything else. Should I automate repetitive tasks early to save time? Usually not. You cannot reliably automate a process you have not run enough to understand, and most early-stage workflows are still changing. Do the task manually, watch where it breaks, document it as a simple SOP once it repeats, and automate only the steps that are both frequent and stable. Premature automation locks in a workflow you were about to change.