Hey!

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

Software companies are really good at building tools for their customers.

They're remarkably bad at building tools for themselves.

There's an old saying: the cobbler's children have no shoes. And if you run a software company, there's a decent chance it describes you perfectly.

New engineers may waste days on a dev setup nobody automated, while customer data is scattered across spreadsheets, and cloud costs are ballooning because nobody's watching.

None of these are 5-alarm fires—and that's exactly why they persist.

But believe it or not, it's probably the easiest leverage in your entire organization.

Let me explain why (and how you can take advantage of it). 👇️ 

📒 DEEP DIVE

The Cobbler’s Children Tax

Why the internal tooling opportunities you're ignoring are costing you more than you think—and how to fix it fast. 

Founders often assume building internal tools is a big, expensive project that you undertake only after you've solved everything else.

But in practice, the investment is almost always smaller than people think, and the return comes faster than almost anything else you can spend engineering time on.

Here's the playbook.

Find Your 1 Painful Thing

We like to start with a simple web app for 1 use case. Here are a few examples I run into constantly when we go into organizations:

Dev environment setup is a mess: A new engineer shows up, and it takes them 2 days to get a working local environment—database clones, a dozen credentials, configurations nobody wrote down.

No real customer database: A lot of companies have a CRM for leads and pipeline, but nothing that tracks what's actually happening with long-term customers.

Cloud costs nobody's watching: Software companies accumulate cloud resources the way people accumulate junk in a garage.

Any one of those is a reasonable place to build your first internal tool around.

The Gateway Effect

Once employees actually use an internal tool—the moment something annoying and manual becomes automatic—it flips a switch.

"Wait...we can write software for ourselves?"

It sounds obvious from the outside. But a lot of people inside software companies have never genuinely considered it. They've been so focused on the product they're building for customers that building something for themselves didn't register as an option.

Once that switch flips, the compounding begins almost immediately.

People start walking up and saying things like: "Okay, if you can do that, we've always needed this other thing." And you start building out this internal operating system for your company.

And it runs deeper than productivity. Annoyed people are not productive people. When someone is grinding through the same frustrating manual process for the 100th time, they're not solving interesting problems.

That friction has a material cost that never shows up in a budget line.

The Pushback

There are a couple of objections that come up almost every time we have this conversation with customers at Surton:

1. Maintenance

It's fair to ask if you'll be able to maintain what you build. The honest answer depends on whether engineering is in your DNA as a company.

If you have an internal team that can own this, build it in-house. If you don't, bring a partner in to build the foundation and hand it off cleanly.

2. Infrastructure Anxiety

There's a corner of the internet that will tell you all the different tools you need to buy before you can ship even a simple internal web app. Ignore most of it.

You don't need a sophisticated setup. You can run this stuff on a single server in the cloud.

In fact, while I don't recommend it, a lot of companies are currently running their internal operations out of Excel. It's not particularly good at backups, compliance, or automation, but it tells you where the bar is.

Playbooks Aren't the Finish Line

Once you've handled those objections and started building, most founders realize something bigger is in play.

There's a pattern that plays out as companies scale. Founders build playbooks to systematize operations—step-by-step processes that let them stop doing every job themselves.

That's the right move. But a lot of people stop there, and that's a mistake. If a human can follow steps 1-5, a computer can, too.

Once you've documented how something works, you've done most of the work required to automate it. You automate the drudgery and let your people focus on the parts that actually require human judgment.

The internal tool you build today becomes the automation that eliminates a hiring decision tomorrow.

BEFORE YOU GO…

To get started with this, pick a single wedge that pays back fast.

Timebox your first version. This should take hours or days, not quarters. The goal is to get something simple in front of people quickly and watch what happens from there.

Then make the call: if you have engineering in your DNA and a team that can maintain it, build the muscle in-house. If you don't, bring someone in to start it and hand it off cleanly.

Either way, the first step is the same. Find the thing that's quietly bleeding time and money, and build something simple to fix it.

Talk soon,

Chris.