Getting new software – Make or Buy?

This is a huge question facing every buyer of software today.  Why does Joe, the owner of Joes Baked Goods LLC, a $100 million bakery thinks he can hire his brother-in-law’s son “the geek” for a summer and have the same Manufacturing Execution Tools that others have paid hundreds of thousands for?   If it was that easy, as they say, everyone would be doing it.

There is no question that with the tools and technical expertise available today, many solutions can be built in-house [and some should].  But, these should be very specific, very contained, very well defined, very organization-specific, and/or very confidential solutions.  They should be single-user or at worst, workgroup solutions.

To even consider building an integrated enterprise solution today should be met with a great deal of skepticism by management.

In most cases today, there is a well-written, well-supported, fully-featured parametric package out there that will do what needs doing, and much better than anything you can build – even given unlimited time and money.  Do you want ABC Biscuit Company to make the best biscuits; or to become the ABC Biscuit, Software & Computer Company?

Conversely though, your software often gives you a competitive advantage.  If the software supplier that is telling you how you need to run your process (because that is the way their software works) could run your business as well as you can, perhaps they should be in your business rather than software!  However, there is still probably another package that is adaptable to the way you do things.

So there are some unique circumstances when building your own, is a viable option – but that is usually where proprietary processes are involved, or you come up with a need that no one has ever automated before – unlikely but feasible.  The trick is to know the difference.

Remember the inevitable laws of software development, all of which are unfortunately true:

90-90 law :  “The first 90% of the software takes 90% of the time to build, and the last 10% of the software takes the other 90% of the time.”

Cheops’ Law:  “Nothing ever gets built on schedule or within budget.”

Brook’s law:  “Adding manpower to a late software project makes it later.”

Starting down the “we can build it, they will come” road is costly.  I have seen clients delay implementing a solution because they are going to write it.  Years later, they are still going to write it.  If they had implemented the package solution in the meantime, just as an interim solution while they were writing the panacea, they would have paid for the package several times over from savings.

Sure, $100,000 or more may be a lot of money to invest in a solution, even if it saves $500,000.  Perhaps putting a couple of junior programmers in a room for 6 months to a year will give you at least the basics you need in your business – you don’t need all the bells and whistles that the $100K package has.  So pay each of these guys just $60,000 a year ($120K), plus benefits ($30K), give them an office ($5K), development software ($10K), and computer horsepower ($5K), and give them unlimited access to the user community that they will need to develop a responsive package ($$$).  And get someone to write decent user documentation (about 30% of the cost of any system).

What most people don’t realize is that it is not the writing of the code that is difficult – exceptional coders are available – it is the ability to understand user requirements and translate them into workable system definitions that work in the culture and are supportable on current and future platforms – that is the key to success.  This is why sending the code offshore to be “developed” in India often fails.  In order for the Indian coders (who are very good) to write it correctly, you have to take the time to define it in infinitesimal detail – so now you need to add your time to the expense calculation.


At the end of the year I guarantee you will have a half-written, very basic single-user partial solution, and be out about $300,000 in salaries and expenses – not to mention the opportunity cost of not having a solution in the meantime. Even if the junior programmers produce exactly what you need in the time promised (you would be the first), you will still have spent $300,000 and lost a year getting part of a $100,000 solution.

So, to avoid this, you will decide to hire a “professional” consultant, or software developer.  You still need the detailed definition.  All you have accomplished is a restart, and a cost base of $100+ per hour, instead of $30.

I personally wrote my own Client Database several years ago.  Took about 6 months and did exactly what I thought we needed.  Single user.  Then we bought a commercially available CRM.  Cost about the same as the underlying database and supporting software for my custom system.  Had everything mine had, and hundreds of other features we could use, but I had not even thought of.  And it was designed for enterprise use.  No brainer!  We still use it.

At QIC we have developers on staff to perform integration for clients.  They are beyond programmers – for the most part they can define the details and understand the business processes behind the software.  If anyone is positioned to write our own, we are.  And yet, every system we use internally is an application package.  There is a reason for that.