Using low-code/no-code tools successfully requires knowing how to pick the right tool and knowing the kind of challenges that merit calling in a technical team for consultation and advice.
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.
Earlier this month, we launched our series on how USDR has used low-code/no-code tools and last week we explored the strengths and weaknesses of the tools. Here, we examine how to choose these tools and how to approach them when working with technical teams.
How we choose no-code/low code tools
First, we like to look for tools that have a strong degree of interoperability with other tools–ideally both in the form of an open API and in the form built-in integrations such as having good support in Zapier, having a Power Automate connector, or simply having many direct integrations with the other key software you use. But looking beyond the current set of tools avoids deadends later–the richer a tool’s ecosystem is, the more likely you will be able to integrate future tools.
Related to that, we also err on the side of tools that have rich feature sets, even when the simpler tool might get the job done today. This is one reason we prefer JotForm or Cognito Forms to, say, Google Forms, Microsoft Forms, or Airtable Forms. From complex conditional logic to access to a range of form plugins, we are less likely to hit a situation where we can’t do what we need to do and are forced to migrate. The one situation where we often err on the side of a simpler tool is when it lets us avoid bringing in an entirely new piece of software; for example, if an Airtable form is good enough for our purposes, and we are already building in Airtable, we won’t bring in JotForm until it’s necessary. On the other hand, if we’re building an intake form for a benefits application, we’ll almost certainly start in JotForm, even if a less powerful form tool seems like it might get the job done because we don’t want to have to rewrite everything if we discover a more complex need later on.
While features matter we also care a great deal about the usability of these tools because we are often handing them off to non-technical folks.
Tools like Zapier, despite being less featureful than tools like Integromat, are easier to bring in because they are designed to be fairly simple to use. We’ve found that most users can pick up Airtable very quickly due to its similarity with spreadsheets. Similarly, while we are excited about the promise of tools like NoCoDb, the current usability story makes it difficult for us to use them today in products where Airtable may shine.
A second major consideration is ensuring that there is no lock-in to any tools storing data. For example, we always want to see a way to get a machine readable record of the user data that was stored in the system. A CSV download is generally fine as long as it contains the records in a reasonably structured way. If data access is via API, make sure that the API doesn’t cost extra to use.
Another consideration is how good the user community around the tool is. For example, both JotForm and Airtable have active, helpful support forums that answer most common questions.
Finally, it’s important to think about the real, documented scale supported by each tool and decide if it fits the scope of the project being planned — with some headroom as a margin of safety.
How we think about low-code/no-code for technical teams
We’re frequently asked whether low-code/no-code tools are more for non-technical users to build software for themselves, or if they work best in the hands of a technical team. The answer is: both.
Non-technical teams can often handle their own buildouts for use cases with lower complexity and scale requirements (for example, building out a basic database tracker or a simple intake form that intakes hundreds or low thousands of records). In these cases, low-code/no-code tools simply remove much of the friction of building using traditional programming languages and the team can focus on the underlying problem.
As the scale and complexity increases (e.g. building complex screening workflows with multiple stages in the process that will process tens of thousands of applicants) traditional software development and product management techniques become more important to deal with the increased complexity. For example, product management thinking helps prioritize critical features and ensure that the solution fits holistically together. Additionally, security, compliance and scale considerations may come into play. Fortunately, the risks are generally lower because the types of problems are much more directly connected to the application design. For example, you aren’t going to have an XSS issue with a form builder, but you do still need to think about threats from malicious users if you’re accepting document uploads. In these cases, having a team with more technical experience partner with the non-technical team during the initial buildout can lead to a better solution, and the low-code/no-code tools will act as an accelerant for their efforts while supporting a more seamless ownership transition once the initial work is done.
We also think that low-code/no-code tools, while not a substitute for user research and design, can support these efforts through rapid prototyping (or simply allowing internal users who are the customers of the product to build tools for themselves). The tools also generally provide a pretty good base layer of UI components — a JotForm form looks good with minimal effort.
How we think about security and privacy of these tools
A privacy and security review is typically a key part of deploying any new tool–particularly one that may contain sensitive resident personal data. Fortunately, in our experience deploying these tools to over 40 of cities, counties and states, we have not found these reviews to be a deal breaker. Most of the tools we have used have mature privacy and security policies that incorporate industry best practices and standard certifications.
For the vendors we’ve used the most, here are links to the privacy and security policies of each:
Airtable security and privacy
JotForm security and privacy
Cognito Forms security and privacy
Zapier security and privacy
Power Automate US Government plans
Low-code/no-code tools help build capacity
While low-code/no-code are a benefit for many teams in that they don’t require a lot of programming experience, they do require a certain level of business savvy to make them work for your team. But when you pick the right tool for the job and know where to get creative, they can really build up the capacity of your teams.
Don’t forget to check out our first post in this series, review our deep dive on low-code/no-code tools strengths and weaknesses, and check out our advice on how to get started.
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.