Mar 17, 2022
Strengths and Weaknesses of Low-Code/No-Code Tools
There are a lot of different low-code/no-code options out there. Understanding their strengths and weaknesses will help you pick the right tool for the job and balance their sometimes significant weaknesses with their tremendously valuable strengths.
By: Alex Allain, CTO and Co-Founder at USDR
As USDR celebrates our two year anniversary, we’re pulling back the curtain and showcasing some of the techniques we use to scale USDR and help our partners serve their communities.
Last week, we launched our series on how USDR has used low-code/no-code tools internally as well as with our partners. Here, the strengths and weaknesses of these tools are examined and how we’ve seen them used best.
Strengths of low-code/no-code tools
The primary strength of low-code/no-code tools is that you can spin up new solutions very quickly at low cost. At USDR, we’ve been able to build entire rental assistance applications and backend processing workflows in a (very intense) week.
These tools also make adding features quite quick. USDR’s Poll Worker Management tool is built on Airtable, which allows us to implement new features in a matter of days. One county requested a helpdesk feature for poll workers to submit election day questions in a centrally managed fashion, and we were able to add it over a weekend. It proved quite helpful on election day. Polling site leads (Judges of Election) could fill out a form that submitted questions directly to Airtable, rather than calling an election hotline that was usually busy. County elections staff watched Airtable for new questions, and they were able to instantly get the details of the question, know the precinct and location for that person, track who was working to answer the question, and see the notes and final response to make answering similar questions easier. After the election, they were able to look at the questions in a single location and discuss changes to make the next election better.
Low-code/no-code tools also empower non-engineers to modify solutions to their needs without having to bring in high priced consultants or take up scarce IT team members’ time.
In one project, USDR’s government partners built out a sophisticated set of email automations on top of Airtable–all based on a handful of examples we’d originally put together. Usually picking up these tools requires someone with reasonable technical literacy, but they don’t need a computer science degree or even any programming experience at all. If you’ve ever used formulas in Excel, you can probably pick up these tools.
Empowering teams close to the work makes up for many of the challenges of low-code tools (which we’ll get to shortly). One reason software development is hard is because the people writing the code aren’t the people using the software, leading to core requirements getting lost in translation.With low-code/no-code tools, it’s more likely that the solution built will work for the people using it.
It’s important to note, however, that traditional project management questions that get at the deeper “why” remain relevant. We’ve seen situations where our government partners got ahead of themselves in building something without thinking through how it would fit together with the larger system. This can lead to point solutions that don’t fit together, so you’re constantly playing whack-a-mole with one solved problem leading to another issue. Low code tools aren’t a substitute for thinking carefully about the problem.
Related to this idea of eliminating translation issues, low-code tools make prototyping exceptionally easy. We have had a lot of success eliminating misalignments or confusion about requirements by throwing together a quick Airtable demo and getting it into the hands of end users and decision makers to understand if we’re on the right track. Recently, we worked with one state looking to run a public comment process. By putting together a demo of what was possible with Airtable, it helped them understand exactly what was possible with minimal infrastructure overhead and also made a lot of abstract concepts of data management clear to them. This helped them understand that a complex, custom (and expensive) database was not necessary.
Low-code/no-code tools also empower teams by stripping away much of the operational work associated with traditional software development. Specifically, you don’t need to worry about hosting and maintaining a backend server, or thinking about infrastructure level security or reliability issues (e.g. keeping your system patched). This means the focus is on the mission, where it should be, not technical minutiae.
That being said, there are still resource limits in each tool that you can run into, and traditional planning-for-failure thinking is valuable.When we first built the internal infrastructure for USDR, we had to be very careful about not running out of tasks from Zapier, lest our volunteer management automations fail in the middle of a surge of volunteer sign-ups (Zapier does now have an automatic task upgrade feature in beta to address this). Similarly, you still have to think about low frequency errors. What happens if your JotForm submission doesn’t get sent over to Power Automate properly? While rare, at the scale most governments are working at, these issues can arise and you want to have some way to check for them, even if it’s just a manual scan every once in a while.
We’ve also found that it’s possible to start from a totally no code environment (e.g. building workflows on top of Airtable as a backend) and then migrate to a more codeful environment where you build out pieces of an application that need more software while maintaining other parts using low-code/no-code tools. For example, our Neighbor Express app has a web-based frontend with an Airtable-backed CMS, but the backend matching volunteers to assignments is handled entirely in Airtable’s native UI. Similarly, our tools for finding and reporting on grants started life as Airtable databases before we decided to move them to a fully codeful solution as it became more clear what the scope of work was.
Finally, the best tool to use is one you can actually get access to, and in many cases you will already have access to some or all of the tools you need. For example, Microsoft Power Automate is available to anyone for free (and the free plan has been sufficient for all our projects). Many of the other tools we prefer to use cost only a few tens of dollars per month for a single user (here are the pricing pages for Airtable, JotForm, Cognito Forms and Zapier). Notably, Airtable charges only for editors, not for readers, which means that even if an office needs many people to access data, the cost may still be relatively low.
Challenges of low-code/no-code tools
While we strongly believe that the benefits of a low code setup frequently outweigh building something from scratch, low-code/no-code solutions are not a panacea for all software challenges, and in some cases create new challenges that must be managed. Again, all of the observations below are based on the tools we have used (and may not apply to all tools in the category).
Because these tools generally have ready-built integrations, you get what you get in terms of which apps you can easily interoperate with. In general, we’ve found that the Microsoft toolchain has limited integration with the Google suite, and vice versa. This often means a fundamental choice in the design of a low code solution is whether to use Power Automate or Zapier as your integration hub, and the choice is based on which suite you use. The reason this matters is that you should make sure your preferred tools have the integrations you need before assuming you can link them together. There are some exceptions: Zapier, for example, has generic webhooks support that can be used to interface with apps that don’t have native Zapier integration, but this is more of a power feature that goes beyond what the average non-developer can handle.
The most significant and frustrating disadvantage of the low-code/no-code tools we’ve used is that the versioning, testing, and deployment story is often weak. For example, there is no easy way to create a template for an Airtable base, check it into GitHub, run a set of unit tests on it, etc. If you want to avoid making changes to a live production instance in almost all of the tools, you have to create a separate copy, make your edits there, test them manually, then re-apply them to the live code. This is tedious, manual and brittle. The saving grace is that most low-code/no-code solutions have implementations that are not nearly as complex as pure software, so it’s not as important to be able to run a suite of automated tests. That being said, this is a real, painful weakness.
A second disadvantage of the low code tools we’ve used is that the limits they impose are often either low levels of scale or opaque. Airtable bases can only store 50K records on the Pro plan or 100K records on the Enterprise plan, and Zapier plans get quite expensive as you go up to 10s or 100s of thousands of tasks. As of this publication, the most expensive Zapier plan on their pricing page, which provides 2M tasks, costs $3599/month or almost 43K/year. However, most solutions we’ve built require only a few thousand tasks at a cost of $50-$100/month and sometimes even cheaper. Tools like Microsoft Power Automate do not have these low limits; however, their underlying constraints are complex and can be difficult to understand. At USDR, we have never hit them, even when doing load testing, but it’s difficult to analytically assess when they might be hit.
Taken together, we think that low-code/no-code solutions are generally great when you have scale on the order of thousands of records or lower (as might be the case for many locally run programs), but if you anticipate hundreds of thousands of records, these solutions become more brittle and are likely not appropriate for the long term. The tens-of-thousands of records scenario is a bit of a gray area. It can work, but you’ll start to hit some of the reliability and scale issues mentioned above unless you take some care to avoid them. Having a good way to double check that errors that happen one in ten thousand times don’t cause someone to slip through the cracks becomes more important.
These limits are from our experience with specific tools. The entire category of low-code/no-code tools contains enough specific tools that some may be more (or less) appropriate at higher scale levels.
Even in cases of high scale, low-code/no-code tools can still be useful as an interim solution that teaches you what kind of workflows are appropriate. As referenced earlier, our grant management tools began life as a set of Airtable bases and were later converted into a more standard software stack as we proved the needs and our understanding of the problem space.
Another issue is that even though low-code/no-code tools can support more sophisticated code integrations, they’re often a bit of an afterthought and suffer from the same versioning issues discussed earlier. Notably, because your code needs to live within the context of the application (e.g. if you are adding JavaScript to a Zapier action or writing a JavaScript automation in Airtable) it doesn’t live in a git repository, yet the cost of not being able to test and version the code is much higher because even small amounts of code can get pretty complex.
Finally, governments aren’t always the target customers of these tools, which means, for example, tools like Airtable and JotForm are not FedRAMPed. On the other hand, tools such as Power Automate, do have US Government plans. This means that some of these tools may not be available at the federal level or in other jurisdictions that require FedRAMP authorization.
Where we think low-code/no-code shines and struggles
There are a number of common government scenarios where we think low-code/no-code tools really shine:
- Form building: We see little reason for someone to re-invent form building — the tools that are out there seem to work well enough for most projects. JotForm and Cognito Forms are both powerful, and you can create both forms and screeners.
- Case management: Tracking cases that go through a common set of workflows can work great in a tool like Airtable.
- Matching resources to resource providers (e.g. volunteers to volunteering opportunities) works well — it’s easy to build backend workflows on top of Airtable.
There are also some scales of projects that we think work best for low-code/no-code tools–and conversely, where they don’t.
- Shines: We’ve found that the tools we use work well with a scale of 1000s up to (low) 10000s of entities.
- Struggles: Beyond that scale you start to hit issues both with the scalability of the apps we are talking about (e.g. Airtable Pro has a 50K record limit) as well as hitting the risk of running into errors even for systems with 99.99% reliability.
- Shines: Low-code/no-code solutions are typically best when they are the “leaf” nodes of a system, rather than when they are the central hub upon which multiple other systems rely. Usually, we look for ways to bring low-code/no-code tools in to complement existing systems. That said, USDR’s data layer is built almost entirely on Airtable, and it works well. The level of integration required is high, however, and may not be appropriate for projects that need higher scale.
- Struggles: Building a more foundational system is most appropriate for teams with high technical ability (such as software engineers who can evaluate long-term architectural tradeoffs), and will likely require a move toward more code over time for interoperability across systems.
Choosing the Right Tool to Fit Your Needs
As you can see, there’s a lot to consider when choosing the right tool for your needs. We hope this detailed examination of these tools gives you a good understanding of where they could fit into your workflows.
Next up, we’ll be examining how you can select and work with these tools and our suggestions on approaching these tools with technical teams and security.
Need a refresher on low-code/no-code tools? Check out our first post in this series.
If you are a government partner looking for support, please reach out to us here. We’ve worked with these tools on engagements with governments across the country, and are happy to discuss how these tools could help you as well. Similarly, if you are a technologist or public servant looking for ways to use your skills on high-impact, high-urgency projects, join our USDR volunteer community and see our open staff positions.
