A common dilemma of many tech managers and businesses in general is when presented with a business problem, do you build your own software or do you buy? For some companies, this is an easy answer. Some development teams are not equipped with the skills to build a particular tool or product. Other companies just do not have any budget available for the product needed, but do have ample resources to work on development. But for the teams and situations that fall in that middle or gray area, what do you do?

So, how do you decide to build or buy? Through my experiences I have compiled a short list of questions you need to ask yourself as a technology manager.

1. Do I have a budget to buy this product? – If not, the answer has been made for you. You will need to build a product that does the task, or at least can hold you off until there are available funds for purchase. Beware of the trap of building a ‘good enough’ product that then stays long past its shelf life.
2. Can my team build this? – This question has a couple of things to consider. Does your team have the skillets to build the product. Development teams have roles, and sometimes its obvious. For example a web team that builds games is just not going to build a billing system for you. Second, do you have the available resources and time? You may have the talent, but will you be able to set aside the right talent for the time required? They may be needed elsewhere.
3. Does developing in house cost me in other ways? – Once again this speaks to your talent base. Maybe you can put a developer on this application for the time required, but are you missing out on future development opportunities? Is this project so far from their original skills and desires that you will diminish team morale? Less tangible than cost, these are still important to consider.
4. Will the commercial software suit my needs? – My experience has been that many products have a set fee, but then you need to factor in the additional cost of customizations or additions that will suit your business needs. Or you think you can get away with a basic implementation, but soon need to upgrade, incurring additional costs. Or if you are paying for a subscription model, there may come a time when this may not be cost effective anymore.
5. What will the cost be to build? – Again there are a couple of things to look at here. First, how many development hours will a project take? To get a good assessment, you need to be skilled at creating project estimates. If done incorrectly you can end up in a losing proposition. Ask yourself, does your company have a history of feature creep? If so, this project will inevitably take much longer than originally thought. Finally, what is your possible productivity loss? Does putting 2 developers on a six month project keep you from developing a new tool that can be monetized? As Opportunity costs are just as important as accounting cost.
6. Could this be outsourced? – Sometimes the solution is not to build in house, or buy, but rather to have a custom application developed for you. It has been my direct experience that a lot of outsourced code, while possibly cheaper initially has cost more to grow over time. Digging through lines of code to fix bugs or to add a feature ends up wasting a lot of time. If you expect the contracting company to support the product, make sure they have been around awhile, and that you feel confident they will be there in the future. Also make sure their business model allows for incremental updates and support. Many consulting teams work on building and deploying full tools, and are not interested incremental additions.

I have to admit with the increased amount of opensource code in the community and advanced APIs to work with, I tend to build. We can usually find a good opensource product, edit and grow it for our needs, and save a lot of time and headaches. Or we buy a small commercial component that takes care of some aspect of the tool that we could/should not build, then build around that component.

Do you have similar issues? How do you decide whether to build or buy? Maybe you made a decision and wish you had chosen the other? Did I miss a major point in my decision process? I’d love to hear from you. Join the discussion in the comments. We should all learn from each others experiences.

image by msmail

Related posts:

1. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...
2. Defining Roles Within a Development Team I am a big advocate of keeping teams lean and...
3. Web Development is a Creative Career Web developers are different breed of technologists. We are increasingly...
4. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
5. transparent background Let me give you a little information about where I...

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under:
dev team, experiences, philosophy, software by bill breen