How We at Stormotion Maintain Products After Release

The development process includes a lot of stages like pre-project planning, UX prototyping, executing, release and post-release maintenance, etc. Each of these stages implies completing dozens of steps from risk assessment to setting up reporting channels and quality assurance processes.

To learn more about how we establish Project Management for each project individually, you can take a look at this article. Here, we talk about each stage in detail and share some insights from our skillful Project Manager.

In case the client wants to develop the application further, release becomes a recurring checkpoint within a PDCA cycle rather than a single huge update. The changes can be minor and regular. It’s quite common for companies who have reasonable budget distribution and a long-term perspective of their application.

Oftentimes, one of the biggest checkpoints in software development is delivering a Minimum Viable Product (MVP). After the MVP release, companies normally get a much better understanding of clients’ pain points, prepare a post-release roadmap, or even hit a Product-Market Fit.

An MVP is clearly defining the set of features you’d like to implement in the upcoming development stages after validating the business idea. We have an article dedicated to prioritizing features implementation after the MVP release in case you’d like to deepen your understanding of what the next steps can be:

Sometimes, companies don’t get to the point of product release and have to stop the development (temporarily or even permanently). The reasons might be highly diverse:

• Lack of funding.
• Disagreements with inventors or co-founders.
• Reprioritization processes.
• Business model setback & others.

In such cases, we typically complete the development up to the point when there’s a coherent version of the code, finish up merge requests (merging several code branches), and create the documentation so the development can be more easily renewed anytime from that point.

This is called “freezing” a project. It might be needed at any development stage depending on the reason and company needs.

Surely, the release can also be a major product update with a bunch of new functionality — it’s not a rare case. However, the bigger the scope of the release is, the more time you and your Tech Partner would have to spend on fixing technical debt and performing maintenance work.

Now, let’s move to the exact steps that we generally follow when maintaining the application after release. Additionally, we’ll share the details of one of the post-release projects we’ve worked on.

🔄 Post-Release Maintenance Cycle & Our Expertise

Regular post-release maintenance is sort of a cycle with repetitive steps:

• The release of a product version.
• The client collects user feedback.
• Based on the feedback, we formalize new requirements to create a backlog.
• Once there’s enough to improve, we perform development iteration.
• Repeat the same starting from step #1.

Of course, if there’s an urgent request like third-party SDK issues, we immediately start working on the solution. When it comes to routine bugs and crashes, we proactively fix them. To detect the issues, we use analytics tools like Sentry or Firebase Crashlytics.

In case it’s something you’d like to learn more about, feel free to follow the link to the article where we talk about integrating analytics tools into your application:

Also, there’s a whole separate post-release maintenance branch — handling technical debt. In principle, it’s a code “weakness” that occurs when releasing the product or as a result of prioritizing Time-to-Market reduction over code perfection. Normally, it’s not something crucial for the app’s functioning but it can significantly decrease the app’s performance and take up server space.

Even if the app is perfectly built, the technologies gradually get old as new versions of tools, libraries, and frameworks get released. As a rule of thumb, companies should handle technical debt once every 3 months or by necessity.

We have a piece dedicated to handling technical debt where we talk about it using a bunch of examples and exact steps to handling them:

Stormotion’s Expertise

Once a client reached out to us with an already existing application. It was based on WebView, which is a system component that allows displaying content from the web browser directly in the application.

This useful tool has its drawbacks: one of them is poor User Experience (UX) design. The company wanted us to partially rebuild the application so it has native functions.

We needed a couple of sprints to implement all the required features and released the updated version. After the release, we agreed on performing post-release maintenance, which included tracking and fixing crashes.

For that matter, we connected to the client’s Firebase Crashlytics account. The main goal was to increase the number of crash-free users. We were able to reach the point where 99,5% of users stopped experiencing unexpected exits.