Building to Scale

· 299 words · 2 minute read

Building to scale is a popular term in the software development world, especially in tech startups. The normal usage is the idea that you should build your software, computer infrastructure, and business in such a way that you can grow to be the size of Facebook. Usually this means extremely complex architectures, “planet-scale” infrastructure, extremely complex build and deployment systems. All processes much be automated and zero touch.

Yesterday I was having a conversation with a colleague about Quill and he brought up very valid concerns about future problems we will run into. Things like vetting of uploaded content for copyright violations, particularly works in the public domain. There are features that authors want and that will be necessary to compete with companies like Amazon or even SmashWords.

I want to reiterate that his concerns are valid, just as the scaling concerns in the traditional building to scale mindset are valid. Those are absolutely problems that will need to be addressed. I have historically been just as liable to accept those things as now requirements, which pushes back release dates indefinitely in a slow death March of motivation and viability. It seems to me that the important thing for me to remember is that they will need to be addressed.

What if instead of building in order to scale, we just built at our current scale. Right now we don’t need to worry about large scale copyright violations. We don’t need to worry about 10-9 availability and constant green-blue deployments with hyper-resilient data storage. We can probably run on a single server when we actually release to the public, and hand review each item.

Instead let’s build something where we are, put out something people use, and then add what people need. Seems like a winning strategy to me.

Got thoughts? Share them by email.