Tag Archives: startup

Lessons I learned from building startups

Sysdom isn’t my first startup, it isn’t even my second, but comes some way down the list at 3 or 4 (or 8 or 9 depending on whether you want to count startups that I didn’t have equity in). In that time I have made mistakes (oh so many mistakes), but I have learned from them and tend to make completely new mistakes the next time around. 😉

I will try to distil some of that hard learned knowledge into a something that others can learn from so they don’t have to make the same mistakes I have.

Happiness is everything

If you aren’t happy going to work then you really shouldn’t be doing this. You will work harder for something you enjoy and unhappiness will spread to colleagues and customers. In the end it will make or break the business.

Everything has a cost

While you might not value your time during the initial stages of building your new enterprise, your time does have a cost. Any time that you spend reinventing the wheel or building solutions to a problem that can be solved cheaply by using an outside service or product is time that you are not concentrating on your core product.

Everything has a value

Any time you are building solutions to problems you are creating value. While it might be difficult to turn this value into money (ie. by productising it) it quite often can be used to build reputation or build attention for you and your business.


If you don’t have a vision or aim, then you are essentially just randomly hitting keys and hoping to come up with the complete works of Shakespeare – it is unlikely to happen. Start with a problem that vexes you regularly then solve that problem. It is quite probable that other people face the same problem regularly too.

Never take outside money

Taking other peoples money is never a good idea for a small startup. It gives them a massive lever in the direction of the business and often results in the business going in a way that you dislike. Result? You end up getting dissatisfied with the business and work suffers.

Don’t give away equity

Giving away shares in your business should be one of the last resorts. It can mean that employees will work harder, that investors may bring in expertise to assist in the growth of the business, but unless done right it will mean huge risk and little benefit.


If you aren’t breaking new ground then you are really just building a ‘me too’ product. This isn’t always a problem, but makes it hard to differentiate yourself in a market filled with clone products. Innovation is key: make it simpler, faster or do something no other product does.

Pivot and think laterally

Inside almost any solution is the key to solving an even bigger problem. Build a good solution and you often have other products that can be brought to market with minimal effort.

Be Lean

Even if you do have cash available, you don’t have to spend it. Do you really need that flashy usb coffee cup warmer? That £800 office chair when a £100 will do? The same goes for infrastructure. Why buy a £5k server when you can build using cloud servers (Rackspace Cloud and Amazon Web Services for example) at a fraction of the price and gain redundancy to boot. Yes, it will be hard, but these challenges will make you face up to the real problem – that of bringing in customers and cashflow.

Fail fast

If the problem isn’t really a problem or your solution doesn’t adequately solve it then don’t be afraid of quitting before you sink too many resources into it and move onto the next problem.

Don’t quit at the first hurdle

If you find a problem that you can’t solve initially, don’t quit. Other people will be facing the same issue and a solution will mean you have an advantage over them. This doesn’t mean you should sink resources into something that is unlikely to be able to recoup them – fail fast in this case.


You are unlikely to get it right first time. Build a product then improve it one problem at a time. Sometimes it will look nothing like how the original concept was envisioned – this is fine and normal.


Metrics and logs should be an integral part of everything you build. If you can’t measure it you can’t improve it. Web logs are a good start, but alone don’t tell you much besides who is visiting and how many times they have visited. You also need to know how many resources you are spending on servicing each visitor.

Low barrier to entry will mean many competitors

If the solution is easy, then many people will build one and compete with you. For example, there are many projects cloning 37signal’s Basecamp product or bringing basic telephony services to market based on the open source asterisk project. If the problem is harder, then you will have less competitors and will be be able to price your product higher.

Find your niche

Your niche should be somewhere where you can dominate, where few competitors exist and you can grow unhindered. For example, applications for pig farmers – there are a lot of them around the world…

Some competitors will always race you to the bottom

Racing your competitors to the bottom is generally a losing race for everyone involved. Without the cashflow to innovate and support your product, your service will suffer and your product will likely stagnate. Charge a fair price, explain what your customers are paying for and point out why a lower cost solution isn’t suitable. 37Signals have been releasing uptime and customer happiness metrics for just this reason.

Stop doing things that don’t get you towards your goals

If it doesn’t get you closer to your goals then it isn’t worth spending your time on. Stop doing it, or at the very least outsource it.

You aren’t perfect

It is unlikely you will have all the skills required on your own. Don’t be afraid of buying in talent to bolster your skill-set.

I hope that this has been interesting and please do leave any additional lessons in the comments below.

Case Study: Optimising a Cloud Application

I was recently brought in to examine the infrastructure of a small startup. This wasn’t anything really special, I do it quite often for various reasons. What was different was that they didn’t have issues with scaling out particularly – they had that working well with their shared nothing web application and mongodb backend. What they were having issues with was their infrastructure costs.

I normally work on through a 6 step process that has been built up over time –

  1. Monitor and gather stats/measure the problem,
  2. Standardise on a reference architecture,
  3. Add configuration management and version control,
  4. Start to define a playbook of how to do things (like up/downscale or provision new machines and clusters) and start to automate them,
  5. Bring everything to reference architecture/consolidate underutilised servers and eliminate unused infrastructure,
  6. Consider architecture changes to make it more efficient.
  7. …and repeat

I will take you through a case study showing how this process was used to lower their monthly costs. Names and details have been changed in places to protect the guilty… 😉 Continue reading