• Modern Javascript stack
  • Use the best tools there are
  • Leverage from open source components
  • Use nosql databases for flexibility
  • Full stack
  • Test driven development

Common startup problems

This page discusses some of the common pitfalls for startups, which can often be a factor in their lack of success.

Be embarrassed

There is a famous quote by Reid Hoffman, the founder of LinkedIn, which really resonates with some entrepreneurs:

If you are not embarrassed by the first version of your product, you’ve launched too late.

So allow yourself to be embarrassed, it’s actually a good thing, and hey, your next version will be better.

Not failing fast

Your startup idea may be great, but what ends up making it a success may be a little different or a lot different.

A key part of the Agile methodology is to fail fast. What this means is, learn from mistakes quickly. Failing fast means measuring results, and continuously adapting until the results are better. It means listening to your customers, making changes to try things in different ways until you hit the mother lode. Instead of being a gold miner, you might end up making shovels or gold pans, and having a steady, profitable business.

Building a platform

Do you need to build your own “platform” or app? These days there are plenty of tools that will do a percentage of what you need, add some manual effort, and you have a means of transacting business. This is a good way for you to start operating, and learning what your customers need and want (did I say that these things are different?). Tesla (and a lot of successful companies target customers wants, and even aim to cultivate those wants further (for their own good, of course)

I would recommend that any startup delay the building of a platform until they have exhausted the capabilities of these low-code systems, and it begins to hurt.


It starts with something like:

Let’s go serverless, and build micro-services

and you could substitute many other technologies in there, whatever the flavour of the month is. Now your chosen technology is cool, I mean really cool, but we shouldn’t let the technology drive the business.

Doing something like micro-services isn’t trivial. In theory each microservice is standalone, and can be developed and maintained independently of everything else. It sounds great, the ability to maintain and update simple pieces of code without the need to release the whole system. You probably do need to run integration and end to end testing though.

Decoupling adds work. When services are decoupled, you need to allow for the asynchronicity of them, and the fact that they may be unavailable (for whatever reason). This usually means introducing some kind of queueing system, and writing orchestration code to manage that.

It’s quite possible that the additional effort in this queueing and orchestration outweighs the benefit of isolation of features that micro-services bring.

Scaling too early

Scaling too early is related to over-engineering. Engineers worry about getting to the kind of scale that Facebook and Google have, so want to architect systems for that ultimate scale. This level of scalable engineering is not cheap, and will change the way you write your code, making it a slower process to develop it (and increasing costs and time to market)

If you are learning lessons along the way, the product you start building, and the final product version are likely to be quite different. Heavy duty engineering hinders adaptation, if you have a “throw-away” prototype, you will let it go easily. The second or third re-write is when you get it right.