Stage 5

“Don’t let perfect be the enemy of good”

Classic software development methodologies sometimes overfocus on managing risk and uncertainty, leading to many additional steps in development and QA on the quest to strive for perfection. If you’re building software to power a rocket ship that flies to the moon, this is completely understandable! It can take years to ensure the software’s completeness and perfection. However, in the business world, the pressure to avoid disruption (think Uber, Netflix, etc.) demands greater speed and requires the ability to release apps and features swiftly so that you can respond to competitors or innovate your business processes faster. This demands a focus on meeting the needs of the business and maintaining a fast pace. Your initial release should focus on key capabilities that can be deployed quickly to enable the business to move forward. Perfection can be achieved in later stages following the everyday delivery approach that we will describe later.

No-code development helps meet these pressing challenges by accelerating the development of both the initial release and enabling rapid and continual updates. The Prototype to MVP stage starts by focusing on the rapid delivery of the initial Go-Live release, which was defined by the prior Project Assignment stage.

No-code Feature Development Approach

We continue following the philosophy that we will leverage the no-code visual tools as much as possible. This means that the MVP design steps will be performed visually inside the no-code platform (as opposed to making specifications in separate design docs). Unlike traditional software development, we aren’t starting from scratch. First, no-code platforms provide a significant amount of the underlying infrastructure. This allows you to focus on the business functionality that you want to build, rather than worrying about building technical and application frameworks. You also accelerate the process by “inheriting” the working prototype that was built during the earlier Design and Prototyping stage. We start by extending the available prototype, which allows us to save a lot of time and minimize the risks of misalignment.

Another benefit of working from a prototype is that needed features can typically be built almost immediately and incrementally on top of the existing app prototype, allowing you to avoid lengthy delays waiting for a reviewable version of the app. As new micro use cases are added, you can usually publish the working prototype for quick review and feedback. This enables a much more immediate and continuous feedback cycle throughout the building process.

MVP Structure

What is included in the no-code feature development? Similar to before — during the prototyping phase — it will typically focus on these key areas:


The basic UX will have been established by the prototype but will now be extended by adding individual features/micro use cases. This will add more depth and completeness (by adding forms or screens needed to complete a full process) and desired usability enhancements (e.g., streamlining the user flow throughout the application by combining steps or automating the population of fields). It will also add additional business rules and validation logic needed for the MVP. Finally, the UX will also likely undergo some form of brand/UX review and may require updates to ensure consistency with overall corporate standards. Also, during the earlier prototype stage, we mentioned that data models should not be in focus. However, at this stage, it’s time to establish the right data structure and the necessary dependencies between the objects.

Workflows and business logic

You will extend the business processes (both human and system processes) that were defined in your prototype by adding more detail around subprocesses and tasks. This will also typically introduce more nuances around “edge” conditions and process variations that might be suggested by different departments or business units. Error conditions must also be anticipated to handle cases where there are failures or process exceptions. Allow these to be handled gracefully.


During prototyping, the internal systems that needed to be integrated with the no-code app are often “stubbed” for simplicity but, in this phase, the actual integrations will be introduced. If data is accessible in systems with preexisting connectors or modern APIs, this may be simply a no-code configuration. Often, however, this may require some participation by software engineers as part of either a fusion team or perhaps sourced through a Center of Excellence.

Dashboards and analytics

At this point, you need to extend the dashboards and reports you’ve built in the prototype so that they include real data and cover key aspects that are needed to analyze the performance of the business use case. Keep your focus on adding key dashboards with defined success criteria to the MVP as this helps streamline the adoption of the app, specifically by the leadership team.

Keep in mind that while the no-code tools will be used to define the core of the no-code application, they may be integrated with other components of the solution that you identified during the Options Analysis stage (e.g., with either packaged application functionality or with custom-developed components). This will introduce the need to use other development tools as part of a fusion team approach. However, always remember that the goal is to utilize no-code capabilities wherever it’s possible. Professional software development tools should be used only in cases when no-code development cannot be applied.

Kanban progress tracking

The ability to break down larger functionality into a stream of small features/micro use cases is powerful but, to be successful, it requires a deliberate approach to manage the flow of work effectively. We recommend a Kanban approach, which we believe is optimally suited for no-code development. Kanban is one of the common flavors of modern Agile software development, but its origins trace back to advances in lean manufacturing pioneered by Toyota in the late 1940s. It is a “just-in-time” approach to managing complex workflows. There are a lot of primers on Kanban available for review. We don’t want to spend time duplicating these guides, but we do want to make sure you understand one of Kanban’s core practices: The use of visual boards that breakdown work into a set of “cards” and “columns” (e.g., requested, in-progress, done). This is a highly visual approach to managing and tracking work items that allows the development team to pull work from a defined backlog (to-do list) and easily track and communicate updates. Kanban also provides both the development team and key business stakeholders with visibility into the scope and progress at any time, which facilitates collaboration and discussion about priorities.

Many software development teams may be familiar with Scrum (a type of Agile methodology). However, we recommend Kanban over Scrum for no-code development for the following reasons:

  • Kanban builds a continuous “push” delivery model where teams release value as soon as they are ready, while Scrum organizes work in Sprints and defined Release Trains.

  • Kanban also offers the flexibility to use the method on top of existing workflows, systems, and processes without disrupting what is already in place. Scrum can require adopting a nontrivial number of new systems and processes, which can be overwhelming for a business-led no-code development.

  • Finally, Kanban minimizes the need for practical experience and specialist roles (e.g., Scrum master, product owner), which also makes it easier and faster to adopt by business teams.

