Buy vs. build your software, 8 things to consider

As the owner and account manager at a medical software company specializing in physician call scheduling software, I occasionally have a prospect tell us that they are "thinking about creating scheduling software in-house".  Although I highly discourage this due to the complexity, staff requirements and amount of time that would need to be invested to re-create what we have already done, I thought I would be objective and tell you when I think it’s good to build versus buy. 

After researching this topic, consensus appears to be:  Buy when you need to automate commodity business processes or to standardize; build when you’re dealing with core processes that differentiate your company or to compete.  “Everyone knows that the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance,” says Mark Lutchen of PricewaterhouseCoopers.

Here are 8 things to consider when making your decision:

1.      Upfront Scope and Requirements costs:  what do you want the software to do and how will it look and function.  What are your expectations?

2.      Upfront development cost:  You will most likely need project manager(s), lead architects, coders and testers.  Also don’t forget the technology required to develop and test.

3.      Upfront time:  Scope and requirements can take 2-3 months full time on a project that is medium in complexity.  Development can take 6-9 months and testing another 2-3 months.

4.      Plan for the “ooh, that’s what you meant” most projects have some amount of re-work required to move forward.   This is usually greater if you decide to “off-shore” your project.

5.      Ongoing maintenance:  Software becomes outdated the moment it is released, that’s why there are patches and updates.  Not to mention that every time you update or patch something, chances are that you will break something else.

6.      Software maturity:  This is the point when you have an ultra-stable system that is virtually bug-free.  This is a moving target.

7.      Staffing:  What happened when your coder or project manager gets a better job offer or you have budget cuts and have to eliminate a key position? 

8.      Intellectual property rights:  Don’t forget about the IP that will go into this project during the development.  Although most companies have policies that state that anything that is developed on company time is property of the company, that does not preclude your employees from developing “similar software” for another industry or building on a concept that was scrapped at work.  The hardest part in this scenario is finding out that someone has a covert project going on at home.

                                                    Graphic by Bruce F. Webster

I think a good argument can be made depending on your goals and objectives.  As an example, we have developed custom on-call doctor scheduling software to sell to hospitals and clinics.  We truly feel this is core to our business.  But on the flip side we have purchased via SaaS model both CRM and Accounting software where better mousetraps had already been built. 

I think the key takeaway is to know what you’re getting yourself into and why are you deciding to build vs. buy software. 

______________________________
Justin Wampach is president of Adjuvant Technologies, developer and provider of Call Scheduler. Contact him at 320-257-7134 or justinw@call-scheduler.com