The Founder SOP Stack: How to Document Everything So Anyone Can Run It

A standard operating procedure is a written description of how a specific task gets done, specific enough that someone who has never done it before can complete it correctly on the first attempt without asking you a single question. That last part is the test. If your SOP requires follow-up questions to execute, it is not done yet.

For expat founders running lean operations from Southeast Asia, SOPs are not optional overhead — they are the mechanism that makes delegation possible without constant supervision. You cannot hand off a task to a virtual assistant and then spend more time answering their questions than you would have spent doing the task yourself. The SOP eliminates that dynamic entirely.

This guide covers the exact framework for building a founder SOP stack that actually works — not the kind that gets written once and never looked at again, but the kind that becomes the operational backbone of your business.

For the async business architecture that SOPs plug into, read How to Build an Async Business That Runs Without You.

For the time arbitrage system these SOPs support, see the automation systems at ExpatBuildr.

Why Most SOPs Fail

The most common failure mode is writing SOPs for the future rather than for the present. A founder sits down to document a process and writes the idealized version of how it should work rather than how it actually works. The result is a document that does not match reality and gets ignored.

The second failure mode is writing SOPs at the wrong level of specificity. Too high-level and the reader has to make too many judgment calls. Too granular and the document becomes a 40-step instruction manual for sending an email.

The third failure mode is building a documentation system that nobody can find or navigate. If your SOPs live in a folder buried three levels deep in a Drive, they do not exist operationally.

The framework below addresses all three.

The Three-Level SOP Architecture

Level 1: The Business Playbook

The business playbook is a single master document that lives at the top of your Notion workspace. It answers three questions: what does this business do, how is it structured, and where does everything live?

A founder business playbook covers:

• What the business offers and who it serves
• The team structure and who owns what
• The tool stack and what each tool is used for
• The communication protocols and response time standards
• Links to all Level 2 department SOPs

The playbook is the first document a new team member reads. It should be readable in under 30 minutes and give them a complete mental model of how your operation works.

Level 2: Department SOPs

Department SOPs cover the recurring workflows for each functional area of your business. These are process-level documents — not step-by-step task instructions, but descriptions of how a workflow operates from start to finish.

A lead generation department SOP covers: how prospects are identified, how they are enriched, how outreach is sequenced, how replies are handled, how meetings are booked, and how the handoff to a sales conversation happens. It describes the flow, the ownership at each step, and the tools used.

Department SOPs are typically one to three pages. They give a team member enough context to understand their role within a workflow without providing the granular step-by-step instructions for individual tasks.

Level 3: Task Checklists

Task checklists are the operational documents your team actually works from. They are step-by-step instructions for specific recurring tasks, specific enough to execute without prior knowledge.

A good task checklist for sending a weekly newsletter looks like:

1. Open Beehiiv and click New Post
2. Copy the subject line from the Notion content calendar for this week
3. Paste the body content from the Notion draft into the editor
4. Review formatting against the style guide checklist (linked)
5. Add the header image from the assets folder (path: /newsletter/headers/[week])
6. Set send time to Tuesday 8am EST
7. Send test email to [email address] and screenshot for approval
8. Wait for approval in Slack before scheduling
9. Schedule the send
10. Update the content calendar status to Scheduled

That is a checklist someone can follow on day one without asking a single question.

How to Write an SOP That Actually Gets Used

Start with a screen recording. The fastest way to write an SOP for a task you currently do manually is to record yourself doing it with Loom while narrating each step out loud. This captures the actual process, not the idealized version. Send the recording to your VA and ask them to write the checklist from it. Then review their checklist for accuracy and completeness. This produces a better SOP in 30 minutes than most founders write from scratch in two hours.

Write in second person imperative. Every step is a direct instruction. Not “The operator should click the export button” but “Click Export.” Not “It is important to verify the email address” but “Verify the email address before sending.” The imperative voice removes ambiguity and makes checklists faster to scan.

Include screenshots for anything visual. Any step that involves navigating an interface, finding a specific field, or identifying a specific element should have a screenshot. Screenshots become outdated when software updates but outdated screenshots are still better than no screenshots. Annotate them with arrows and labels.

Define the done state. Every task checklist should end with a clear definition of what done looks like. What file exists? What status gets updated? What message gets sent? A team member should be able to confirm completion against an objective standard rather than a feeling.