The Ultimate Guide to Choosing a No Code Platform to Build an App

Introduction

‍The no-code landscape has changed dramatically in recent years, providing users with a plethora of options when it comes to choosing a platform to develop an app. We’ve developed a framework that we ourselves use when embarking on a new project:

Clarify what the end-product should look like
List the features you need and want (but separate them!)
Build your tech stack options based on how well they address the core features and fit the end-product use cases from steps 1 and 2
Define your budget and, based on the features you need and the tools in your tech stack, figure out which pricing plans you will need and if they align with your budget

Before exploring this further, let’s clarify a few things. Firstly, how quickly your app is developed depends on the skill level of the person building it, their familiarity with the tools required to produce the app, and the complexity of the app. If you hire a no-code developer to build a simple app using tools they are familiar with, you can expect a fully functional app in as soon as a few weeks or up to a couple of months, assuming they have the bandwidth. If you attempt to build a complex app yourself despite having no experience with the tools required to build the app, it may take you several months to get a basic functioning version that is usable. That said, there is nothing wrong with learning on your own - after all, that’s the benefit of using no-code/low-code tools! However, the worst thing you can do is make assumptions about your project without taking the time to understand its complexity, scope, or best practices. If you decide to take on a project by yourself, ensure you are dedicating enough time to learn how to put your best foot forward with the tools of your choosing.

Clarify the end product

Clarifying your end-product is relatively simple. First think through how you want yourself and/or others to be able to use your app. Will it be a mobile app (i.e., available to download as a native app), a progressive web app (PWA), or web app? Will it be available to the public or not? What pages and screens will your app have? In other words, begin with the end in mind. Trying to figure out what you want your app to look like or do while you are building it is not an impossible task, but makes organizing your thoughts and making important decisions difficult if you are new to development.

Try designing basic wireframes and having basic workflows in mind before going into development.

Anatomy of an app

Regardless, your app will have a front-end and back-end. The front-end is straightforward: it’s the interface available to users to interact with. The back-end, however, is more ambiguous. At Keymaker, we like to split up the back-end into two components: database and authentication. Yes, there are more ways to compartmentalize the back-end which you will learn with experience, but for now let’s stick with the most critical parts. So, there are essentially 3 components for any app: front-end, database, and authentication. Your front-end includes the visual components your users can interact with, the database includes the data for your app (e.g., for a social media app, this could include all posts you have liked), and authentication includes user data and the mechanism by which users can sign up or log in to your app.

Use cases and features

Use cases

Now that we know the anatomy of an app and have defined what you want to build, we can go into the ‘what’ of your app you are trying to build.

By ‘use cases’, we care less about specific features and more about what your use case is and how a particular platform can support it. For example, Softr is a common front-end builder that people will use to connect with their existing Google Sheets or Airtable data to better visualize or display data. However, you are better off using a different tool, such as Bubble, if you want to build a marketplace. Some tools are more specialized for different use cases and others, and each have their own pros and cons.

Most apps we’ve seen in the no/low-code world can fit into one of the buckets below. Please note that the example companies are just examples of the software in that category and is not an indication of the tools used to build them.

marketplace (medium): e.g., Airbnb, Etsy
e-commerce (medium): e.g., Walmart
SaaS/software-as-a-service (difficult): e.g., OpenAI’s ChatGPT
CRM (medium): e.g., HubSpot
internal management system (medium): e.g., Notion
AI/ChatGPT wrapper (medium): your friend’s ‘AI startup’ idea
custom widgets for a website (easy): e.g., custom Google Form
directory or querying tool (easy): e.g., Yelp
client portal or dashboards (medium): e.g., data visualization using Excel or Tableau

Some apps you may know fall into multiple buckets. For example, Amazon is an e-commerce marketplace.

