Lately, I'm finding myself being asked the following question over and over again:
When is it appropriate to buy software, and when is it appropriate to build software? What do you base your decisions on? What principles do you apply?
The consultant's answer is, "It depends", but here are some heuristics I've found that have helped me apply some meaning to my decisions which at the time can seem like a gut-feel.
1) Buy for time-to-market
It's normally a good move to buy COTS (Commercial Off-The-Shelf) software if it guarantees a faster time-to-market. It's better to get your foot in the door with software that might not 100% meet your needs if it means that you'll beat your competition by a significant margin.
Note: Don't fall for the powerpoint. COTS systems can take ages to implement too, and will incur a level of development anyway - normally around integration efforts. This point stresses the word 'guarantee'
2) Build for the User Experience
I always strongly advise for building software when there is a user-facing component that requires a solid UX layer. As long as this doesnt conflict with 1) above, and as long as 1) above allows a customised user interface at a later stage, these two rules can exist in harmony.
This rule applies to user-facing API's too.
3) Buy for non-core functionality
ERP's, CRM's, CMS's are a solved problem. Done. Over. Don't waste a second building your own. If your needs are simple, and you don't mind delving into code now and then, open source alternatives are viable here too. As SaaS applications grow even more sophisticated, this becomes an extremely attractive option too. Don't waste developer time building something that is a solved problem.
Also - my definition of core vs. non-core is this:
I determine software, services, products and disciplines to be ‘core’ to an organisation under the following conditions:
- When it is deemed to be of strategic importance
- When it is an actual product that an organisation sells
- When it directly supports a product that an organisation sells
4) Buy to avoid opportunity cost
This is a spin on 1) above, but reaching this conclusion tends to come from a different path. Sometimes we're not racing against a market, and have the time, but there's an opportunity cost to consider. If a development team spends 6 months building something, what is that they're not building instead?
5) Buy when TCO vs. ROI don't make sense in a dev context.
This one is pretty self explanatory. If the numbers don't make sense or add up, just don't do it.
6) Build for differentiation
Building software so that you stick out from the crowd is always a good move, providing the criterion above makes sense too. Nothing builds client stickiness like a fit-for-purpose all-killer, no-filler custom system. Your client's, being the super-smart people they are, will notice this and appreciate it.
What you typically find when building for differentiation is that this becomes a breeding ground for innovation and cross-pollination of system functionality. In this space, you'll find a natural inclination to take features from System A, mash them up with System B's features to build System C that is greater than the sum of its parts.
That's my general thinking on this subject, if you have thoughts to add, there's a comment box a few pixels down.