Revenue operations
RevOps for founders. What to build yourself, and when to stop.
The short answer. RevOps before you can afford an ops team.
RevOps for founders is not a smaller version of a RevOps department. It is a different problem entirely: what can one person, with no ops hire and no budget for one, realistically build and maintain themselves. The answer is narrower than most founders expect, and that is good news. You need one CRM that the people touching a deal actually use, one shared definition of what each pipeline stage means, and one number you look at on the same day every week. That is the whole starting kit.
Most of what gets written about RevOps assumes a company that already has separate marketing, sales and customer success teams disagreeing with each other, and a budget to fix it. That is a real and useful topic, and we cover it elsewhere: why RevOps matters makes the commercial case for it, and how to build a RevOps strategy sets out the fuller model once those teams exist. This piece is different on purpose: it is the practical playbook for the founder who is the marketing, sales and customer success function all at once, with no ops hire in sight, who needs to know what to actually do this week rather than what the discipline looks like at scale.
The honest answer, for a founder asking what RevOps actually means for them right now, is that at the earliest stage it is less a system than a habit. It is the discipline of logging a deal the same way every time, in one place, rather than trusting your memory or a notes app. Founders who build that habit early save themselves a genuinely painful CRM clean-up later. Founders who skip it usually end up paying someone, eventually, to reconstruct eighteen months of pipeline history from old emails.
How it works in practice. Three stages, three different jobs.
What RevOps actually asks of you changes as the business grows, and treating every stage the same way is where most of the wasted effort comes from. Roughly, there are three stages worth thinking about separately.
Solo or pre-revenue. At this stage RevOps is entirely personal discipline. You do not need a CRM platform with automation and custom fields. You need one place, a free-tier CRM or even a well-structured spreadsheet, where every conversation with a prospect gets logged the same way: who they are, what stage they are at, what the next action is and by when. The point is not the tool. The point is that in six months, when you have had forty conversations and cannot remember which three are actually warm, the record exists and you trust it.
First sales hire. This is where RevOps for founders actually starts to matter, because you are no longer the only person whose memory the business runs on. The moment a second person is logging deals, an unspoken personal system stops working, because two people will interpret "qualified" or "in progress" differently without ever noticing they disagree. Before that hire starts, write down, in one page, what each pipeline stage means and what has to be true for a deal to move between them. This is the single most useful document a founder writes in the first year of hiring, and it takes an afternoon.
Five to ten people. By this point you likely have someone in sales, someone half in marketing, and you are starting to see renewals or repeat business that needs its own attention. This is usually where founders feel RevOps pressure most acutely, because informal coordination, a quick Slack message, a hallway conversation, stops covering the gaps. The instinct is often to buy a bigger platform. The better first move is almost always to formalise the weekly number review you should already be doing, and to write down the handoff between whoever is generating leads and whoever is closing them, so it does not depend on the two of them sitting near each other.
Salesforce's 2023 State of Sales research found that reps typically spend less than 30% of their working week on activities that actually move a deal forward, with the rest consumed by admin, internal coordination and CRM upkeep. That figure is aimed at larger sales organisations, but the underlying warning applies just as much at five people: every hour your first sales hire spends fighting an over-built CRM instead of talking to buyers is an hour you paid for and did not get. A minimum viable set-up is not a compromise. It is the version that actually protects selling time.
What good looks like. The minimum viable RevOps set-up.
Strip away the frameworks and the tooling debates, and a working RevOps set-up for a founder-led business rests on three things, in this order of priority.
One CRM, used properly. Not the most feature-rich one. The one everyone touching a deal will actually open. A CRM with three unused fields and one habitual user beats a fully configured platform that only the founder logs into, every time. If you have not picked a tool yet, our guide to choosing a CRM for startups covers that decision in more depth than is useful to repeat here.
One shared pipeline definition. Every stage in the pipeline needs a plain-language test for what has to be true before a deal sits there, written down somewhere more permanent than a founder's head. "Discovery call booked" is a stage. "Interested" is not, because two people will disagree about what counts as interested within a month of using it.
One number, reviewed weekly. Usually open pipeline value and a realistic view of what closes this month, looked at on the same day every week rather than whenever a founder happens to remember. The specific number matters less than the habit of looking at it on a fixed schedule. A founder who reviews pipeline every Monday morning, even briefly, catches a stalling deal or a forecast that has drifted weeks before a founder who only looks when something already feels wrong.
A judgement call worth naming here, because it comes up in almost every early-stage conversation I have: founders often ask whether they should build the "proper" reporting dashboard now, while there is still time, or wait. My answer is nearly always to wait. A dashboard built on a pipeline definition nobody has agreed yet just displays the disagreement more clearly, in colour. Fix the definition first. The dashboard is a half-day of work once the underlying data means the same thing to everyone looking at it; it is wasted work before that.
A worked example. How this might play out over a year.
This is illustrative, not a specific client engagement, but it reflects the pattern I see most often. A founder selling a B2B service starts month one with a spreadsheet: name, company, stage, next step. Nothing else. By month four, with a handful of live deals and a first sales hire starting, the founder spends an afternoon writing a one-page pipeline definition, five stages, plain language, before the new hire's first day, and moves the tracking into a free-tier CRM both of them log into.
By month eight, with the team at four people and a second sales hire in place, the Monday pipeline review becomes a fifteen-minute standing meeting rather than a founder checking a spreadsheet alone. Nothing about the underlying system has changed, the CRM is the same one from month four, but the habit is now shared rather than personal. By month twelve, with renewal conversations starting to matter and the team past six people, the founder brings in a few days of outside RevOps support to configure proper reporting and tighten the marketing-to-sales handoff, because that is now worth paying for. The CRM itself barely changes across the whole year. What changes is who is accountable for keeping it honest.
The founders who struggle are usually the ones who invert this order: an expensive platform bought in month one, configured for a team that does not exist yet, sitting mostly unused while the actual coordination happens in WhatsApp and memory. The tool was never the bottleneck. The habit was.
Pitfalls to avoid. Where founders get this wrong.
Over-tooling before there is a team to use it. A platform with automation, custom objects and integrations is genuinely useful once several people rely on it daily. Bought solo, it is an expensive way to track forty contacts, and the configuration time is time not spent selling. Buy the bigger tool when the second or third person joins, not before.
Building a system with no time to maintain it. A founder who sets up a beautiful pipeline structure in a weekend and never opens it again has built nothing. RevOps for founders lives or dies on the weekly habit, not the initial set-up. If you genuinely cannot commit fifteen minutes a week to reviewing the pipeline, build a simpler system you will actually keep, rather than an ambitious one you will abandon by month two.
Conflating RevOps with buying software. This is the most common mistake, and the most expensive one to unwind. A new CRM does not create a shared definition of "qualified" or a weekly reporting habit on its own. Those come from a conversation and a written page, not a subscription. Founders who buy first and define later usually end up, eighteen months on, with a new tool encoding the exact same disagreements the old one had, just with a nicer interface.
Waiting too long once the team outgrows informal coordination. The flip side of over-tooling early is under-investing once the signals are actually there: two people describing the same deal differently, a forecast that surprises you two quarters running, a handoff that depends entirely on two specific people remembering to talk to each other. Past roughly five to ten people, that is usually the point to bring in fractional or consulting support rather than continuing to patch it yourself. Our overview of revenue operations covers what a fuller function looks like once you are ready for it, and RevOps consulting sets out what a focused engagement to build that system actually involves.
None of this requires the discipline that a dedicated RevOps hire eventually brings. It requires roughly a day of set-up, a page of written definitions, and fifteen minutes a week, kept up consistently, for longer than feels necessary. That is the whole of RevOps for founders until the business genuinely outgrows it. If you are further along and building sales capacity rather than the underlying system, our guide to founder led growth covers the selling side of this same early stage in more depth.
Common questions.
Do I need a RevOps hire before my first sales person?
No. Before your first sales hire, RevOps is just you being disciplined about your own CRM: one pipeline, logged consistently, reviewed weekly. A dedicated hire only earns its keep once there is enough deal volume and enough people touching the pipeline that informal coordination between them starts to break down, usually somewhere past the first sales hire, not before it.
What is the minimum viable RevOps set-up for a founder?
Three things: one CRM that everyone touching a deal actually uses, one shared definition of what each pipeline stage means, and one number reviewed at the same time every week, usually open pipeline value and what is genuinely likely to close. Nothing else is required to start. Dashboards, automation and a documented playbook come later, once the basics are actually holding.
Can I run RevOps on a free or cheap CRM?
Yes, and for most founders it is the right call. A free or entry-tier CRM used consistently by everyone on the deal beats an expensive platform that only the founder logs into properly. Our guide to choosing a CRM for startups covers the selection criteria in more depth if you have not picked one yet.
How do I know when to stop doing RevOps myself and bring in help?
The signal is not headcount, it is disagreement. Once you catch two people on the team describing the same deal stage differently, or a forecast that surprises you two quarters running, informal coordination has stopped working and it is time for a fractional RevOps consultant or a dedicated hire, whichever the budget and the workload actually justify.
What is the single biggest RevOps mistake founders make?
Buying software and calling it done. A new CRM or a reporting tool does not create a shared pipeline definition or a weekly reporting habit by itself. The tool only pays off once the founder has actually agreed, in plain language, what each stage means and who is responsible for updating it. Skipping that step is the most common reason a new system looks the same as the old mess within a quarter.
Is RevOps for founders the same as a RevOps strategy?
Related but not the same question. A RevOps strategy is the fuller model for aligning marketing, sales and customer success once a business has separate teams for each. RevOps for founders is the earlier, narrower problem: what one person with no dedicated ops hire can realistically build and maintain themselves, before that fuller model is even relevant.
Outgrown what you can hold together alone?
Get in touch and we'll look at your current pipeline, work out what a founder can still handle solo, and where a few days of RevOps support would actually earn its cost.
Let's talk ↑