I had the opportunity to speak with a CTO of a medium sized company this week as part of the interview process. The exact nature of his company isn’t important. What is important was something he mentioned in passing describing their current situation.

He talked about working hard to convince the rest of upper management that they didn’t have to build every single solution they would ever need. It doesn’t make sense to build a calendar app from scratch when there’s dozens of available solutions. It reminded me of an old adage I learned early on in my development career:

Don’t build it if you can buy it. Don’t buy it if you can steal it.

I cannot tell you how many times over the years I’ve looked at my management and said, “You know, we can buy this solution for like $100 and just adjust it until it works for us.”

I also can’t tell you how many times the order’s come down to build it anyway.

There’s an evolution to a lot of non-tech-centric enterprises that can help explain this. Let’s say that you and a partner open up a widget shop where you take custom orders for widgets via an out-of-the-box, zero configuration system. (I’m looking at you, Shopify.) It works for you, in the sense that the orders come in, but there’s an awful lot that you wish you could do with it, but it doesn’t.

So you get a little bit of money together (but it seems like a lot at the time) and you contract with a team that’s based in some place you’ve never heard of before, and they build you something more customized.

If you’re lucky, that goes well, but often it doesn’t. In either case, the new customizations go fine for you for a bit, but then you need more. The original contractors you used have closed up shop before you can realize that they’ve written terrible, useless code. So you find another contractor, but you’re not sure what the heck they’re doing. It’s taking forever, and you’re suddenly managing the contractor more than you’re managing your employees.

You hire someone to do the tech. (Maybe that guy’s me.) I get the contractor straightened out. I finish off the stuff the first contractor didn’t or couldn’t. You decide you want some new changes cause you’re paying me anyway, and I make those.

In a few months, you want a new module for the application to do scheduling for widget delivery. We setup to build this. We decide it’ll take 2 months to finish, and it’ll be more than the original contractor charged you way back when, but now that doesn’t seem like such a bad price anymore.


Why are we building a scheduling app? I’m sure that this is a problem that has been solved before. I’m pretty sure we could buy a scheduling app and patch it into our system in a few days instead of a few weeks. Plus, that app will have it’s own professional support, security updates, feature additions–all kinds of stuff we’re not going to do because we’ll be busy.

So why not just buy it? I believe the trap is two-fold. Firstly, the business (that’s you in this case) are finally confident in the development process, and they want to use it. And the developer (that’s me) doesn’t want to push back, because I get paid to develop things–not to find pre-built solutions.

But good form is to buy it. You wouldn’t ask in-house development to build you a spreadsheet app, because you’d find out that Excel has like a billion man-hours in it, and because you’re comfortable with the idea of buying that software.

I heard that from this CTO, and I smile a little, and I felt like he was a smart man who was going places. I don’t think I’m interested in the job, honestly. But it was nice to hear another tech pro remember the old idea.