Software development cycles (If needed for a fusion team model)

We keep emphasizing that you should be focusing on using no-code tools to fully exploit the power of the platform. Using no-code tools wherever possible drives greater productivity and lowers the total cost of support and maintenance. You’ll want to revert to custom development only when you have specific needs that call for the fusion team model. Don’t forget, the Application Matrix will have identified your appropriate delivery mode type. You may have included software engineers on your team (as part of a fusion team delivery model) or you may seek software engineer support from a No-code CoE. Depending on the size of the custom software components, this may dictate some of the processes that the software engineers may follow. For small development scenarios, it may be easiest to simply have them join the cadence of the no-code team and use the Kanban Method outlined earlier. For larger software development projects, the software engineers may identify the need to follow other traditional software development methods, such as Scrum, to manage their work before it gets integrated into the no-code app.

Scope and change management

As you further build MVP features, it’s common to continue to elaborate on lower levels of depth of use cases and identify additional requirements (based upon the feedback techniques that we’ll discuss in the next chapter). However, while it’s good to be responsive and agile, you must also be disciplined throughout this process of managing scope and applying change management practices. Clearly identify and track new feature requests as they are identified and maintain a focus on deciding whether they are in for the MVP.

Here are suggested criteria for deciding which features should be included in the MVP:

  • Timeline. In the prior stage, you have established the timeline for the MVP and allocated resources accordingly. It’s recommended to adopt a timeboxed approach for hitting this date. As you identify and elaborate scope items that could possibly exceed an expected MVP timeframe, the no-code team should reprioritize the defined scope and target fewer features and shorter time-to-market.

  • Business value. The end users should be able to start using the MVP capabilities and receive the expected business value as outlined by the business use case. Any newly identified features that are not critical to supporting these business outcomes should be deferred to the backlog for future consideration.

  • Crystal clarity of the use case. The ability to execute is important, and the MVP should include only those capabilities that are fully aligned, clarified, and don’t require additional research and approval. Vague and not fully confirmed requirements should be taken out of scope and deferred to the backlog until they are clarified or matured.

The most important criterion in the no-code development process is “aggressive” decision-making and prioritization processes during the MVP scope. If wrong decisions are made or incorrect prioritization is allowed, the MVP release timeline could possibly be extended to months, dramatically increasing opportunity cost. When you are working on the scope, it’s critical to focus on the capabilities that can be released within days or weeks to deliver value to the business. So, while analyzing each feature, the no-code team should be asking themselves the following question: Can the business get value without it?

If the answer is “yes,” then consider it out of the scope for the MVP release and move it into the backlog for later consideration. The team should also focus first on features that are easy to implement relative to the business value they provide. Prioritize features that are low-cost to implement and provide high business value.

Software testing

Testing is important to ensure the quality of software, but the approach to your testing methodology does change a bit with no-code. Traditional software testing methods anticipate that many software defects can be introduced during the low-level coding process and set quality gates and validation steps to identify and remove them. Defects will certainly still need to be removed from a no-code app, but the abstraction layer of the no-code platform tends to provide guardrails that help prevent you from making lower-level technical defects.

During the current Prototype-to-MVP your focus should be on testing end-to-end scenarios that validate the end-user features and user journeys to be delivered in the app. Depending upon the number and complexity of the integrations, you may also need to invest time in API testing, especially for newly created data exchanges. Note that the user acceptance test is important but not in scope during this stage. It will be covered later as part of the “First Release” discussion.

What happens to unit testing? Well, in no-code, traditional unit testing activities are not typically needed. Unit tests are short program fragments that are written and maintained by the developers that exercise some narrow part of the product’s source code and check the results. The outcome of the unit test either passes or fails. Developers will typically write many unit tests to cover the application modules or features, grouped into an overall test suite. This can require a significant amount of development effort but is a key part of maintaining the quality of a custom app. In no-code, however, there are few (if any) original “units” of code. Instead, each of the smaller components of the app is usually a prebuilt unit that is supplied by the no-code platform and assembled into higher-level functional components (e.g., forms, workflows, etc.). This allows teams to put focus on validating business rules and end-to-end user scenarios rather than having to unit test for minute defects that were accidentally introduced during coding.

Likewise, technical infrastructure and environment testing are also abstracted away from the application developer. You do not need to worry about running these test scenarios because once the no-code platform is established, it typically hides all the infrastructure and most of the environmental configurations away from the developer.

Finally, one last difference in no-code testing is that it tends to also be performed more incrementally, rather than waiting until the entire MVP is complete. You don’t defer the end-to-end testing to the very last minute. No-code encourages conducting scenario testing as soon as they are ready to be validated. This doesn’t eliminate the amount of testing, but it often allows you to spot defects earlier in the process.

Final Takeaways

This was a lot to cover, but “don’t lose the forest for the trees.” The most important thing to take away is to stay focused on releasing the MVP as quickly as possible. It doesn’t have to be perfect — it shouldn’t be because the quest to find perfection will distract you from the core mission. Instead, it would help if you embraced the power and speed of no-code platforms — take advantage of them by adopting an efficient, lean, and iterative approach that fully uses its unique strengths in accelerating development. Speed is essential to keeping up with the demands of the business, and a no-code platform can help you address these needs.

Now, concurrent with the MVP development discussed in this chapter, you should also be collecting feedback. We’ll explore this parallel activity in the next chapter.