Try our conversational search powered by Generative AI!

Dan Matthews
May 24, 2013
(0 votes)

The first, easiest (and worst) decision your tech start-up will make

Yesterday I was at the premier conference for technology entrepreneurs and start-ups in South Africa, Net Prophet. I had a chance to mingle with some of the fantastic talent we have here in Africa and there is one thing that I kept hearing in conversations and it went something like this:

“We had to keep costs low, so we built our own platform”

Or, sometimes, a variation:

“We had to keep costs low, so we chose an Open Source platform”

On the face of it, that makes perfect sense. For a technology start-up you start with an idea for a product or service, and the first decision you need to make is what platform to use. Apparently, it’s a no brainer. An easy decision that you can’t get wrong. Or can you?

Let’s take a step back and see what you actually need for a start-up. Yes, you need that great idea or service that someone wants to buy from you, but what you then need is capital. Money. Greenbacks. Moolah. There are various ways of raising it – running a start-up in parallel with your day job, selling your house and car as capital and living out a cardboard box, getting an angel investor, joining an accelerator program… but whatever option you choose, your start-up needs to be as lean and mean as it can. This is something we all know to be self evident; low overheads mean better margins and higher profit or – if required – the same margins and lower end cost to customer, increasing competitiveness.

This is then when we come to our first decision. We need a platform, we need to keep costs low. If we custom build or go Open Source, our cost is zero. Lean. Mean. Profitable. Successful.

But wait a moment… what many start-ups fail to realise is that the art of keeping costs low has two distinct and very important parts; capital costs and running costs. What is the distinction? Capital costs are the costs incurred by a business to get to an operational state, and running costs are the costs to operate the business. For our start-up, we need to consider both. Remember, time is money. Every minute you spend before you are operational is a capital cost. That includes time developing or extending your platform. Somehow, you need to pay for your time to do that. Just because the platform is free doesn’t mean it doesn’t cost you anything. Then, once you are live, you need to consider how much time you spend maintaining that platform. Something that was free might actually incur far higher operational cost than you expect, both in time and hard cash.

On top of all this, we have a golden rule for start-ups… get to market as quickly as possible. Why? Because then you can start making revenue, and that makes a successful business. This is lots to think about, so let’s summarise our options.

Option One – Build It Yourself


  • Exactly what you need
  • No initial license cost


  • Long time to develop causes high cost in man hours (capital cost)
  • Long time to develop causes slower time to market
  • Continuous maintenance required
  • Difficult transfer of skills
  • Limited to knowledge of developers (if you didn’t know something, how could you have built it?)


  • Capital cost HIGH
  • Operational cost HIGH
  • Time to market LONG

Best when…

  • You are happy to take a long time to go live
  • You understand your market intimately
  • You have another steady revenue stream
  • You have an extremely knowledgeable development team
  • You can guarantee your development teams availability long term
  • You have very cheap operational resources
  • You can afford to burn time

Option Two – Open Source


  • No initial license cost
  • Existing platform reduces effort required (capital cost)
  • Quick time to market than build-it-yourself
  • Paid-for-maintenance available
  • Skills can be transferred


  • Technically oriented (designed for developers by developers)
  • Often disjointed and inconsistent as it’s build by a disparate team with different needs
  • Still requires heavy development (although less than build-it-yourself)
  • Lock-in to a product that is potentially transient
  • Community support often lacking
  • Additional modules can cause ‘patchwork’ software of varying quality
  • Requires continual attention and maintenance
  • Vendor support (if it exists) can be expensive


  • Capital cost AVERAGE
  • Operational cost AVERAGE
  • Time to market AVERAGE

Best when…

  • You have a very small initial investment
  • You need to get live fairly quickly
  • You have a reasonable development team
  • You want medium-term future proofing
  • You want some 3rd party support options

Option Three – Paid for Product


  • Fully Supported
  • Very quick time to market
  • Proven scalability
  • Powerful feature set
  • Consistent experience
  • Dedicated development team
  • Business oriented
  • Skills transferable
  • Migration options


  • License cost (capital cost)


  • Capital cost HIGH
  • Operational cost LOW
  • Time to market LOW

Best when…

  • You have raised a decent amount of initial investment (yourself or via investors)
  • You want to get to market fast
  • You want long-term profitability with low operational cost
  • You want to be long-term future proofed
  • You want the security of dedicated support

So… where to from here?

Ultimately, which option you choose depends very much on where you want to go with your start-up. If you have a great idea you want to develop yourself and time is no consideration, build it yourself. If you are really, really squeezed for initial capital but you can’t take the risk to build it yourself, go Open Source. And if you can raise the capital to do with a paid-for platform up front, you will get to market and profitability far quicker with lower operational costs. In real-world experience, if a start-up is successful then if they chose build-it-yourself or Open Source then they will tend to re-platform within a couple of years to paid-for, and at a significant migration cost. Those start-ups that started with paid-for can just continue making money with their scalable platforms and don’t need to hit that speed bump on their journey. If you can raise the capital, it’s a long term win to start that way.

Here’s a question to finish up. Do you think that an angel investor or venture capitalist will be impressed if you tell them about how you’re going to take ages to get to market because you’re keeping capital costs low? Or do you think they care about fast time to market, quality of platform and operational costs? They have money to place where they think it will be effective, and for them the capital cost is the small part of the picture. If you pick a paid-for platform and partner with them, you already have a team on your side, you have credibility, and you have a product you can be proud of. That makes capital raising for your business a much easier affair. It shows you’re serious, and you’ll find investors are likely to reward your long-term vision.

So your first decision, your platform, does require serious thought. Make a wise decision, and a good one.


May 24, 2013


May 24, 2013 02:53 PM

Explaining the total cost of a project including development hours and maintainance for a couple of years a s o is quite a pedagogical challenge yes. It's pretty funny (and sad) to hear comments like: Why not use XXX CMS, it's for FREE!?
Hmm yes, but since the license cost is about 150 development hours of cost, depending on rate of course, the interesting question will be:
Can you make this website with your "free" cms at the necessary quality, run it and maintain it for 5+ years with decent performance and avoid to spend 150h more in the process?

There is no such thing as a free lunch...

Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog

Identify Azure web app instance id's for an Optimizely CMS site

When running Optimizely CMS in Azure, you will be using an instance bound cloud license. What instances are counted, and how can you check them? Le...

Tomas Hensrud Gulla | Feb 27, 2024 | Syndicated blog

Introducing Image Transformer - AI Assistant for Optimizely

We've got something super cool to share with you, and it's all about giving your images a fresh spin. Image Transformer, the latest feature from ou...

Luc Gosso (MVP) | Feb 26, 2024 | Syndicated blog