It’s an age-old IT question: Build vs. Buy. Two distinct choices when solving a problem with software.
Most good software comes about as a result of existing software only doing 80% of what somebody needs it to do. Solve 80% of the problem you set out to solve and you’re probably in good shape. That number goes up considerably if you plan well and hire smart developers. It goes down considerably if you simply throw money at a problem that isn’t clearly defined. I’ve seen companies spend (literally) millions of dollars on solutions that were never even used. Obviously a lot goes into that success, but in many cases the vendor and client simply don’t agree on the problem or the proposed solution even though they think they do.
Build
- Pros
- Specific solution that solves 95% of the problem
- Security can be much better (obfuscation and proprietary methods)
- Forces you to identify opportunity cost
- Cons
- Code maintenance is a challenge
- Mindshare can leave with employees
- Forces you to identify opportunity cost
Buy
- Pros
- A support contract is a cheap insurance policy
- Larger throat to choke
- Leverage with vendor
- Cons
- Only a partial solution
- Hidden costs (customization / professional services)
- Vendor lock-in
I always advise my clients to be sure they understand the problem they need to solve and to put a dollar amount to that problem. This sounds very simple and obvious, but sometimes they neglect to look at it that clearly. Granted, you don’t need to tell the vendor what you think it’s worth, but if you don’t have a dollar value in mind you will almost always be surprised. Estimating software projects is a very difficult science (or art, if you prefer). Once you’ve done your due diligence, the decision of whether to build or buy sort of answers itself.
I like to recommend a phased approach for most product or application development projects. I’ll sit with a client and have them rattle off everything under the sun that the product could be capable of (sometimes this is the most entertaining part of my job). Once we have a reasonable feature list we can prioritize on what NEEDS to be in Phase 1 and what can wait until Phase 2, depending on the initial success. I’m always trying to get my clients to think carefully about the value they place on the project. If they don’t see it as important, they certainly won’t like my invoices. I’ve even talked clients OUT of giving me their money on solutions I don’t see any value in.