When Not to Do It Yourself – InApps 2022

New Relic sponsored this post.

I was struck recently by two competing views among decision-makers working with business software. Some felt it was always better to build your own tools, while others prefer to buy or license any software possible except when absolutely no option exists besides making it themselves. In this piece, I wanted to talk about the right and the wrong times to build your own solution.

We all know the value of doing things yourself. You get something better, and cheaper, than if you’d gone out and bought something on your own. Clearly. That’s the advantage of DIY, right?

Except that’s not true at all.

I love to cook. I cook all the time, and I enjoy trading recipes and practicing my skills. And yet, I doubt I’ve ever made a meal as good as I’ve had at Le Pigeon, a delicious French bistro near my neighborhood in Portland. Furthermore, all my DIY electronics projects over the years have probably cost me 10x what I’d spend on the same devices from a store. Doing it myself, it seems, is a way to make things that cost more and are often demonstrably worse.

It makes sense: I don’t cook full time and my electronics components are bought one at a time, instead of by the freightcar. I’m not qualified to make something better or cheaper. And yet, I persist.

So Why Do We Do It?

Sometimes we build things ourselves out of an odd compulsion for control. There’s just something wrong with the things I can buy, therefore, I need to make my own.

It’s not much, but it’s home.

But there are good reasons to build things ourselves! And the primary reason to build things ourselves is that we get better at building.

DIY Has Some Big Benefits

When I participate in a hackathon, I know I’m not making the best software I could, but I’m gaining experience in:

• Working in a new team.
• Shipping software.
• Writing components that I’m less comfortable with (hel-lo load balancers).
• Presenting my work in front of a crowd.

I can get none of these skills paying for a software license.

Further, and this a critical one:

• By making it myself, I know what to look out for when I buy it.

I like to make pottery (look, I have a lot of hobbies, don’t judge me) and while my cups and plates aren’t the best, I do know what it takes to make something on a potter’s wheel. When I look at a handmade piece of pottery, I can readily see the skill that went into it.

Surely Some of This Has Something to Do with Software

While all my examples have been about crafts, the same rules apply to software. Inhouse tools built from scratch do, in my experience, resemble the coffee mugs I’ve made on potter’s wheel: functional, a bit heavy, and with a certain charm inherent in something made with passion but very little experience in the field.

The thing about a DIY cup is that you can still drink out of it.

But the disadvantages of self-made software for your team are the same as the advantages: By making it yourself you get better at making stuff like that, and if that’s not what makes your company money than making it yourself is a distraction from your team’s real work.

Reasons to make your own software:

• Only you know what your team really needs.
• You have the best software team in the world.
• When you need something customized, you know who to call.

Reasons not to:

• Other people have made that software already.
• They’re super good at it.
• Any time there’s a bug in *their* code they have hundreds of stakeholders and full-time coders to fix it.
• It’s doubtful that your team’s needs are really that different from any other company.

Now We Gotta Talk about Money

One of the most frequently stated reasons to make your own software is how dang much software costs. Sadly, this never works out.

You don’t need a lot of money to have a good time!

In general, when a team tells me they’re building their own software to make money, it’s an indicator that something has gone deeply wrong in their calculations. Often the conversation goes something like: “We had to build our own CRM, the only other solution was something that costs $500 per seat per month!” or even something like “we saved $100,000 by writing our own CRM”

To this, I’d start with the question “is the software that your team writes free?”

The reality is that the software you write yourself saves money only in the very short term. While the licensing fees you don’t pay save you money on this month’s balance sheets, the developer time spent on writing software isn’t shown on the same balance sheet. The features your team doesn’t write for your core product aren’t on that balance sheet, and neither are the sales you lose because half your team was distracted writing a CRM.

This Is Really about Serverless

When I talk about this, I’m not really talking about doomed DIY projects, or writing your own CRM. I’m really talking about Serverless. Serverless is not a technology for your team to master, it is not a methodology that your team must adopt. As Ben Kehoe put so eloquently, serverless is a state of mind.

With serverless you buy the vendor’s expertise in hosting, running, and scaling services. That leaves your team to build the solutions that your customers want to buy. With serverless, no one on your team is going to get better at managing your servers, they’re only going to get good at meeting customer needs. And that, of course, is probably a good thing!

Counterexamples: Sometimes Your Hobby Becomes Your Job

It’s important to focus on what makes your company money, or what will make it money in the very near future. Except when it isn’t.

The best example I know of a side project working out is Slack, which began as an internal tool for Stewart Butterfield’s company Tiny Speck during the development of Glitch, an online game. While Glitch never made much of a splash the internal tool showed promise and you doubtless have Slack open on your laptop while you’re reading this.

The history of business has some of these notable counterexamples where a fun side project or internal tool turns out more compelling than the core mission. I’m not sure what to draw here except “don’t DIY outside of your core mission” isn’t a universal truth, it’s usually true, and you should keep an eye out for when internal tools have turned into something interesting in their own right!

Feature image via Pixabay.