Starting a new app? Deploy it to production first

When you start a new project, the temptation is always to get the code scaffolded and to get hacking away. I'm going to argue that you should deploy your non working application to production straight away.

The walking skeleton

I first came across this phrase when I worked at a small development house. Despite the company only being small (5 employees, all were devs), they delivered and maintained a large number of line of business applications for some well known clients.

There were multiple reasons behind this success. One of the major reasons was the fact that all new projects had to be deployed into their production environments in an automated fashion before any real development work started.

This approach has a few advantages:

1. It deals with any deployment pain early on.

This includes setting up DNS records and build pipelines. It exposes any limitations in the deployment plan early on. It also forces you to resolve problems like production database migration, early on.

2. It fosters an environment of early feedback with the end client.

This is one of the cornerstones of agile development. Rather than waiting until we think we're approaching a finished state with the project before tackling the deployment pipeline, having it done first makes it the first class citizen that it needs to be

3. Crucially, it proves any technology choices that we have made early on.

More on this point later...

In this context, the skeleton is our barebones project with very little in it, and no real business logic. The idea of it "walking" refers to it being deployed to production in an automated fashion, and with a production config.

Proving technology choices

The world of web development suffers from an enormous amount of technology churn. It feels like every day there is a new framework, runtime or module bundler.

When we want to use a new technology, we need to prove that it can run in our production environment, and with a production config. "It works on my machine" isn't something we can tell our paying customers.

The importance of the production config

When we run web applications in production, we typically remove all debugging code, and we bundle and minify our code. We need to prove that our technology stack is capable of delivering a production ready site to our end client.

An unsuitable production config

A few years back, I was working on a team that was looking into starting a new Angular project. At the time the Angular documentation favoured TypeScript, but stated that JavaScript could be used. As the team felt they were strong JavaScript developers and were relatively unfamiliar with TypeScript, their preference was to continue writing JavaScript.

As performance was a key metric for that project, one of the first things we did was scaffold the project, and run the distribution build just to test the bundle sizes, and to get a feel for how it ran in the browser. We did not want to spend months building out a project only to find that the in browser performance had got worse with a supposedly superior technology.

We were glad we did - we discovered that the empty JavaScript version of the application shipped 800Kb of JavaScript to the browser, whereas the TypeScript version shipped around 140Kb. The treeshaking in the JavaScript version simply did not work. It was a non starter, and we were very happy we found this our early on. We posted our findings on StackOverflow.

Conclusion

Get to production early, even if your app isn't ready. You'll catch critical issues early.