Stage 8
First Release

Congratulations! You’ve passed the governance checks, and you’re ready to deploy the initial MVP release of your no-code app! You’re almost done, but don’t forget some of the most essential final considerations. You moved fast and have almost completed the journey of building your first app, so don’t stumble at the final stage. Taking these final measures to prepare for release will help set up your app for success and ensure it makes a good first impression with your users.

The stages we covered in the No-code Lifecycle have ensured the application has met all of the stakeholder, user, and governance requirements. However, there are still some final steps to prepare the business function to use the application, including the following:

• Documentation and application guides

• Deployment

• Validating environments

• Final user acceptance

• Support and monitoring

• User onboarding and enablement

Documentation and application guides

Documentation and application guides can vary widely depending upon the complexity of the application. For a simple app, it may be enough to have a walkthrough guide for a first-time user, whereas for a business-critical enterprise application, you may need full-blown documentation that fully describes all features, functions, and operations. Also, consider that you may want to put more user support and online documentation into the app itself through in-app guides, hints, tips, and walkthroughs to support the user navigation. If the app is simple and intuitive with support for users as they get going, they may not need to heavily rely on traditional external documentation.

It’s worth noting that the building of documentation is often started late during traditional custom software development as the teams may not have access to working software until late in the development cycle. In contrast, with no-code development, there are early “working” versions of the app even during the prototyping stage. While the app will progressively evolve over time, you can begin planning the development of needed content even at the early stages of the lifecycle.

Deployment

With modern software development, there has been a trend toward more complete automation (referred to as “continuous deployment”) of the deployment activities to take manual steps and points of error out of the equation. Most no-code platforms depend on continuous deployment approaches as part of their automation (this set of functionalities is often called Application Lifecycle Management or ALM) to allow for more rapidly moving no-code applications through environments. When an operator needs to move a no-code app to production, this usually involves nothing more than approval and a click of a button.

However, moving an app into production still must be performed with care and in concert with appropriate validation steps. Deployment should be released from quality assurance/pre-production to production environment only after the final acceptance testing has been performed. Then, following the release to production, it’s important to still verify the solution changes operate as expected before significant users or customers are onboarded.

Preparing and verifying environments

Until now, most of the focus has been on development or QA activities as you’ve largely been working in a small number of nonproduction environments. But it’s important to carefully plan out your needs regarding the types and numbers of environments you will need ongoing so that you can respond to change. Once the full set of environments is provisioned, you’ll need to test and verify that the environments are ready.

Typically, you may have several of the following environments provisioned, although the exact number and configuration will vary based upon the application complexity.

Sandbox (SANDBOX)

This is an environment used for quick experiments and demos that won’t affect the work of other developers on the team. The sandbox can be used for early ideation and prototyping before the MVP release officially starts.

Development (DEV)

This is where the primary development for the current MVP release is performed. You may have multiple teams depending on the size of the application but, ideally, they are still all working in the same environment.

Quality assurance (QA)

As feature development is completed, it may be moved into a separate QA environment to allow for more detailed and controlled testing (e.g., integration or system testing).

Staging/preproduction (PREPROD)

Once testing has been completed, the app will often be moved into a controlled staging environment that closely mirrors production. Staging will mimic similar volumes of data, and system resources will be sized to mimic production response times. This is often used for final performance simulation and user acceptance testing.

Production (PROD)

This is the actual production environment, where end users will directly be onboarded and use the live application.

You should use the Application Matrix as a general guide to determine which (and how many) of the environments may be required:

• “Simple” apps may only need two environments (DEV and PROD). With simple complexity apps, you might use a single environment for both building and testing and then deploy it into production when you are ready for Go-Live.

• “Medium” and “Advanced” apps typically represent more business-critical applications and may require additional environments (e.g., multiple QA environments to support parallel releases to be tested at once, a PREPROD production mirror). Having more environments adds some incremental complexity, but it also allows for more flexibility in testing — you can conduct final UAT, smoke testing, and regression testing in controlled environments before being released without impacting the development underway. It also allows fixes to be made rapidly in PREPROD and released without having to worry about the accidental release of work-in-progress changes.

