The

Big

6

Users, Nonfunctional Requirements, Pricing, Support, Governance, Features

There are 6 key things to take into consideration when evaluating no-code vendors.

1. User base

The most important consideration when choosing a platform is who will be developing apps on that platform. According to research and advisory firm Forrester, there are two major platform segments, one designed for use by professional developers and the other designed for business people, or citizen developers. Forrester research indicates that professional developers will reject platforms for citizen developers as too simplistic, and business people will find platforms for pro-developers too hard to use.


There can be some overlap, but according to VP and principal analyst John Rymer who wrote The Forrester Wave™: Low-Code Development Platforms for AD&D Pros (and The Forrester New Wave™: Low-Code Platforms for Business Developers), Q4 2017 there is (so far) no single platform that equally caters to professional developers and business developers.


Neither focus is better than the other, it just depends on whether your bigger problem is that you don’t have enough developers, or that traditional development takes too long -- and your platform choice should reflect this.


As a no-code platform ourselves, our outlook is that the not-so-distant future will start to see platforms that can be equally useful to both professional developers and business users. We believe in the possibility to build a platform that can support the complex functions that appeal to hardcore programmers, while also enabling anyone to build applications regardless of programming skill. But that’s a discussion for another day.

2. The -ilities

Nonfunctional requirements, also called the “-ilities”, include usability, maintainability, scalability, availability, extensibility, portability, and security (because there’s always that one guy…). Together they contribute to the quality of platform performance. You likely have different requirements for each of these, and some may be more of a priority than others based on your needs.


Think about what those needs are (more on that later), and how the different nonfunctional requirements fit in. Are you a healthcare or government organization dealing with sensitive data? You’ll likely be more concerned about security than a large enterprise organization who prioritizes scalability to be able to accommodate company-wide usage.


In any case, consider the following questions when asking about the nonfunctional requirements of no- and low-code platforms:


  • How do users rate the ease-of-use and startup experience?
  • How easy is it to maintain and make changes to applications built on the platform?
  • How much specialized knowledge is needed to maintain?
  • How much scalability does the platform support?
  • What percentage performance down time can you expect?
  • Does scheduled platform maintenance result in down time?
  • What kind of extensions does the platform support?
  • Can data from the platform be migrated to other systems?
  • Is the platform hosted on-premise or in the cloud? What type of installation does this require?

3. What about pricing?

Different vendors calculate their pricing models in different ways, and not all platforms are priced along the same guidelines. Some platforms price according to the complexity of the app you build, while others calculate price per end user. This makes a huge difference in your bottom line.


For example, let’s take the same enterprise project approval or expense reporting app that will support 5600 users. On a platform that does pricing based on the number of components needed to build the app, it would cost about $12,000/year. On a different platform with a pricing model based on the number of users, the same app would cost 10 times more, over $100,000/year.


That’s why you should always ask about a platform’s pricing structure, including hidden additional license fees and other potential changes in pricing after the first year of use.

4. Support

As with any software, you’ll want to consider the available tech and product support. Are there online forums and documentation available? What about live support and trainings? Are these free or paid? Documentation and video tutorials are pretty standard, but some vendors offer paid support packages with custom training, and others have online certification courses and other resources.

5. Governance

How do you govern development with no- and low-code platforms? It would be shortsighted to simply treat a platform as ready out-of-the-box solution. Challenges will arise if you don’t take steps to address the larger organizational changes that come with implementing such a system.


One of these risks is shadow IT, or unsanctioned, unmonitored applications running without IT’s knowledge. That’s why a no-code platform should support transparency and sanctioning by an organization’s IT department. IT should be able to have an overview of all apps being built on the platform so that they can effectively govern its use. A platform should support your processes of setting up projects, monitoring progress, and collaboration.

6. Features

There are a variety of available features across the spectrum of low-code and no-code options. NLP, machine learning, and IoT functionalities including the ability to incorporate real-time sensor data are among the flashier innovations on the market today.


Some platforms also feature reusability of components as a unique selling point. With this functionality, developers can build a component (like an API integration, for example) save it, and then reuse it again in other areas of the application without having to re-develop it. Some platforms even make this feature available across multiple applications and shareable among different users.


But how do you know which features are really matter to your case? Always keep in mind the problems or processes you want to fix, and ask yourself if the features of a platform will help you solve those problems. If a feature doesn’t help you solve your problem, then it’s not needed.