The curse of Bespoke Software

Taking on a bespoke development project can be an adventure

I’ve done a pretty unscientific and slightly small survey of my peers in the software business. These are  folk who have been running software companies for a while now, and we all share similar experiences when it comes to bespoke ( or custom/tailored) software.

It’s generally not a pretty picture but it all starts off so simple, usually a problem which can be described on a single sheet of paper. How hard could it possibly be to translate this into an IT system?

You’ve guessed – very, very hard. It’s not the fault of the A4 sheet of paper we started with – that spec was fine but it just doesn’t encapsulate the tricky detail that’s in the customer’s head. And of course if you’re in IT you know that it’s the little details which can totally blow your development budget.

There is a solution which involves spending a lot of time up front in definition of the system. That’s not necessarily great because often we’re breaking new ground and the client may see new possibilities for the system as things develop.

Agile approaches are good in theory, but they are often impractical as they often depend on open ended budgets and a high level of commitment from the client which are often tricky to obtain

One way of solving this problem is simply not to take on any bespoke development,  but over the years we’ve discovered a few basic principles (other principles are available):

  1. Payment on time and materials – unsurprisingly many customers don’t like this because it moves the risk too far in one direction
  2. Get paid to produce a detailed spec – this has worked pretty well and it allows us to take a decent look at the requirements and come up with a spec which can be understood by the engineering team. This reduces uncertainty and allows more accurate pricing
  3. Take a  stake in the product- either a long term support fee, a share in product sales or a stake in the company which owns it. We’ve had limited success with the last two of these but we can generally negotiate an ongoing support fee  which makes sense if you consider the risk of having an unsupported system performing a key business function.
  4. A modified version of (3) – keep the rights to the product so you can sell it to other people – this actually works pretty well if you have a customer who isn’t set up to maintain and develop software and sees the advantage of an ongoing commitment.
  5. If none of the above are possible, use the project as a means to get exposure to a new technology which will have benefits elsewhere.

It took us a long time and a few marginal projects to realise that bespoke development isn’t a great long term strategy. Of course when you’re starting out you can’t be too picky, and we were no different to any other startup, but we’re nearly 30 now and we (should) know better. We do love shiny things though so it’s a constant battle to look objectively at the long term potential.

Choose your language
1988 highlights