Tips for Technologists #19: Build or Buy Software

In Tech Digest by Nick Ruffilo

Tips for Technologists is a series aimed at teaching you to engage with technology in best way possible. You can see all the Tips for Technologists articles here.

By Nick Ruffilo

computer workIt’s a common question for businesses with specific technology needs: is it better to build software or buy it? The decision isn’t just based on cost, so here’s an analogy to help you decide.

The Why Factor

This article is for the technology decision makers in an organization. It covers the decision making process of “Build or Buy” when it comes to technology by discussing the pros and cons of each approach. It also touches upon the approach for creating an in-house development team.

Build or Buy: Software and Houses

Whether you own a home or rent an apartment, inevitably something will break and need to be replaced. If you have no knowledge of how to do even the simplest of fixes (unclogging a drain, hanging a cabinet, painting, etc.) then you are at the mercy of professionals and their rates. Professionals are paid well because they know exactly what to do and how to get it done quickly, but they come at a cost. To de-clog a drain (run a $10 snake down a drain) a professional could charge from $100–$150. Whereas, if you bought the snake yourself, it would merely cost your time (which also has a value).

To be perfectly clear, by “build” I mean “build it yourself,” and “buy” I mean “buy it pre-made or pay someone else to build it.”

Taking the metaphor further and extracting value.

When you need something that is complex but abundant (such as a door) unless your profession is door-maker, then you should buy. When it comes to installation, if you have some experience, you’ll save money by doing it yourself (one of the reasons I’m doing this Tips for Technologist series is to give you the tools/knowhow to save yourself time and money). The same applies to software. Do you need a word processing software? Get a copy of MS Word or Pages. Need a graphics editing program, purchase Adobe Photoshop (or Gimp if you haven’t the money). These are necessary tools that are common, so unless your business is making them, you should buy them.

When you need a simple repair – pay a professional the first few times, learn from them, then do it yourself. In a home, the cost estimate for replacing an electrical outlet is about $150. Just $10 of that is the outlet itself. The steps to replace an outlet are simple.

  1. Turn off the power to that outlet at the breaker (flip a little switch).
  2. Unscrew the outlet cover.
  3. Remove the outlet (unscrew 3–5 screws)
  4. Connect wires to new outlet, and screw them in.
  5. put outlet cover back on.
  6. turn the power back on.
  7. test.

I speak from experience when I tell you this can be done in 10 minutes (including the time it took me to walk up/down two flights of stairs to get to my breaker box). Over the years I’ve had to replace about 10 outlets, saving myself $1500. Most electricians will let you watch, and even tell you what they are doing but there are always wonderful books at Home Depot or Lowes on how to do basic home improvement jobs.

The same goes for tech. Get a new version of Microsoft Windows? You can pay the Geek Squad $29 (in store) or $129 (at your home or office) to install it for you, or you can pop in the disk and press a few buttons when it asks. Both personal and business level tasks can be handled the same way. Need a bunch of data to be churned into a graph for a presentation? You could put in a request for the tech team to do it, or you could load the data in excel and create a pivot chart.

Now we get to the difficult part — the grey area

Unless you have an unlimited budget, or no budget, your best bet is finding the perfect mix of build and buy. Lets say you are opening up a bookstore and need to furnish it and get it up to code. You have some basic handy skills, and some money. Lets go through a checklist and see what makes sense.

  1. Doors — Buy
  2. Windows — Buy (will most likely need to be custom though)
  3. Shelving — Buy & Build (will want them to showcase the books well)
  4. Paint — buy the paint, paint the walls yourself
  5. Light Fixtures — buy the fixture, install it yourself
  6. Checkout Counter -—Buy
  7. Point of sale system / Customer Management System — Buy

Ok, you get the point. Now things get interesting. The business is doing well, and you’ve opened a few new stores. You now are profitable and are looking to cut costs. For me, I see customer relations as the highest priority for a business. As a business owner, that would be a core competency that I would want to own. Sure, I could staff people who know how to build shelves and install windows, but if I can make my customer relations better, I will do more business and make more money.

This is the point that you should really be asking “build or buy?”

Unless you already have expertise, if you are doing a pilot, test, or one-off project, you should almost certainly buy. But, if you are trying to improve a core competency then you should start with the decision to build and work from there.

Always start your search with complete solutions. In the example above, you will want to look at all the customer management systems out there and look at the features and total cost. Keep in mind that future expansion may mean you would need additional software licenses so that should be factored into cost. If you find a solution that fits all your needs, take its spec sheet and bring it to a software development house and get them to estimate a cost and time. If done correctly, bringing the work in-house should cost half as much but take two to three times as long.

What bringing development in-house really means for your business.

If you already have a technology development organization within your company, then this section does not apply to you. But, for many publishers, their IT division (if one such division exists) is there to manage their Intranet, keep the computers running, and ensure people can connect to the Internet. While this is an important role, it is not software development and cannot simply be transformed to becoming one.

A good technology organization needs the following roles (they can be all one person, but they are distinctly different roles with different skill sets needed to be successful).

  • Translator: This is the person who understands technology and the business needs and takes requirements from the business. Sometimes called a “Business Analyst.”
  • Project Manager: Works with the developers to chunk development tasks, estimate their completion, prioritize them and communicate back to management expectations of delivery.
  • Coder: The person who will actually be writing code.

If you are missing any role above, you will have a very rocky experience and are most likely headed on a path that will not lead you to success. For small organizations, I’ve seen this work with 1 person (in fact, I’ve been that 1 person before) but if you are getting development estimates in the 200k+ range, you had better expect this one person to have a year or two to address your development needs. If you have the budget and ability, you should hire at least 1 person in every role (two or three coders for larger projects).

The key advantage to building instead of buying is an aligning of incentives.

An app-development shop wants to maximize their profits, which means turning out a product that meets (and slightly exceeds) your requirements but done as quickly and cheaply as possible. This means that they will rarely look for better ways to do things, especially if that better way is more costly (or they will turn that cost around to you two-fold). Also, their success is in completing the project, not having the project be successful. If you request a feature that is undesirable, they will deliver on it, whereas an internal team may question your request and save time by eliminating the functionality or suggest better functionality.

There is additional responsibilities — unlike an external team, you have to continue paying salaries after your project is done, or if it is on hold. I don’t often see companies that have a lack of technology projects to be worked on, but if that is the case, “down time” between projects can be used to have the developers experiment with new technologies to see if there are better ways to do things, or new functionality that can be added to future products. Application development teams can quickly and easily be turned into research and development teams when it comes to software. In fact, I highly encourage it, as it acts as a form of continued education for developers (which increases their value to your organization).

Having a small development organization in a large company

For a medium-to-large sized business, having at least a small development organization (one of each of the three roles) is akin to having a good friend who is a contractor. While you may not use them for all your jobs, they’ll help you weed out the bad contractors, and will give you a good estimate for projects as well as tell you what you really need (sure, oak looks beautiful, but you may only need birch). So, even if your 3-person tech team acts solely as a proof-of-concept/R&D team that provides you insight on technical direction, they will save your organization far more than their combined salaries on external development projects.


Paying others to do your development has a high cost, but can be done quickly and does not require your business to build a development competency. Great for tests, proof-of-concepts, or one-off projects. Building something in-house requires you build the competency first, but can reduce overall cost (at the expense of some time). The important question is, what does your organization do, and how does it provide value? If some sort of software is involved (and yes, ebooks are software), then can you really afford for it not to be a competency of yours?

About the Author

Nick Ruffilo

Nick Ruffilo is currently the CIO/CTO of He was previously Product Manager at Vook and CTO of BookSwim.