Startup Mistakes: Over Engineering Your Tech Stack

Software developers like myself have a deep passion for creating new technology. Us engineers loves to obsess over a problem and become consumed by it until it is complete. Although this can lead to exceptionally well-tested code with many features, this passion is sometimes at odds with the needs of the startup. In particular, revenue and customer acquisition can take a backseat. This is an extremely common pattern, which I have seen at many startups, including those that I have co-founded or been an early employee at. As a former CTO, I have fallen into this trap myself. Hence I feel obliged to inform other startup founders of the danger of putting technology ahead of the customer.

Once you have successfully validated your product/market with initial research you need to get the minimum feature set out the door as quickly as possible. The reason is clear - you want to see whether people are actually willing to part with real cash for the service you are offering. If you aren't able to get 10 paying customers for your product then how do you expect to get 100,000? More to the point, why are you building a stack designed to handle 100,000 customers if you haven't even got 10?

An awesome (but overthought) tech stack

Let's take the example of a typical web application. You will generally need a database, an app server and a capability to serve static content. You might want a load balancer in there as well to spread traffic over multiple boxes. You will also need to store your codebase in version control, will need a continuous integration system and a testing system. You will need a local development environment and a remote staging environment that closesly mimics the production system. If you are running a social app, you might also need a lot of email to be sent - hence an email server.

In summary, we have a load balancer in front of two reverse proxy/media servers (scaleabe horizontally) which pass all dynamic requests back to two app servers (also scaleable horizontally) attached to a master-master replicated RDBMS (again on two separate machines). We have a separate box for the Agile tools and a separate machine for delivering email. All of the key systems need to be duplicated for a staging environment as well (another large box, virtualised). This leads us to 10 separate machines.

There is absolutely nothing wrong with this setup - if you have the customer revenue to pay for it and the demand to warrant it! If these were all on separate dedicated machines then you would not get much change out of $1500 per month at most hosting firms. To put that in perspective, in order to keep your entire stack alive and break even you would need 60 regular paying customers each forking over $25 per month. I can't imagine 60 customers would require such an over-engineered stack, so why waste money that you probably don't have at this stage?

What you should be building

There is nothing wrong with designing an architecture to scale, but that does not mean that is has to BE scaled from the outset. All of the above components could happily live on a medium to large server that is fully virtualised. Applications such as Xen allow this sort of stack to remain on one physical computer. Services such as Amazon EC2 also allow for on-demand scaling - perfect for the horizontal application described above.

If your application has minimal media to serve (just the website base images, CSS and JS files) then a VPS is a perfect solution. Slicehost has a 1GB slice which costs $70 per month, has 40Gb of space and 600Gb bandwidth to play with. This could easily handle an application designed to test out customer sentiment with a few beta users and still provide all of your agile toolset needs. In fact, for some applications, you could probably get away with far less.

If you need to serve a vast amount of media, then consider an EC2 node with some Elastic Block Storage (EBS) points. These are permananent drives suited for long term storage, unlike the EC2 instances themselves which (unless EBS-backed) will lose all data upon shutdown. You can add EBS points rapidly, as well as back them up in a straightforward manner. EBS points can also be mounted to separate machines (although not at the same time!) allowing you to switch storage between instances.

Every systems architecture is different, so your mileage may vary, but the one consistency among them is that if nobody is using your application, then there is no need for it to scale. Remember that customer needs lead the application design and hence the engineering architecture - not the other way around!