When your company spots a need for a new application they look to you lead the charge. Time is of the essence and often an all-hands-on-deck approach is favored to avoid a missed opportunity. Perhaps the big idea will drive immediate revenue or solve a critical customer challenge. But when they decide they need a new application, they might make the mistake of planning to design and build the initial version of the application without taking into consideration the long-term work required to make the application a success.

However, the continuing success of the application requires early planning and diligent ongoing work.  This should not be overlooked. Following the five application strategy guidelines provided in this article will minimize the probability of failure of your otherwise well designed and engineered application.

1) Plan for post-launch during the initial project planning

When creating the project plan, don’t stop with the launch date. Consider things that might need to take place after the launch: collecting and reviewing user feedback, addressing post-launch bugs if they arise (let’s not kid ourselves… they always do), and ongoing maintenance tasks. Create the project plans with these tasks in mind, and ensure you are reserving resources to complete them. If you are transitioning the team post-launch, have team members overlap during the project. This creates a shared familiarity with the application, eliminating any gaps as team members ramp on and off of the project.

2) Implement a phased approach for feature releases to maximize the potential of a successful launch

Up until a few years ago, most software projects utilized the waterfall methodology. Teams would pack as many features as possible into the initial software release to create a feature-complete first version. While in theory, this provides the biggest value to users, it can jeopardize the quality assurance and inundate support teams with an overwhelming volume of user feedback in the post-launch period. Since most, if not all, of the application is developed prior to receiving feedback from real users in the application, this approach also lacks opportunities to course-correct along the way.

Conversely, a phased launch and roll-out of functionality facilitates a focused and methodical support of a smaller set of features. Consider the ill-fated Healthcare.gov launch as opposed to Oregon’s healthcare exchange launch. Oregon’s approach was to release only a limited amount of functionality on launch day, and phase in additional features over the coming weeks. The result was initial reports of 34 issues, only two of which were critical. The team was able to focus on the two critical issues immediately, without overwhelming media scrutiny and visitor traffic.

Another approach is to plan for a limited audience release. Confining your initial launch to a small portion of the target audience grants time to flesh out issues with a smaller group of users, limits negative exposure, and provides a more controlled environment for releasing rapid updates.  It can also create added anticipation and excitement for other members of the target audience who may be aware of the pending product launch.

3) Expect requirements to change once the application is launched, even with the best planning

Change is inevitable. It is in the nature of the business.  Any software that serves an evolving business will likely face a similar fate. Even the best-planned software project cannot account for all unexpected requirements changes that develop during the project. The moment the project is launched, there will likely be a backlog of changes that need to be implemented.

To be prepared for this you’ll want to resource team members in advance. Depending on the size of your project, you may only need a subset of the original team. Ensure that the team composition is able to process the feedback and execute it all the way through deployment. This may mean that you’ll need a product manager, UX designer, UI designer, Engineer, and QA analyst on standby.

4) Create a cadence for ongoing maintenance and support work

The impact of requirements and changes are usually unique to individual businesses. There are, however, some more universal and predictable external factors that will require ongoing maintenance work. In particular, elements of your tech stack will need to be routinely updated. These updates may also require application modifications. For example, mobile operating systems are notorious for imposing new limitations on apps over time. Product owners are wise to plan in advance for the time of the year when Apple releases the next iOS version (version penetration on Android devices is significantly slower, following a less predictable cycle). Keep an eye on the iOS beta release schedule, and assign resources to test your apps in the new OS versions as they are released.

Even worse, an end-of-life development framework or CMS could require a larger application overhaul. For example, thousands of Drupal 7 and 8 websites and applications had to be reworked in recent years as those versions of Drupal were relegated to the software graveyard at that time.

Security patches are critical as well. A regular patch schedule works well for many application owners. Depending on the specific needs of your application, a monthly or a quarterly patch schedule may work. Keep in mind that critical patches should be applied outside of the regular patch schedule. Be prepared to have resources available to tackle those patches as needed.

Fortunately, browser updates are of lesser concern these days, but we still see the occasional breaking change from a browser release. These can be difficult to plan for due to the number of browsers in the marketplace, but being vigilant and having a team on the ready can help mitigate any issues that may arise. Browser support for Progressive Web Apps (PWAs) changes more frequently, so you’ll need to stay more apprised of browser developments if you maintain a PWA.

5) Look at the total cost of ownership over the first 24-36 months of the application life

It may feel daunting to budget for all these possible post-launch workstreams. One way to plan for the long-term success of an application is to examine and budget for the total cost of ownership per year as opposed to the initial project cost. Divide the calendar for the time leading up to project launch and the time after project launch. Once the application has launched, who needs to be available? What is required of their time? Are there any hard costs that you can account for now? Annualize these costs to obtain the total cost of ownership per year. Being aware of this cost and having these funds allocated is a significant step toward the long-term success of your application.

Supporting your application from launch through sunset

It’s easy to look at an application project as everything leading up to project launch, but the long-term success of an application is often determined by what happens in the period following the initial launch. By following the guidelines presented in this article you will create cadences and systems that successfully support your application from launch all the way until sunset. If you are ready for your next application project, also read how to build digital product platforms for scale.