The 3 SOPs Every Solo Founder Needs Written Before Hiring Anyone
A common failure mode of the first hire: the founder hires someone to “take work off my plate,” then realises in week two that the work cannot actually leave the plate because it lives in the founder’s head and not on paper. The hire keeps asking questions because there is no document to read, the founder keeps repeating the same explanations, and three months in, both sides are exhausted and the founder is doing all of the original work AND managing a person.
The fix is dull and unsexy: write the SOPs before you hire. Not a fancy operations manual; three specific workflows that cover 60 to 80 percent of what a first hire will actually do. Most solo founders skip this because writing SOPs feels like overhead when you are already overworked. But the writing happens whether you choose it or not. Either you write the SOPs now, in 8 to 12 focused hours over a week, or you write them in fragments over the new hire’s first 90 days, under deadline pressure, with worse output. The total writing time is the same; the cost is dramatically different.
This piece walks through the three SOPs that matter most for a service business, agency, consultancy, or content-driven solo founder. If you write only these three before the hire walks in, you have covered the majority of the friction. The principle generalises: the test for any SOP is whether a competent person could execute the workflow without asking you any question. If the answer is no, the SOP is not done yet.
What an SOP actually is (and is not)
An SOP is a standard operating procedure. It is the document that tells someone how to do a specific repeatable thing in this specific business. It is NOT documentation, training material, or strategy. It is the operating instructions for a specific workflow.
Three properties separate a real SOP from notes:
It is step-by-step. Not “we handle client onboarding well.” Specifically: “When a client signs the contract, do the following 7 actions in this order.” Each action is concrete and the order is fixed.
It is decision-free where possible. Where decisions are required, the SOP specifies the rule. “If the project value is over Rs.2 lakh, escalate to founder before quoting; under Rs.2 lakh, follow the standard quote template.” The reader does not have to make judgment calls the founder has not pre-authorised.
It is testable. Someone who has never done this work before should be able to execute the SOP and produce the correct output. If the SOP works for that person, it works for any hire. If it does not, the SOP is missing something.
The minimum viable SOP format is three sections:
- What this workflow is for (one sentence)
- Step by step (numbered, concrete, with screenshots or links where useful)
- Decision rules (when X, do Y)
A good SOP is two to four pages. Long SOPs do not get read. If your SOP is fifteen pages, it is two workflows in one document, and you should split it.
SOP 1: The client communication workflow
This is the single highest-leverage SOP because client communication accounts for 30 to 50 percent of a solo founder’s total weekly hours. Every minute spent in client back-and-forth is a minute not spent on revenue-generating delivery. If a first hire can take over the front-line of client communication on day 30, the math of the first hire works.
The communication SOP should cover:
Response time targets by channel and urgency. Email replies within Y hours during working hours, WhatsApp within Z hours, urgent flags within W hours. Be explicit about what “urgent” means; without a written definition, every message is urgent.
Template responses for the 8 to 12 most common message types. New project inquiry, project status update, client question about deliverable, client request for scope change, payment follow-up, schedule reschedule request, holiday or unavailability notification, project completion handoff. These templates do not have to be polished; they have to exist as a starting point that the hire can adapt rather than write from scratch each time.
The escalation rules. What does the hire handle solo, what gets a heads-up to the founder, what gets immediately escalated? Concrete examples: “Scope changes under 4 hours of additional work: handle, log, send confirmation. Scope changes over 4 hours: send to founder with proposed quote.” “Client complaints: immediately escalate, do not respond before founder has been informed.”
The logging discipline. Where does each client conversation get logged so that anyone on the team can find the latest status? Notion CRM page, ClickUp client folder, dedicated Slack channel per client, whatever the chosen tool is. The rule is one logging location per client, and every interaction goes there.
Tone and brand voice. Two paragraphs maximum. “We respond warm but direct, no fluff, no excessive apology, no overpromising. We use the client’s first name. We avoid ‘just,’ ‘sorry to bother,’ and ‘no worries.’ We sign every email with name and role.” Generic, but explicit so the hire knows the bar.
The shortest viable client communication SOP is about three pages. The version that contains the 8 to 12 message templates is closer to six. Both versions take roughly 4 hours to write if you have done the work for a while; the writing is fast because you already know the answers, you just have not written them down. The hire who reads this SOP on day 1 can handle low-stakes client communication on day 4, fewer reviews from the founder, and is fully owning the front line by day 30.
SOP 2: The work intake and scoping workflow
The second most leveraged SOP is how new work gets into the business. The classic mistake of a first hire is letting them take new inquiries without an intake structure, which produces three failure modes: underquoting (the hire is too cautious and prices below your rates), overscoping (the hire commits to work the business cannot deliver in the timeline), and scope creep (no formal scope document, so the client expands what is “included” later).
The intake SOP should cover:
The qualification questions. What do we ask every new inquiry to figure out whether this is a fit? Five to seven questions, written out, asked in the same order every time. “What is the outcome you are trying to achieve? What is the timeline? What is the budget range? Have you worked with someone in this space before? Who else is involved in the decision? When do you need to make a decision by? What does success look like in three months?” These questions both qualify the lead and produce the brief.
The decision tree for who responds. Some inquiries the hire handles end-to-end. Some get passed to the founder for the discovery call. Some get politely declined. The SOP specifies which inquiries fall into each bucket. “Inquiries with budget under Rs.50,000: hire handles, sends standard quote template. Inquiries Rs.50,000 to Rs.5 lakh: hire qualifies, schedules discovery call with founder. Inquiries over Rs.5 lakh: hire flags immediately, founder takes from there. Inquiries from outside our service categories: polite decline with referrals if possible.”
The scoping template. When the work is in our zone, how do we scope it? A two-page document with sections for objective, scope (inclusions and exclusions explicitly), timeline (milestones and final delivery), price (fixed or hourly with cap), payment terms, change-request handling, and termination conditions. Reused for every project. The hire fills it from the qualification call notes. The founder reviews before it goes to the client until trust is calibrated, then the hire owns it after that.
The decline template. When work is outside scope or not a fit, what do we say? Polite, brief, with a referral if possible. Not “we are too busy,” not “we do not do that.” Something like: “Thanks for reaching out. The work you describe is not in our core focus area. I would recommend reaching out to [referral] who specialises in this. Best of luck with the project.”
The pricing rules. What is the minimum price for each service category? What are the discount rules? What gets discounted (long-term retainers) and what does not (small one-off projects)? The hire should never have to wonder whether a number is acceptable.
The work intake SOP is the one that saves the most money in the first year. Every misquoted deal costs the actual quote difference; every misscoped deal costs the rework. A clear intake SOP prevents both at the source.
SOP 3: The handoff and quality workflow
The third SOP covers the workflow that turns “in-progress work” into “delivered work.” This is the SOP that protects the brand and the client relationship, because the moment work leaves the business is the moment quality matters most.
The handoff SOP should cover:
The definition of done for each deliverable type. What does “complete” mean for a report, a design, a code commit, a content piece, an audit? Concrete checklists. “A report is done when: all sections completed, executive summary at top, references and data sources listed, no spelling errors, file named in the standard convention, exported to PDF, uploaded to client folder, link shared with client via the standard handoff template.”
The internal review step. Before any deliverable goes to the client, what is the internal check? For the first hire, this is the founder reviewing. As trust builds, it becomes a self-review against the checklist. Concrete steps: “Send to founder via the review channel with the file link and the deliverable name. Founder reviews within 24 hours. Make any requested changes. Re-share for sign-off. Then proceed to client send.”
The client send template. A consistent format for handing work to the client. Email with deliverable link, summary of what is delivered, what to look for, the response or feedback expected, the next steps if any. Not freeform every time.
The handoff log. Every deliverable sent to the client gets a row in a log (Notion database, ClickUp custom field, spreadsheet). What was delivered, to whom, on what date, against what milestone, with what payment status. This log is the source of truth for invoicing, for project status, and for any future dispute about what was delivered when.
The feedback intake. What happens when the client comes back with feedback? Captured in the standard format, prioritised within 24 hours, response committed by the next working day with a clear action and timeline. Not ad hoc.
The completion sign-off. When a project is done, the client receives a structured sign-off email confirming completion, any remaining open items, payment status, and the warranty period (if you offer one). The sign-off triggers the close-out steps: archive the project folder, update the CRM, trigger the final invoice if not already sent, log lessons learned.
The handoff SOP is the one that matters most for retention and referrals. Clients who receive consistent, structured handoff feel taken care of, refer more, and accept higher prices on the next engagement. Clients who receive sloppy handoff lose confidence in the team’s professionalism regardless of the actual quality of the work.
How to write your first SOP if you have never written one
The biggest psychological block is feeling like the SOP needs to be “good enough” before you write it. It does not. The first version of an SOP is a transcript of how you currently do the work, written down in the order you do it. The second version (which you write in month two of using the SOP) cleans up the gaps you discovered. The third version is genuinely good.
A simple method:
Do the workflow once and narrate it. Open the SOP doc. Do the work. Every time you take an action, write down what you did. Every time you make a decision, write down the rule you used to decide. The output is messy. Save it.
Re-read it as if you were a stranger. Mark every place where a stranger would not know what you mean. “Send the standard email,” what is the standard email? “Update the tracker,” where is the tracker? Fill in those gaps.
Have the new hire follow it and flag any place they had a question. This is the best test. If they ask “where do I find X” or “when do I do Y,” your SOP is missing that. Add it. Within 30 days, the SOP has been stress-tested enough that it works for any subsequent hire.
The total writing time for all three SOPs, at the minimum viable depth, is roughly 12 to 16 hours spread over a week. This is real time, and you should expect to feel like you are not doing “real work” during it. The payoff is that the first hire’s onboarding is 30 days instead of 90, and the second hire’s onboarding is 14 days because the SOPs already exist.
When to NOT write an SOP
Not every workflow needs an SOP. Three filters for which workflows to skip:
Workflows you do less than once a month. The SOP cost (4 to 6 hours to write) is higher than the operational savings. Write it later when frequency increases.
Workflows that genuinely require founder judgment every time. Pricing decisions over a certain threshold, hiring decisions, strategic direction, public-facing brand messaging. Do not pretend these can be SOP-ed; document the criteria you use but keep the decisions with you until you have a partner-level second person.
Workflows that are about to change. If you know the workflow will be different in three months because of a tool migration, a client onboarding change, or a strategic pivot, the SOP becomes obsolete before it gets used. Write notes; defer the SOP until the workflow stabilises.
The point of the three SOPs is leverage, not completeness. You are not building an operations manual; you are building the smallest set of documents that lets a competent person operate the front-line of the business without you for 60 to 80 percent of the work. The remaining 20 to 40 percent stays with you for now, by design.
Once the SOPs exist, the rest of the first-hire framework follows. The decision of when to hire is in when to make your first hire as a solo founder. The contractor-vs-employee question is in contractor vs first employee in India. The tooling that supports the SOPs at one to three users is in the 1-to-3 person tech stack that scales without rebuild. The first 90 days with the hire are in the first hire 30/60/90 onboarding playbook.
