“No code survives first contact with the users” -Gen. George Patton
If you have, or are considering, launching a web app, you know that your most critical measure of success is engagement — what percentage of visitors to the platform become users. How can you tell the difference between low engagement and high error rates without robust error reporting? At Radial, we have launched dozens of web apps, and through experience we have developed standard practices so we aren’t caught flat-footed on launch day.
In The Lean Startup, Eric Reis suggests that a product can be launched with very little development required. You can start by gauging customer interest through a simple landing page. From this, a small demo can be put together rapidly and put in front of potential users as feature sets are iteratively built and deployed. Reis’s primary point is that your visitors – users – provide your company with the blueprint for developing your product. This is a great strategy; but it can be completely derailed by some easily-avoidable missteps.
Early in my career, launching a new product or app involved days or weeks of fumbling and tweaking just to get an app that worked fine on my development machine working properly on the production server. After launch? Silence. Was anyone actually visiting the site? Had some unknown bug prevented users from signing up? If there was a traffic spike, did the server handle it, and if the server didn’t, how would we know, and what would we do?
From our experience of launching dozens of apps here at Radial, we have developed some standards for production-ready apps. This checklist doesn’t take much time to implement at the start of development but will save a world of headache later on and ensure that you have critical metrics for your business.
12 factor apps
From the start, we follow the 12 factor app pattern as our set of best practices. This helps to make the application portable (it runs on both development machines and production servers) and scalable (can handle unexpected bursts of traffic).
Separate production keys and storage infrastructure
We provision separate infrastructure (like AWS S3 storage) for production at the same time as we provision it for staging — helping to keep configurations in sync but enabling us to limit access to live data. Separation of development and production infrastructure is important — preventing accidents and security incidents.
It’s never too soon to turn on automated database backups. User data is your most critical asset, and should be secured from both system malfunction and external attack.
A critical step in web security is always using HTTPS (HTTP over SSL). Thanks to LetsEncrypt, this can now be done for free!
The most commonly attacked secure data is user passwords. Passwords should never be stored as plaintext, but instead are stored as a “hash,” or a sort of fingerprint for the password. Changing this method of hashing a password after users have begun using your app is exceptionally difficult. At Radial, we always use modern secure algorithms from the start.
At Radial, we like Test Driven Development a lot. But at the very least, your app should have some integration tests that provide a sanity check that the most critical features keep working.
Continuous deployment and deploy pipelines
Deploying new code should be a frictionless as possible–you never want a critical bug fix to be waiting on a specific sequence of clicks and you always want a quick way to rollback to a working state. We like to use Heroku for infrastructure because it provides these features. We also like to use Circle CI to automatically run tests before code is deployed so that we don’t accidentally deploy a broken app.
Services such as Rollbar, Scout, or Sentry capture application errors and provide a handy interface to keep track of them. Don’t wait for your users to report errors (they probably can’t tell you enough information to fix it anyway).
Simple tracking code from Google or Hotjar is enough to get detailed statistics on how many users are on your site and what parts are being interacted with. This is critical feedback for your business and provides a sanity check that, yup, the site is still up.