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.
Partner:
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.
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.
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.
There are a number of common government scenarios where we think low-code/no-code tools really shine:
There are also some scales of projects that we think work best for low-code/no-code tools–and conversely, where they don’t.
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.