Build it or buy it?

By Laura Haight
Originally published in the Upstate Business Journal, Greenville, SC, on July 5, 2013 

Customize me. That’s what we want. Off the shelf, off the rack, out of the box, standard - those things are not good enough for most of us. We are special and we want special things.

When it comes to technology, the buy vs build conundrum is particularly problematic. It may come up for websites (often), for internal operations and for network design and configuration.

Both approaches are the right way to go and both are wrong for you. It just depends on how you answer critical questions, like these five:

1. What is the need you are trying to fill? Not what you want to have but what is the core need. For example, is the need for a website, or is the need that customers to be able to retrieve updated project documents? A website, program or app is just a tool and before you know what tool you need you have to know what you’re trying to accomplish.

2. What are the basic requirements? This sounds easy but it’s not. In any company big enough to be considering a custom programmed solution, bringing in different teams to collaborate on requirements is important. You have to get end users and line staff involved in any discussion to make sure that you know how things really need to work. Through this process you may also learn a lot about how your current tools are being used - be prepared for a potential shock.

3. What are key design factors? A lot of this information would be needed for any RFQ (request for quote).

  • Is this something that needs to high availability? Is it a 24X7X365 function that is critical to the business? If so, factor in what’s required to do that: redundant servers, in diverse locations, the ability to switch over automatically, dual data and functionality maintained dynamically. Sounds complicated? It can be. So make sure this is something you really need. Configuring and maintaining this is expensive.

  • Integration. Systems today do not stand alone. Make sure you know all the systems you may want to integrate with.

  • Operating Systems and devices: Who is going to be using the system or site? Is it internal - where you can control many factors - or public-facing. If it’s public facing, you will need to make sure it will work with all kinds of devices, browsers and operating systems.

  • Security. Will you be accessing or collecting any sensitive data here? Credit card numbers, customer information? If so, you just kicked up to a new level of design. Some application design companies - like Yella Soft based in Greenville - hire program crackers throughout the world to try and break into their systems. When a hole is found, they plug it. Most companies don’t do this; but if you are holding sensitive information you want to take every possible step to secure it.

4. What’s out there already? Once you know what you want in a system or application, you have a blueprint for exploring what is already out there. Check out websites, ask vendors, look at the sites for businesses like yours. You may even be able to do some competitor research. If you find an app or cloud application or service that seems to do what you want, contact the company for a free trial. The trials will not be as full featured as a full application, but they might give you an idea if they are even in the ballpark. Ask questions about security, backup, redundancy - all the issues that you worked through in the first three steps.

5. What can we support? This is where the rubber hits the road. Customization is not a write-it-and-forget-it process. Security particularly is a function requiring constant diligence. If you have a public-facing system, like a website, you will need to be prepared for thorough testing when new operating systems come out, when one of your integration partners changes its software, when new devices are released. If you don’t have the staff or the budget for thorough maintenance from an outside developer, you may need to back off of build it and move into “buy it”. Or possibly change some of your requirements; instead of taking credit card numbers yourself, perhaps you can rethink your process to move to a passthrough process to a payment processor.

If you hire someone outside of your company to build your application or website, make sure you have a full set of design documents and that code notes are included throughout. If that designer moves, goes out of business, or just stops supporting you, will you have what you need to pass off to another developer for maintenance?

Looking at this column, I realize that there are a lot of questions - not so many answers. But, in the words of a close friend, you don’t know what you don’t know. Once you know the right questions, the answers and the path they lead you down will be a lot easier for you to figure out.