Most companies larger than sole proprietorships need some form of internal tooling, and as your company grows, this need for tooling typically grows as well. Often you’ll find that the tooling you need already exists: QuickBooks for accounting, Salesforce for CRM, etc.
If an existing tool in the marketplace meets your needs, it’s often a good idea to use those tools rather than build your own. You’ll usually save time and money using an off-the-shelf solution, allowing you to focus on activities that bring the most value to your customers (should you spend 6 months building a custom CRM, or would that time and money be more valuable to your customers if you build that feature X which large numbers of potential customers need?).
At some point, though, you may determine the value that a custom tool could add is high enough that you decide to explore options for building one; it’s during that exploration process you should take a hard look at low-code options!
What do we mean by “low-code internal tools”?
Low-Code = app “builders” that typically allow you to create custom web or mobile applications using a combination of already-built components and code
Internal Tool = a tool used by your team rather than your customers
Retool is one of the market leaders in this space. Take a gander at their marketing site for some examples and customer stories. I’d also recommend looking at their developer docs, particularly the components section, and asking yourself how much engineering time it would take your team to simply build out a similar component library. In a nutshell, low-code tools allow you to drag and drop components, wire those components up with code, and click a button to publish your app to your team.
The quintessential example is a custom CRM — imagine that rather than being constrained by existing CRM design/feature sets, you were able to build the perfect solution for your team’s specific needs. That said, a CRM is not a great example; in my opinion, there are so many existing CRM solutions out there that I think it’s very likely you can find an existing tool that works well for your team. A better example might be the software that DoorDash uses to help manage its delivery drivers. That’s a very custom use case, one for which it’s unlikely existing software would work very well. They realized this and used Retool to build their custom internal software.
Here’s a screenshot to give you a little better idea. The app is being built in the center of the page (the area with the gray background). We can see some <input> elements for search/filtering, a table, and some cards that probably contain data. The bottom and right-side panels are what engineers building the app will see; in this example, it looks like we’re writing some SQL queries to populate data in the table.
Downsides
Before I get too far into selling low-code tools, let’s play devil’s advocate and examine some of the major downsides we should be aware of. Like anything, just because you’re building an internal tool doesn’t necessarily mean low-code is the de facto best choice.
Constrained Functionality
When your team builds a React application, nearly any functionality you can imagine is doable. It may not be easy, but it’s probably possible! When you use a low-code tool, that’s not the case; the functionality of the tool will constrain you. For example, many low-code tools I’ve tested and used in production do a complete browser refresh when you navigate from one page to another. Others don’t have front-end caching built in, so each time a user navigates from and back to a page, you’re making a network request (you can build caching into your back-end, of course).
Constrained UI/UX
One major benefit of low-code tools is that they have an existing component library: tables, modals, buttons, selects, etc. Instead of having to build and maintain components, whenever your engineering team needs a table, they’ll just drag and drop one onto their app canvas. The clear downside to this is the styling of those components is very constrained. Most low-code tools I’ve used allow custom color schemes and border-radius, but that’s about it. You get what you get. Over time I see this improving, especially given that many of these low-code tools want to capture more of the external customer app market from companies like Bubble.
(Yet Another) New Thing to Learn
Your engineering team already knows React, Angular, or Vue; when you choose a low-code tool, you’re asking them to learn something new. This is a bit of an ongoing joke in the JavaScript world (for good reason), and you’ll probably be the butt of a few underhanded comments from your engineering team if you propose low-code. That’s okay. Have a discussion with your team and ask them to evaluate the low-code themselves. Each tool has its own way of doing things and its own constraints. Learning those constraints takes time. That said, I’ve found that junior engineers with more than a year or so of front-end experience are typically able to begin building in these tools very quickly. They’re much easier to learn than, say, learning React.
Downtime
Downtime is out of your control. If it’s down, you’re at the mercy of another company. If your internal tooling is mission-critical, this is absolutely something to have a conversation about. I’d encourage you to compare and contrast the uptime you think your own engineering team can provide.
Breaking Changes
If you wander through Retool’s community forums, you’ll find one of my posts that says something to the effect of “Please move slower and break fewer things” which garnered a lot of discussion. Low-code companies need to be agile and need to move fast, just like we at our own companies need to. When all of the buttons across all of your internal tools which are hooked up to an async API call begin failing though, this can be quite a bad thing. Usually, these companies are quick to respond, but again, there’s nothing you can do until they revert or fix their breaking change. Unlike in your own app, there’s no SEMVER, no way for you to revert the change manually.
Engineering is Expensive and Scarce
Now that we’ve taken a look at why you might not want to go the low-code route, let’s consider some reasons I’ve personally found it to be a great option for internal tooling. First and foremost, engineering is expensive, scarce, and usually extremely valuable to your customers (you know, the people who actually generate revenue!)
Building an app using a low-code tool is potentially an order of magnitude faster than building the same tool in something like React. I don’t say that lightly and I’m not exaggerating. Don’t take my word for it: have an engineer on your team sign up and try out one or two of these tools and report back.
We all know engineering is expensive, scarce, and valuable. Compare and contrast the value to your organization:
- 3 months of one team’s engineering resources to build an internal app in React
- 3 weeks to build the same app in a low-code tool
What will bring more value to your customers, the internal tool or that great feature X? With that in mind, where should your team spend the most time?
Extremely Agile
Low-code tools are incredibly Agile. Once a few engineers have the initial learning under their belts (which I’d estimate would take about a week), they will be able to build incredibly fast. Changes/maintenance/updates are incredibly fast as well. I could yammer on about this but I doubt I’ll be able to convince anyone who hasn’t tried using these tools. Again, I recommend getting in and building a few things, trying it out, and discovering for yourself.
Some Non-Engineers Can Build
One major benefit to low-code tools that I think gets commonly overlooked: some technically-minded folks who maybe aren’t engineers (e.g. product manager, data analytics, marketing tech) will often be able to learn to build things with low-code. It’s unlikely they’d be able to contribute to a React project but give them the ability to spin up a standalone low-code app, and you might be surprised by the valuable tools they build for themselves and their teams! It can even be a great option for wireframing, MVP, initial hypothesis/prototype/validation scenarios.
Tips
I’ve used low-code tools extensively over the years, testing most of the major options and using both Retool and UI Bakery for complex internal apps in production. If your team decides to take this route, here are a few tips that might be helpful.
Review/Test as Many Tools as Possible Before Choosing
Analysis paralysis is real, but I do think it’s very valuable to compare as many low-code tools as possible before choosing one. Would your engineering lead decide to build your back-end via an event-driven architecture without carefully considering all the options? Probably not. Once you’ve chosen a tool and built your important internal apps in it, the cost to switch can be high.
Document Standard Practices
Inevitably, you’ll find certain things just have to be done a particular way in your low-code tool of choice. For example, my team used GraphQL Relay, and paging through results required a particular setup in Retool. Since getting data via our API and displaying that data in a server-side paginated table was a very common task, we documented how to do this. Notion for the win!
Log Errors
Would you build a front-end or back-end without logging? If so….well, I won’t judge, but I will say a prayer for your users! In my opinion, logging problems in internal tools is almost as important as logging them in your customer apps.
Be Careful With Component Updates
While it’s great that you don’t have a component library to maintain and components are just auto-magically maintained and improved, be careful when a new version of a component comes out. All the low-code tools I’ve used let you manually decide when to update a component; you should be careful when doing this. Read the documentation, do some testing, and ensure the new version of the component has all of the features you need. Often, when a new component version is released, it won’t yet be at feature parity with the previous version, which can result in you breaking critical functionality in your apps if you aren’t careful.
Top comments (0)