Build versus buy for small teams

Most teams know this matters. Fewer have decided who owns it. Most advice about build versus buy assumes a team that does not exist at your size. Here is the version that does not.

The projects that go badly are rarely the ones with the hardest technical problems. If it only works because one person remembers to do something, it does not work yet.

What to keep

Build what makes you different, buy the rest. In practice this is a scheduling problem more than a technical one. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. In practice this is a scheduling problem more than a technical one.

Where to start

Count ongoing maintenance in the build column. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

What this looks like day to day

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about build versus buy before you move on:

• Someone can say what the current setup is without going to look
• Count ongoing maintenance in the build column — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.