Skip to content

What does production code actually look like

There's no magic production ready code, it's a system to answer questions

Posted on:July 28, 2023
5 minutes

Almost as popular as the state management discussion is production-ready code.

The magical code that I’m always asked about. Especially on my YouTube tutorials, “Can you make a production-ready version of this”, to which I always reply, “This is literally the code directly from a production app”.

It’s good to know what it actually means to write production-ready code, that’s what this post will dive into.

There’s no “special production-ready code”, it’s the same as all the other code.

Let’s look at the 6 traits of a production-ready codebase:

Having all these present in your codebase means you know how your app is being used, how stable it is, which features are the most used, and how your app is performing. Let’s dive into each one.

An implemented architecture

I don’t have an architecture that I recommend, only one that I use personally for clients.

I use MVVM simply because it’s the simplest architecture that I know of. The goal of choosing an architecture is to allow you to have an opinion in your code base. Where new files go, how responsibilities are shared, and how to grow the codebase.

In the beginning, not choosing an architecture is perfectly fine, but when in production it helps with guidance on further development.

Tracking Analytics and Usage

If you don’t know how your app is used by your users you don’t have production-ready code.

Your code might be in production, but it’s definitely not ready to be in production. This is an easy-to-implement step, that many overlook, but without it, you shouldn’t be in production. If you are then you should consider implementing analytics.

Add basic analytics, then move on to custom events based on your app use case.

Crash and Stability reporting

Similar to analytics tracking, you need to know the stability of your app, this is a requirement for code to be considered production-ready.

Without this, you cannot know:

Basic crash reporting for uncaught exceptions is a good start. The best is having all exceptions, caught and uncaught, go to reporting. Caught exceptions should be non-fatal, and uncaught exceptions should be fatal.

This allows you to monitor internal code health, answering the question “Are all assumptions we’ve made in code true in the production world?”

The app is released into production

The idea is a bit counter-intuitive, that your app has to be in production to be considered production-ready.

The reason is, you cannot learn what you require to operate effectively in production without being in production. Once the app is released you’ll have the following questions:

Answering these questions is how I determined the traits outlined in this post.

Strict code review guidelines

Once your app is in production you have set a standard, whether it’s low or high, but it’s set.

You now need to adhere to that standard or raise it, consistently. To achieve this you can set strict requirements for your code reviews. Even if you’re a solo developer, holding yourself accountable with a simple checklist is useful. Here are our requirements:

The goal is to ensure you maintain a certain level of code-quality from this point forward.

Your speed of delivery increases over time

This one was a requirement for our projects. I would often allow developers to spend up to 3 weeks just on a refactor, while the rest of the team carries the feature development.

My goal is always long-term, and if yours is too then this should be important. You have to aim for the following:

Writing self-testing code is the answer, but it’s not easy to do. I’m working on a service to help teams take their first step toward long-term speed in 4 weeks or less. If you want to save time on manual testing and avoid long dev cycles reply to this email with a message that you’re interested and I’ll reach out.

If your app is already in production and you have none of these, don’t worry. Each of these is independent of the other so you can dedicate a few days a week to get them all ready.

I hope you enjoyed this post,

See you again next week.

If you want to get these in your inbox, for our newsletter.

Also check out