Introduction to Go-Live

The Go-Live Phase begins the actual development of your no-code app. Part of the power of no-code is that it abstracts you away from a lot of the low-level details of traditional software development, which allows for a greater ability to step back and focus on what matters — releasing the MVP app to your users as quickly as possible!

So, we’re going to start with the basics. In this primer, we’ll introduce the key concepts and provide important context about the approach as well as tips and best practices to navigate you through this phase. The following chapters will then dive into more specific details on each of the individual No-code Lifecycle stages. Keep in mind that the stages we’ll outline include what is relevant to mission-critical enterprise applications. However, the steps may be streamlined significantly if your apps are not complex. Please remember to use the Application Matrix to assess the level of complexity of your apps. In most cases, especially when the applications don’t include critical requirements, Go-Live should happen in days or weeks (not months or quarters).

1. Let’s start, however, by taking a fresh look at the no-code development specifics and discussing how they vary from traditional development at this stage of the cycle. First, in no-code, the business function acts as a direct participant in the development itself, rather than simply being an external stakeholder specifying requirements to the developers. The common software development methods tend to focus primarily on software developer roles and don’t consider business personas as being direct participants in the team (or even contemplate the fact that the business function might be a developer). In contrast, the business function sits directly in the driver’s seat in no-code projects — authoring the requirements and driving the design activities. The business function will also play the lead role (and often the sole role) in the development by placing no-code creators and no-code architects directly onto the team itself. When the business function plays a larger role, you typically have greater direct knowledge and understanding of the business domain seeded into the development itself. This often results in improved efficiency and accelerates the creation of differentiating intellectual property. It also increases the overall speed of getting your no-code application live and into the hands of end-users.

2. Secondly, no-code offers a unique opportunity to gather user input much earlier in the process. In traditional development projects, you often must wait for user feedback until the end of a sprint or until you have a functioning application, which can be fairly late in the development process (perhaps during user acceptance testing). This often results in delays because you may receive key feedback late in the project and spend time reworking functionality or adding missing features. In contrast, with no-code development, you can capture user feedback early and iteratively (as you will nearly always have a working app, even at the start of the project), providing the ability to incrementally course correct and accelerate your progress.

3. Finally, there tends to be more fluid movement between ideation/design/build activities because of the inherent power and ease of collaboration with visual no-code tools (the idea or design becomes the app itself, not simply a throwaway documentation artifact). This typically results in a more effective rapid collaboration between the no-code team and the business stakeholder. It also means that the feedback you collect from end users during the building process doesn’t have to be put into a future backlog that may not receive attention for weeks or months later. Rather, your no-code teams can often take the input they received during daily/weekly feedback sessions and address it the same day. Note that scope management is still important, and you need to ensure you’re applying the same criteria for defining the MVP as discussed in Chapter 10. You can often address smaller feedback relevant to the MVP almost immediately.

Let’s start to examine in more detail what a Go-Live Phase actually looks like. As with the Design Phase, this is composed of four key activities. Each of these will be described more fully in the following chapters, but let’s briefly discuss the essential stages:

Stage 5 Prototype-to-MVP

This begins the process of building the MVP functionality defined in the prior stage. We will continue the philosophy that we should use the no-code visual tools to perform as much of the work as possible. This means that throughout the design and building of the MVP app, the activity will continue to be captured visually inside the no-code platform (as opposed to making specifications in separate design documents). This results in a very efficient, lean, and iterative approach. At this stage, you are taking the loose prototypes defined in prior stages and fully fleshing them out so that they fulfill their intended purpose. The result is a completed solution. This may include completing the data model, workflows, and all the required user forms as well as building any required reports, etc.

We will manage the process using Kanban as an Agile methodology. This allows you to visually track and manage the flow of work through a series of development stages. Unlike frameworks, such as Scrum, Kanban can be layered incrementally on top of your team or processes. It also allows you more flexibility to release updates when they are ready vs. having to adhere to strict sprint or release planning structures that take a fair amount of training and experience to get right. Finally, we’ll discuss the important topic of software testing, which should also be adapted and streamlined because the no-code environment abstracts much of the traditional need for unit or infrastructure tests and allows the quality focus to stay at the business and user requirements level.

The no-code creators will take on a significant lead role as the building begins. These creators will primarily come directly from the business group (function or unit) that has chartered the application or from the business analytics group. For more complex projects (as assessed using the Application Matrix) that involve a fusion team delivery model, software engineers may be integrated into the project as well.

Stage 6 Feedback Loop

As discussed earlier, we’ll walk through how to capture feedback throughout the development process using an approach to continuous feedback. This will build on the earlier feedback you captured during the Design and Prototyping stages, but the feedback becomes more specific and focused on the current release use cases as the focus is shifting from broad design thinking to a more concentrated view for the MVP. We’ll also discuss how to select the right stakeholders to give feedback, the right frequency of feedback, and how to efficiently approach change management of user feedback.

Stage 7 Governance Checks

This is a critical step of the review process to ensure your app has successfully passed the applicable checklists and is ready for production release. This typically includes reviewing the following:

1. External compliance checklists to assess compliance with external laws, guidelines, or regulations imposed by government institutions, industries, and organizations.

2. Internal compliance checklists imposed by internal audit teams or committees to enforce adherence to rules, regulations, and practices as defined by internal policies and access controls.

3. Security checklists to protect your corporate information resources from external or internal attacks.

4. Data governance checks to assess how sensitive corporate data is managed and secured.

Stage 8 First Release

This last stage is where the application is released to production to end users. The release process is typically straightforward in modern no-code platforms — they adopt the “continuous deployment” philosophy and use automation to deploy features quickly and seamlessly across environments in an on-demand fashion. However, there will be variations in the number and type of environments as well as in the specific steps of the continuous deployment workflow. The scale and complexity of the release will be driven by the Application Matrix, which helps define the appropriate level of sophistication needed. Finally, there are associated operational/support readiness activities and end-user onboarding/enablement activities that will be needed for the first release of the application.

This is a lot to cover, but we’ll step through each of these stages in the following chapters, and offer guidance, examples, and practical tips that can be used along the way.