If you have the option to buy it (along with customers) it might be a good idea to find the financial arrangement. There are stagnant small businesses where owners are dreaming of retirement and will give you the stream of revenue because conditions are no longer on the upside.
Internally we had the same debate of buying versus building and created a criteria list associated with weights for each line. Here is a short sample:
| Buy | Develop | Comments | |
|---|---|---|---|
| time to market | short | depends on on items 3,5 | |
| implementation risk | none but the software debt can burden further updates | depends | |
| product comes with customers | serious advantage for up-sell | could be an uphill battle | |
| implementation cost | none | depends on in-house talent and the rarity of the skills needed | |
| time and cost to break-even | can be calculated right away | it is just a projection phase for new software | |
| path for upgrades | might be difficult | should be designed as such |
The most frustrating problem with existing software having customers is the acrobatics required to adapt to new requirements when the design was totally absent or barely modular. You start to have frictions and existent customers are biased to think you don’t want to serve them.
We encountered cases when inexperienced developers launched a product, fought hard to keep it afloat in the buoyancy of new customers and deserted the ship when real waves started to hit it.
In other instances the business side was blinded by the sell potential and promised to allocate money after the transition is over for version 2.0 and everything sunk in an everyday effort to patch and keep the product afloat.
As always, new technology and paradigms are coming into play making some parts of the software to be much easier and robust to come to fruition. At the same time people have to remember the fate of COM/ATL/VB/ActiveX/WPF in Microsoft world as well as Sybase/Palm/Blackberry/MS Phones most recently.
Just food for thought!