- Does the fee model make sense for you? For consumer apps, you likely won’t be able to justify low-code systems that charge per-user fees. Many low-code vendors post their pricing on their websites. For others, you need to call their sales departments. This isn’t the time to be shy: Ask them about pricing, and compare the answers among the vendors you’re checking out.
- Does the low-code/no-code platform support all of your desired deployment targets? If it doesn’t, keep looking. If none of your options support all your desired deployment targets, then consider pruning your target list to the most important devices or browsers.
- Does the low-code/no-code platform fit your developers’ skill sets? Think about building an app with a team, rather than depending on one person (the “unicorn”) to have all the necessary skills. If you don’t have all the skills needed for this tool, keep looking, as another tool might be a better fit for your team. If none of your tool options fit your team’s skills, then you are either looking at training, or hiring, or both.
- Will the low-code/no-code platform improve your development timeline? One of the major selling points of low-code development is shorter time-to-market. If that’s an important consideration for you, then you need to figure out how long it will take to really finish your project. Ask the vendor for a timeline based on your requirements and their historical experience. Ask a contract developer that has used the tool the same question. Be careful to include the documentation and testing phases as well as initial development and final deployment in your time estimates.
- Will the low-code/no-code platform scale? Some low-code solutions introduce bottlenecks that limit how many simultaneous users can run your app; others are engineered to handle very large loads. In some cases, you can work around server-side bottlenecks by running multiple servers behind a load balancer. The vendor should be able to tell you how many users a typical deployment can handle, but for your final deployment you should perform a load test.
- Will the low-code/no-code platform meet your users’ expectations? Consumers expect sub-second responses from your apps, a native look, and a native feel. On a smartphone, one of the behaviors to test is scrolling a long list: Scrolling should be fast when flicked hard, but feel like the list has “momentum,” and slow down before stopping.
- Perform a proof of concept. It’s not enough to learn a low-code product passively during your free evaluation period. Pick a simple subset of what you really want to build, and create a proof-of-concept app. I suggest that you do as much as possible of the POC development in-house; only ask the vendor for help when your own people are stuck.
Performing low-code development is a journey that can lead to many rewards. On the one hand, too many companies insist that their mobile apps must be written in native code, and then are shocked when they spend $1 million and a year on an iOS app and another $500K and six months on a nearly-identical Android app. It’s worth exploring the low-code alternatives, both for the cost savings and the reduction of time-to-market.
On the other hand, too many companies think that low-code development can be performed by business users without any help from professional developers or database administrators, and then are shocked when the project fails. If you avoid both extremes and set clear goals, there’s a good chance that you can put together a team that knows (or learns) how to build low-code apps quickly and well.