Final user acceptance

As discussed earlier in the feedback loop chapter, users should be involved throughout the process to supply continuous feedback. Incorporating user feedback along the way makes the final end user approval a less scary event (e.g., will it fail to reach signoff?) and ensures that most of the buy-in and alignment has happened along the way. However, final user acceptance and stakeholder approval should still be attained prior to the release. Consider this a final check to make sure that the no-code stakeholder and business function are indeed ready for the app to go live. Note that this is especially important when the Application Matrix has assessed business complexity as “medium” or “high.”

The focus of the final user acceptance should be to validate the highest-level business requirements (as defined in the business use case) and obtain approval to release. This is not meant to be a substitute for lower-level functional or user testing, which should have been validated during the prior Feedback Loop stage. This will help eliminate issues resulting from data or environmental inconsistencies.

Be very careful to manage expectations on feedback gathered during this final user acceptance effort. The primary focus is to validate that the app is ready for deployment in production, not to gather more feedback on possible enhancements or improvements. If any critical “release blocker” defects are identified, it may be necessary to hold the release so that they can be fixed. However, at this point, the bar should be very high for accepting any new requests. It’s essential to triage the feedback and only accept the most critical items at this late stage. Everything else goes to the post-MVP backlog and will be addressed as part of the continuous improvement cycle.

Support and monitoring

Your organization will typically adopt Information Technology Infrastructure Library (ITIL) and IT Service Management (ITSM) methods and practices as the overall model to provide support for the application. However, depending on the level of application complexity, your organization might be leveraging all 10 processes of ITSM or just have one part (i.e., an individual providing ongoing help for simple apps). Monitoring is a form of proactive support where an organization can set up a relevant process to monitor critical indicators of the application’s health to respond to events in real-time. Such indicators may include time to execute critical actions, the opening of pages, and other triggers.

Note that, unlike custom development, no-code platforms should abstract the individual app teams away from having to manage the health and operations of the underlying platform infrastructure. This would include things such as maintaining a disaster recovery plan, performing backups of system data, ensuring service redundancy, monitoring loads, and stress testing. This is critical at the no-code platform level and will likely be supported by IT working closely in concert with the no-code vendor. However, the individual no-code teams should not have to perform these activities for each app that is built on the no-code platform.

User onboarding & enablement

Once a new no-code app is deployed, you’re ready to give users access to the app! Some of the user setups may be done automatically, for example, existing employees or customers can just log in and go. In other cases, users may need to take some action the first time they use the application. However, even if user onboarding is mostly automatic, you may want to control the pace of bringing new users to the new system. Consider whether phased or staged onboarding is needed to give the business function time to gradually adjust to using the new solution. If a phased approach is desired, you can break up deployment by region or team, for example. If some remaining defects exist in the no-code app, having a controlled onboarding ramp allows for easier fixing of initial issues before significant numbers of users are live on the new app.

Even if the software is working perfectly, process or operational changes may be needed. For example, you may learn from the earlier users that enhancements to training or procedure documents will help them be more effective in their daily use of the no-code app.

Support teams may not be fully ready to handle the volume of inquiries about using the new application. Giving them an initial period of light usage can help with training and ramping up knowledge about the new app.

As end users are onboarded, there is also usually some associated enablement activity required to support effective adoption. Besides traditional training and enablement techniques, it is recommended to adopt a model of continuously retraining the users based on the “Everyday Delivery” approach (more frequent smaller enablement is more effective with an app that is frequently being updated). It won’t be needed to set up training every time when new functionality gets deployed. It will depend on the size and the impact of the change. However, for frequently changing apps we would suggest setting up regular monthly “what’s new” reviews. Also, it is suggested to use certifications and testing to confirm their ability to fully utilize the system specifically for complex enterprise-grade apps.