The more complex an app or its use case is, the more likely you’ll need to invest in a more robust no-code tool. For example, if I wanted a simple landing page with a custom booking form, I could use a lightweight and specialized tool such as Tally or Calendly and embed it as a widget on my existing widget. On the other end, if I wanted to create a booking form template that other businesses can use themselves, I am now in SaaS CRM territory. Consequently, your use case and desired features will have a direct impact on the tools available to you for your intentions.

Features

Now that you know what your use case and app anatomy will be, it’s time to think through your features. For example, let’s say that fictional character “Mark” wants to build an internal management system for his team. He wants to have a page to view current projects, another page to store sensitive documents, and a profile page that contains sensitive personal information such as bank details to receive his paycheck. How should he proceed?

Because he reads Keymaker’s blog, Mark gets to work. First, he defines that the app should only be available to employees at his company and accessible via a website (web app). Next, Mark thinks through how users should be able to interact with the app and what features he wants in it, including the pages, the data the app should collect and display, any integrations the app should have with his company’s existing software, and how to ensure the app is secure for employees to use and protects their data. Mark goes to his boss with his plan and asks for a budget, and his boss thinks that it’s a great idea and grants a budget of $100 per month for the costs to maintain the app. His boss also tells him that if the app is successful, the app may be used company-wide - which means that it will be handed over to the company’s software development team. Now Mark must evaluate which tools are available to him to build his app.

Now that you have fleshed out what you want to build and what you want your app to accomplish, it’s time to build your tech stack. Each tool is unique and has its perks and flaws. Bearing that in mind, every no/low-code tech stack sits in one of two camps: monolith or modular. The monolithic approach means picking a single tool that satisfies all the requirements of your app, and the modular approach means using multiple tools that work together satisfy all the requirements of your app.

“Why would I use multiple tools if there are monolithic tools that I can build an entire app with?” Fair point. But allow me to make an analogy to illustrate my point: let’s say that you want to go on a road trip. In theory, you can take any type of vehicle on a road trip, including a motorcycle! However, what you bring with you and the vehicle you choose is likely based on the type of trip you want to have. If you want to go fast with little to no need for comfort, take a motorcycle and spend each night at a hostel. If you want to take your comforts with you, you can take an RV. If you want to have more flexibility, you can take an SUV and plan stays at different hotels or Airbnbs. The point is, the sky is the limit, and your tools should be reflective of what app you want to build and how you want to build it. Just like you can’t take an RV off-roading, you might not want an all-in-one platform to handle niche features. It is entirely up to you.

Let’s return to Mark, who is putting together his tech stack for the new internal management system he is developing for his team at work. After getting approval from his boss to build the app, Mark then takes his requirements and budget constraint into consideration as he surveys the no-code landscape. After doing his research, Mark initially has 2 potential tech stacks: Bubble and WeWeb + Supabase. He likes how flexible Bubble is for a single tool, and that it satisfies most of his requirements. However, he decides to go with WeWeb + Supabase because he recalls his boss saying that he may need to hand the app off to the company’s engineering team, and Bubble would not make it possible to export the app as code.

Other considerations

Like we mentioned earlier, there are a lot of potential variables that come into question when building an app. Here are some of the most common considerations the team at Keymaker takes into account when embarking on a new project:

Integrations: the integrations necessary for the app to work and how they integrate with the app (e.g., plugin/extension, API call, third-party automation software)
Support: the quality of documentation and support for using specific software/tools required to build the app a certain way or implement specific features
Vendor lock-in: the difficulty of migrating from a particular platform (e.g., no code export, few competitors)
Flexibility: the ability of a tool to add new or modify existing features
Scalability: ensuring that your app can support X users or X automations without breaking by using best practices while understanding the technical limitations of your desired tech stack (e.g., using Airtable as the database provider for a marketplace is not advisable)

Conclusion

It is always best to build with the end in mind, because, at the end of the day, software is a tool, and a tool is only as effective as its wielder. If you are left with questions, please get in touch with us and we’ll be happy to help answer what we can or point you in the direction of more helpful resources. Happy building!