Buy vs Build How to know whether COTS is right for you?

One of the challenge most startups face as they transition into a larger organisations is knowing which technical battles to pick in order to remain a disruptor in their industry space.

It’s important for every development manager, CTO, CEO and even executive board to understand that unfortunately;

There will always be more work to be done than can be completed.

This usually being in the form of a large feature backlog and/or large list of projects the business wants to tackle in a short time-frame.

Enter COTS or Commercial Off The Shelf software.

In a world where moving quickly can mean the difference between being a disruptor or getting disrupted there are a huge array of products that are available and ready to solve the problems you currently face. There are a huge amount of benefits to doing this.

Advantages to COTS

  1. It solves your problem.
  2. Can work out cost efficient.
  3. Can generally be setup in very small timescales.
  4. Maintenance of the application is not your problem.
  5. Features and enhancements will come out regularly ( SaaS in this instance ).
  6. Is an expert in that field.

One of the single greatest rules in software development nowadays is quite simple.

Never reinvent the wheel.

You rely heavily on your team to choose the right programming framework, write as little code as possible and still keep the balance of flexibility and performance so you can respond to change.

So it looks like COTS should always be a contender before going straight to build. Like most things there should always be a balance. Here are some considerations to COTS.

Disadvantages to COTS

  1. You don’t own the product roadmap, their vision of the product might diverge from yours.
  2. It might be 90% of what you need right now, but that last 10% may never be delivered and restrict your growth.
  3. Your business model changes and you can’t respond.
  4. Once your locked in, its difficult to escape. Its a form of technical debt that grows overtime.
  5. The commercials might be weighted to penalize you for growth and you have no alternative but to pay for it.
  6. If your a small client on a large platform, can you be confident your service will be A grade.

How to evaluate COTS vs Build

The best way to evaluate whether you should be buying or building is the following.

1. ROI

What is the length of the life cycle the product will be in production for? 6 months or 6 years? If your planning to remove the product shortly after implementing. Don’t forget to calculate the removal of the product into your projections. If your product will struggle to survive 3 years. The removal of the product will cause a major project that will hinder growth in other areas later down the line.

2. Timescales

Determine your timescales for your own build. When scoping your own build be brutally efficient in the features you actually need. Most COTS products provide functionality that add no real benefit to your particular business model.

3. Skill set

Does your team have the knowledge required/skill-set required to implement that product themselves. Although a COTS product might only last 6 months. Your own product may be implemented incorrectly, causing large technical debt that ultimately will need to be paid off. Effectively causing a rebuild.

4. Flexibility

Linking very closely to product life cycle. Can the product that you implement adapt to what you need going forwards. Before going on the endeavor, make sure you understand your business and where it is going. This avoids you trying to plug a hole and looks at the big picture. If you need to create your own IP. A platform you own, is definitely going to be able to give you that.

Final Conclusion

Here are some of the rules I follow in order to understand Buy vs Build.

  1. Never outsource your core. Whatever makes you special. Make sure its your problem. It will make your business if you do it right.
  2. Commodity software is best bought. Don’t build a financial system if its solving a problem in finance. It also looks good to external investment if your internal process is an accepted standard.
  3. If your thinking about removing it before you start. Its probably not a good idea.
  4. COTS or Custom build. Don’t over scope what you need. Focus only on what is going to get you to the next level. Compare Apples with Apples when determining the best course of action.
  5. Don’t let the board or the bosses push you on unrealistic timescales. Do it right in a reasonable timescale. Make sure your making the right decision, not the one that panders to timescales.

What is an MVP

To be able to build a successful application, we must first understand what its first iteration should be. This is a Minimum Viable Product. Everything in successful modern development practices (I am referring to developing with Agility) is geared up for producing this type of product. It is this approach that has caused the explosion of some of the greatest internet success stories to date.

So what is a Minimum Viable Product in software development? Well, here is a definition from Wikipedia:

In product development, the Minimum Viable Product (MVP) is the product with the highest return on investment versus risk. The term was coined and defined by Frank Robinson, and popularized by Steve Blank, and Eric Ries (for web applications). It may also involve carrying out market analysis beforehand.

Like the graphic above, a Minimum Viable Product should be something that delights the user throughout its evolution.

The challenges most businesses face when building the product is understanding that the end goal (in this case being a car) can be a huge risk. Why? Because humans are fallible and if your business is not used to building cars with a proven successful track record, the cost of getting to the end result could be disastrous. What if half way through your build a competitor releases an application with only 2 of your 10 features and steals your market share instantly?

What a MVP should not be

A lot of people get confused with what a Minimum Viable Product deliverable should be. Rightly so: it is subjective, and there is a debate about what it is. The common pitfalls and put offs with approaching work in that way is that they have been left with a crappy product that ends up dying before it starts, consistently producing a single wheel instead of a mode of transport. Never forget though – everything can be done badly.

What do you need to create an MVP?

The recipe for a successful first release is simple. You need the 4 main ingredients:

  1. Vision
  2. Mission
  3. Goals and Objectives

The 4th ingredient to truly be successful when scoping out an MVP is that you need the alignment and buy-in of senior management. The goals and objectives of the business need to be transparent to everyone. You may even require an alignment session to really nail down what your trying to achieve. Try to stick to the SMART objectives model.

Don’t focus on features, focus on impacts

Don’t let an MVP become a shopping list of features. This will make you produce a wheel rather than a skateboard! Senior management (generally) are not technical experts, and so suggesting features may break the whole purpose of keeping the cost vs risk to a minimum. If the group has a shared understanding of vision, the delivery experts will be the ones to help suggest solutions that deliver those goals in much more cost effective ways.

As Aarron Walters so succinctly puts it, maybe a better way of looking at MVP is actually;

  • Minimum
  • Viable
  • Delightful
  • Product

mvp design

With a coherent vision and a product that makes sense, you can seize your opportunity quicker and cheaper, and reap longer term benefits (or not as the case may be), with the most efficient use of time and effort. It is this movement that will continue to breed and create disruptions in the exciting world of technology engineering.


Next steps?

This part of product development stage as Eric Ries describes in “The Lean Startup” now moves you to the measurement stage. This is where you can assess your goals and objectives to see if you met your success criteria. This should serve as a spring board to iterative product development which I will cover in another post.



A new year.

A new role.

A fresh perspective.

That, and well my previous blog was hacked. Not a great sell for a developer, but to my defence my focus was more on my career than on my hobbies.  So I’m back. I may write “technical” things, but my skill set has always been focused on delivery and ways of achieving it. While I will add technical nuggets from time to time, my new focus will be a summary of my collective experiences and how that has shaped my understanding of development.

So, echo “Hello world”.”Again!”;