Many software development houses prefer to develop all the tools required for their products in house. There are many advantages to this including control of the source code, no royalty fees, quick patching of bugs, and having a toolset custom tailored to their application. Not to mention security risks that come from relying on another company’s product. But all of those benefits can quickly be outweighed by the time to market edge provided when relying on 3^rd party tools. This especially applies to smaller companies who, simply put, may not be able to bring their product to realization without depending on pre-created code bases. Limited developer availability, tasks outside the skillset of a smaller development force, and the need to start profiting from new products as soon as possible make purchasing 3^rd party API’s and tool sets a wise choice for the small to medium sized company.

Relying on another company’s software is not just a compromise. When chosen wisely, there are strong benefits too. The tool you purchase is what its parent company specializes in. What might be given minimal attention if written in house is likely very feature rich when purchased, adding value and features without extra effort. There may be many years of development and evolution in a product that you can take advantage of for minimal per installation or per developer fees. You also gain a user base likely far outside of your own. This means that bugs are more likely to be found, reported, and fixed. All with little to no effort from your in house team.

Choosing whether or not to develop in house or use 3^rd party tools can be a tricky decision that comes down to a few key points:

• Obviously #1 is if the 3^rd party tool completely fits the bill in your application. If not, however, many companies are glad to work with you to make tweaks or add features to their product so long as it adds broader value to the rest of their customer base.
• Can we afford to release our product in a timely manner if we develop all components in house?
• Compare the in house developer cost of writing the code vs. the fees involved in purchasing it. This can be more involved than just how much your developers are paid: what else could they be doing with their valuable time instead of writing this code?
• Are you confident that the company you are purchasing the tool/API from will be around for a good long while, has an established user base, and produces updates and bug fixes on a regular basis?