This is the fourth post in a series where I list steps involved to build your app, from idea to launch. Be sure to check other posts about interviewing customers and preparing the specs, hiring designers and developers and managing the product and the project during the development process. In this post, I will list steps you need to go through before launch when the bulk of features are done and tested, and you are ready to show an early version of your software product to the public.
Staging and production
Up until this step, your app was under development. When development starts you typically set up a development environment where you can see implemented features in action and test them. If you have more than one developer in the team, it makes sense to set up a separate staging environment.
Developers are typically working a local environment, and they need to periodically merge their updates with the main codebase and deploy changes somewhere. It is necessary because there’s a big difference between a code that works locally and the code that works when merged with changes from other developers. Because of constant merging and updating development environment has a lot of bugs and shouldn’t be used for testing. When you have only one developer, it shouldn’t be a problem.
As you are reaching towards the first release, you need to set up the production environment. The production environment is going to be used by the end users so it should have enough resources and its operation should be as smooth as possible. You would want to set up monitoring and error reporting of all components of a production environment — backend, frontend, and mobile apps.
Monitoring allows you to track basic metrics like CPU load, errors, number of requests and response time. Platforms like Heroku include monitoring out of the box, and I highly recommend using them. Otherwise, you will have to pay someone to set up your server and continuously monitor and update it, which is much more expensive than paying Heroku or similar service.
Error reporting is vital to keep track of crashes and errors and debug them. Typically you would use a service like Crashlytics for mobile app error reporting and Airbrake for collecting backend and frontend errors. You can use these services to set up alerts so that you get an email when an error occurs. There will be likely a lot of errors collected by these services in addition to bugs reported by users, so it’s better to prioritize them and ask developers to work only on most critical ones.
One additional thing that is very important to set up is logging on the backend. It's something that is often overlooked. You need to have a log of events happening on the backend that is available when you need it. Backend logs will allow you to debug errors and resolve incidents, finding the root causes of problems. You can use a tool like Sumologic to collect and retain logs.
What to read:
Alpha and beta
You’ve probably heard about alpha and beta versions before. This terminology comes from the early fifties by IBM’s software development department and people involved with it, as Martin Belsky, a manager on some of IBM’s projects claimed. The term ‘alpha’ was used to a version tested internally before public announcement, and ’beta’ was a version announced publicly and tested by the users.
Typically the alpha version is private, and testing is performed internally. To start alpha testing, you need to freeze features in the release to make sure you don’t introduce any new bugs. It doesn't mean that you have to stop the development of new features — typically when you freeze features for release 1.0, you start working on 2.0, while testing and fixing bugs in 1.0. It’s much harder to do if you only have a team of 1-2 people because you are likely to find plenty of bugs and fixing them will take time and energy.
If you don’t have a QA engineer on the team, you will have to perform the alpha testing yourself. You need to perform full testing of the app including all user stories you’ve written down in the very beginning.
Beta version is typically tested in two phases. First, you start a private beta, allowing only people you know and have a good relationship with to test your app. It’s quite different from showing your in-development features to customers to get feedback because you allow people to use the app themselves, not just demonstrating it. After you’re happy with the results of private beta you can start allowing external users to sign up and use your app by starting the public beta testing phase.
It’s important to add support tools like in-app chat via Intercom or ticketing system like Zendesk for bug reporting and providing the feedback as easy as possible for customers. Make sure to manually reach out to your first customers to interview them and offer help.
What to read:
Set up analytics
When you start testing your app with real users, you need to set up analytics to understand how people are using it. Analytics services like Segment, Kissmetrics or Mixpanel allow you to track user actions and then analyze them. To get most out of the analytics, you need to map out user actions you want to monitor and paths you expect users to follow. You can even use services like Hotjar or Fullstory to get heat maps and user session recordings on the web.
Analytics are crucial to understand and fix problems in your app. For example, you can set up a happy path for a todo app — visit the signup screen, complete the sing up, add a todo, check off the todo and log out. You set up events for each of those steps and come back sometime later to check how things are going. When you look at the analytics, you see that from a hundred people who visited the signup screen only five signed up.
Five percent might be a good conversion rate, but maybe you have a problem on your signup screen. By looking into details and user data you can find the problem, for example, your app is not optimized for devices people are using and they don’t see the signup button. Or maybe the form is not being submitted because of a bug that is not visible 95% of the time (including the time when you were testing).
A/B testing allows you to perform small changes in the UI of your app and see how this affects the metrics you are tracking. You can improve the signup screen and see more or fewer people sign up. It will allow you to make a decision based on data instead of guessing what works best. Of course, to perform tests, you need a constant flow of users visiting various screens so that data would have a statistical meaning.
What to read:
If you did a good job interviewing customers in the very beginning and were using their feedback during the development, there’s a big chance you will have early users interacting with your production environment and solving their problems with your app. With monitoring, logging, error reporting, and analytics in place you can track and analyze user behavior and improve both the UI and overall app health and stability over time. You set up this process once and maintain it as long as your app is live, scaling it accordingly when needed.
