Taking Your App from V1 to V2: Planning for the Initial Launch & Future Iterations

When building a custom application for your medtech company, it’s important to budget for not only the initial build of the application, but also future iterations. 

Good application development is never a “one and done” type of engagement–future iterations will always be needed to keep up with evolving technology and business needs. If you are strategic in planning the necessary features for the initial launch of the app vs. features that can be included in later iterations, you can get your application off the ground while planning and budgeting for the future.

Prioritizing the necessary features for Version 1 (V1) of an application is a conversation we often have with our customers. Here, we’ll share our advice for planning out V1 of your application and future iterations.

1. Start with only a core set of necessary features for V1.

The first step in planning for V1 vs. V2 of your application is recognizing that you don’t have to cram all of the features into the first release. There are, of course, some core features that the application has to have to make it worthwhile, but there are probably some options that can wait. Sometimes, it’s better to start with the basics, and then add on as you’ve had time to use the application and understand where additional features truly make sense.

For example, when we were building the Online Product Catalog for our client, the client had both short-term and long-term goals. Initially, the client only needed the capability to provide an online catalog of their products to customers. With that, they needed some basic features to have the catalog work online, including the ability to feed product information into the catalog, an admin area to manage information, the ability to search for products based on certain criteria, and the ability to save or share product information via email, print, or PDF.

Yes, there were additional features that they ultimately wanted to have, but these were the core items that were needed to make the catalog functional and useful to the end user in its initial release.

2. For V1, tie the output of the application to key business objectives to prove value.

If key stakeholders in your company don’t see the value of the application in its initial release, you may not be able to get funding for future versions. For that reason, it’s important to make sure that the features you include in V1 directly address the business’s need for the application.

With the Online Product Catalog, our client’s problem was that they previously only had a printed or PDF version of their catalog. That system created a lot of extra work for sales people and for customers, who had to do more work to find the products they needed in a non-digital system. Also, static catalogs can get outdated very quickly as products change. With the online catalog, our client was able to ensure that all customers had access to an up-to-date catalog at all times, and also that they didn’t have to flip through pages and pages of a static catalog to find the products they needed to place an order.

When you make the sales process more efficient and make it easier for customers to find what they need to place orders, that ultimately helps the company’s bottom line. When planning for your company’s application, look for those opportunities to prove the value of what you are building from the start so that you can continue getting funding for future iterations.

3. Save the “nice to have” features for V2.

There are always more things you can add onto an app as time goes on. In our opinion, application development is never really “done.” Whether you need to upgrade from a technology standpoint to keep up with the latest standards, or you have ideas on how to improve the app, there is always more to be done as time goes on.

There will always be a point in the initial development process where someone says “Wouldn’t it be cool if it could do x…?” However, you shouldn’t let that pull you off track from building a really great base for the app that you can build upon later. If a suggested feature is a good idea, but isn’t necessary to hit your business objectives, it might be better to save it for V2.

For the Online Product Catalog, that meant saving features like product comparison, direct product-code search, and the ability to search for product kits based on their components for V2 of the catalog. While these features would definitely be helpful to users of the catalog, they were not necessary components to have the catalog function well in its first iteration.

4. When planning for V1, it’s still important to have a vision of where you want to go for future iterations.

When we were building the Online Product Catalog, our client wanted the catalog to eventually be capable of facilitating online purchases. However, they were not ready to initiate a full ecommerce service when we were initially building the application. 

Even though the client wouldn’t likely need ecommerce capabilities for years down the road, it was still helpful information to know as we were building the app. Building it on an ecommerce-capable platform would make it much easier for the client to switch over to that functionality down the road, compared to if it had been built without ecommerce in mind.

This is why it’s a good idea to not only have an idea of what you might want your application to look like now, but also how you might want it to evolve in the future. While you may not be able to anticipate every future need your company might have, planning ahead as much as you can will help your developers choose the right technology and platforms to facilitate both your current and future needs.

5. Get feedback from the people who are actually using the application.

When the team developing the application is not the end user for the application, it’s easy to let inferred behavior and incorrect assumptions influence the final product. And if that final product doesn’t end up meeting the needs or expectations of your end users, you may be building something that creates more work for people, rather than less.

Ideally, you should get feedback on your plan from the intended user of the application as you are planning for V1. If that couldn’t or didn’t happen, you should definitely solicit feedback before you move on to V2. This gives you an opportunity to course-correct and add features that users will actually find helpful. After all, if your intended user doesn’t actually use the app, you’ve spent a lot of time and money on something that doesn’t improve your business or customer experience.

All of this is to say, there are several things you should consider when planning for custom application development. Be sure you are making those considerations before making any key decisions on how to move forward. We’ve seen medtech companies who only thought about the “now” of the app and not the future, and have ended up with something that can’t scale with them. We hope to help your company avoid the same fate.