Hey!

Chris here. Welcome to Blueprint—the newsletter to help you build a winning engineering team.

Back in August, I wrote about the 5-step framework I use to build SOPs without losing my mind.

It was the process that finally got me out of firefighting mode and released me from being the bottleneck in my own business.

But in the 5 short months since, a lot's changed.

The framework still works, and the spine is the same. But the actual mechanics of building SOPs are completely different now because the SOP builder moved into the tools themselves.

I've been using this updated approach for months, and it's collapsed the time it takes to systemize something from hours down to minutes. The friction that used to stop people from documenting their processes is basically gone.

So, I figured it was time I shared my updated framework.

Let me show you what's changed. 👇

📒 DEEP DIVE

My 5-Step SOP Framework (2026 Update)

How I build SOPs now that the tools can do the documenting.

Why SOPs Exist (A Quick Refresher)

If you've been here a while, this might sound familiar. Regardless, it bears repeating. The core idea is that—contrary to popular belief—SOPs aren't bureaucracy, red tape, or corporate nonsense.

They're actually a way to clone your decision-making process for the 80% of work that doesn't need your unique judgment.

As a founder, your work falls into 2 categories:

1. Judgment-heavy work: Setting strategy, making critical decisions, solving problems that require your specific expertise.

2. Process work: Repeatable, systematizable tasks that follow predictable patterns. Things like deployments, customer onboarding, and routine operations.

Judgment work is where you add irreplaceable value, but process work can be documented and handed off.

And that's what the August framework helped you do. The 5-step process was:

1. Always start manual

2. Record everything

3. Turn videos into SOPs

4. Transfer real ownership

5. Make SOPs living documents

And while those principles haven't changed, how we execute them certainly has.

The SOP Builder Moved Into The Tool

To help visualize this, let me walk you through what this looks like with deployments—also known as getting software live on the internet.

Deployments are tricky. There are lots of little bits and pieces that have to be handled just right, or the whole thing breaks.

For a long time, I would just do the work myself. Step 1. Step 2. Step 3. Hit a curveball. Debug it. Keep going. Hit another curveball. Fix that too.

Then I started using Claude, and I started to do the work through the tool. I'd say, "Go SSH into this server, pull down the software, and deploy it this way."

When it hit something it didn't know what to do with, it would pause and ask: "Chris, what do I do in this circumstance?"

I'd answer, "Then we keep going."

This was more efficient than doing it all myself. But the real unlock is that, after doing 1 deployment, I can now tell the tool, "Go write the SOP for everything we just did."

It looks at our entire conversation history and builds a Skill—basically SOPs with first principles and judgment rules built in—that includes the logic behind the decisions.

So the next time I need to deploy, I only need 1 command: "Go deploy the software."

It knows exactly what to do.

How I Build SOPs Today

Step 1: Start Manual

Never systematize something before you validate that the manual process works.

You have to do it manually first to make sure the workflow is actually good, and the outcome is what you want.

Only then should you move to systemization.

Step 2: Run The Workflow Inside The Tool

Instead of recording with Loom first, the tool-run becomes your recording.

You're doing the actual work, but you're doing it through the tool so it can learn the process in real-time.

Step 3: Let It Hit Edge Cases And Teach It Judgment

During the run, the tool will pause at things it doesn't know how to handle.

Your job when this happens is to tell it what to do AND explain the principle behind your decision.

This is critical because it's the principles that make an SOP durable. Without them, you're just documenting steps. With them, you're teaching judgment.

Step 4: Generate The SOP From The Full Run

After you've done the work once, you give 1 instruction:

"Look at our entire conversation history and write the SOP for everything we just did. Include principles and edge cases so next time you don't have to ask me those questions."

This way, SOP creation becomes the final step after the work is complete, not a separate task you do later when you have "time."

Step 5: Ownership And Iteration

It's still true that SOPs die without real ownership.

The difference now is that the iteration loop is much tighter. Skills get exercised frequently, so you find out what breaks faster.

But the requirement stays the same: updates and edge cases must be documented in the Skill. No exceptions.

Where This Works

This approach can be applied anywhere you have a repeatable workflow that keeps pulling you back in with questions:

• Releases

• Incident response

• Customer escalations

• Onboarding sequences

• Reporting

• QA checks

• Contract renewals

But remember: You're not trying to automate yourself out of existence. The goal is to remove yourself from 80% of process work so you can focus on the 20% that genuinely needs your judgment.

BEFORE YOU GO…

The thing that always killed SOP creation was the friction.

You'd do the work. Then you'd have to stop, context switch, and spend an hour writing documentation.

And because you always had something urgent pulling you in another direction, the documentation rarely got done.

Now, that friction is gone.

So start building that library today. Pick the simplest workflow you do repeatedly and run it once. Just once. That's all it takes.

Because the road to the business that can run without you starts with one Skill today.

Talk soon,

Chris.