Low Code No Code

Cheaper

Developers are expensive, especially when you start talking about recurring costs that happen every time you change your mind.

Faster to set up

Development cycles are long. People in business want to iterate on an idea before iterating on an implementation of an idea.

Financial reasons

It’s easier to get approval for smaller operational expenses than it is for large capital expenses.

Ease of disconnecting

If the tool doesn’t work, they can bail quickly without firing anybody.

Outsourcing of risk

If there are regulatory concerns around certain processes (payments, for instance), they’ll be the vendor’s problem.

IT folks can be annoying

There is usually friction between IT departments and other departments. Using low code and no code tools, people can often sidestep that friction until they are in a better political position.

Content management systems

Companies typically don’t roll their own content management systems and haven’t for years (the success of wordpress is proof of this), but the newer types of CMSes are a different breed. They are built with the understanding that many companies need to separate the concept of content production workflows from content display workflows.

Back in the day you would have run into things like wordpress, dotnetnuke, and the like. Now, however, you are just as likely to see headless CMS systems, like Ghost, Strapi, Netlify, and many others like them. Most CMSes, especially headless CMSes, offer a wide range of ways to interact with them, including RESTful APIs, and graphql, on both the read and write side. There are varying degrees of webhook capability in this set of tools as well.

When you are building software for a company, these types of CMS are often very useful when content production is a cost center for the business, rather than a revenue center (although you can probably get by with them in a revenue center scenario as well).

Data entry

It kind of always has (MSAccess back in the day). If a system has a simple enough data structure, there is often little reason to waste resources building out a fully featured data entry environment. Companies are better off using a solid third party tool with a good UI instead of building a crappy in-house replacement.

As mentioned before, this sort of thing was a common use case for Microsoft Access (and still is). A lot of programs still in use today had their start as Access databases. The newer tools are essentially a modernization of such setups. Access is still around and very usable, but there are many other contenders that work well in a modern environment, including tools like Airtable, Directus, Quickbase, etc.

Most of these tools offer at least APIs and webhook capabilities, although you will likely pay for usage. In some cases, you can actually directly access the underlying database as well.

App “Glue” / Orchestration

Many times business people want to share data between applications, but don’t want to hire a programmer to wire it all up. They may also want to avoid risks due to platform (API) changes and may want a way to avoid this risk.

This is something that companies have had to do forever, and often resulted in some rather impressive and hacky kludges as they tried to get systems to place nicely together. This has gotten especially fun in the modern web, with all the security considerations and intermittent failures that are common in a distributed environment.

Common tools in this space include things like Zapier, IFTTT, and Tray.io. These tools offer ways to either respond to incoming webhooks from other applications, or ways to push data at other application endpoints. You’ll generally interact with these tools either by calling webhooks that they provide, or by having them call the webhooks in your own application. That is, if you even know it’s happening at all. Done well, you might never know.

Spreadsheets

Business people understand spreadsheets and use them all over the place already. As a result, they’ll often try to bend a spreadsheet to their own purposes. For years, a reasonable question to ask when trying to come up with software to write was “Are you doing anything with excel spreadsheets that might be better done in an actual application?”

While excel is well known, there are tons of new, web-based spreed sheet systems that people can use, including Google Sheets, Zoho Sheets,  that have much better integration options. You’ll often integrate with these tools with web APIs and/or GraphQL. However, you may also find in some cases that it is still easier to export them as a set of comma separated values and deal with the data in an old school fashion, or bulk insert into a database.

Dashboards

Stakeholders need to be able to quickly determine the state of the system right now, especially at a financial level, and they need it to look good when they show their bosses.

A long time ago, this would have involved pulling data into excel and using the charts and graphs function, but that data may be scattered over numerous disparate systems now. However, it’s still needed and the expectations around how that data is presented are much higher now. You’ll still run into excel being used this way, but many of the no code application platforms will have their own dashboarding systems within. These include things like Bubble.io, Microsoft PowerApps, etc.

While these tools often allow integration through webhooks, web apis, and the like, many of them can also directly connect to databases and other data stores, so you may be able to effectively “integrate” simply by shaping the data appropriately and shoving it into a table.

Social media and promotional email tools

Marketing types need to be able to manage things like ad campaigns on a variety of platforms. They also probably need to be able to trigger campaigns based upon things that occur in one or more applications. For years, there has been software that does this, either included with CMS systems or in the form of add-ons. However, with more modern software packages, you’ll often find powerful APIs to aggregate, parse, and manage social media and email outreach using commonly understood protocols (usually webhooks and RESTful APIs).

Rather than being designed from the ground up to be SAAS applications, with the APIs added later, many of the new tools that are available now are actually built in an API-first fashion, with the intention of being used with other web API based automation suites (such as zapier).

In general, you’ll be interacting with these using webhooks (so that they can send data to you) and REST APIs (so you can send data to them), although there are some newer tools that are starting to bring GraphQL constructs into the mix as well. Many of these tools function as part of some other package that your marketing/sales team already uses, such as plugins for wordpress, shopify, and other similar tools. And of course, there are also still the “old guard” of email service providers, like mailchimp, who are constantly evolving their integration points.

Voice, SMS, and phone applications

Voice-related stuff is hard to deal with and complicated to a degree that many dev shops can’t handle it well. If it’s critical to business operations (for instance, filing support tickets for an ISP), the company is likely to look for tools that let them build workflows without developers.

While tools like Twilio have been around forever, there is also an increasing need for fairly complex workflows (which twilio also allows, but people often aren’t aware of it). This has lead to tools such as voiceflow, which lets you manage complex voice-related workflows through a graphical design tool, rather than code. These tools can seamless integrate with other applications and allow a user to send texts, voice mails, and even to do voice calls from within the application.

You’ll often integrate with these tools either using other no-code tools such as zapier, through the use of web apis, or by including a widget in your website (whether that is something low code like a wordpress install, or an otherwise “normal” web application).

Bug reporting and other ops stuff

Frankly, these exist because it’s hard to get right, even for good developers and is hard to justify. Further, developers are often no so good at making errors visible to management in a way that actually lets management deal with the issue (ie., not just an error message and a stacktrace).

We’ve obviously had logging for most of the time that we’ve had computers, but the goal of these kinds of tools is to capture useful metrics along with simple log messages. These tools also make sure that you can record data that comes out of low code / no code workflows, which can be really useful when those are part of your workflow.

You’ll typically integrate with these tools using web apis, whether in a browser or on a server (or often, both) and you’ll probably make some use of their output yourself as a developer (especially when using tools specifically designed for development operations, such as AppInsights, New Relic, etc.). In addition to logging, performance monitoring, and tools for seeing usage, there are numerous other things in this category that are either no code or fairly low code, such as feature flagging tools, build pipeline tools, and tools for managing cloud resources.

Databases

Database design at the small scale isn’t hard enough to be worth having a developer do it. Early on, especially when prototyping something, it’s often easier for people in other specializations to use one of the many online databases to store various data. While this does take some programming knowledge, it’s often less than you’d think, as a lot of tools exist that can allow someone to quickly design a database (and the screens needed for populating data into it) inside their web browser.

Tools in this space include things like Airtable, Directus, Kintone, as well as “CMS” systems like strapi, and contentful. Many headless CMS systems might better be described as headless databases, but are marketed as CMSes because that’s a very common use case. You’ll typically interact with these much like the content systems we discussed earlier, either via webhooks and restful APIs, via direct access to an underlying datastore (like a POSTGRES DB) or via GraphQL.

E-Commerce and payments

Payments are simply awful to deal with in your own application. In addition to a lot of security concerns and regulatory issues, it’s expensive to make sure they are robust enough (and they are much more expensive when they are not).

There have been tools for this sort of thing for ages, simply because payments are both necessary and obnoxious to deal with. Paypal was one of the earliest low code options in this space, allowing you to embed a payment widget directly in your website. Newer tools enable more complex workflows that can tied back into your code, while still allowing the sales and marketing people to do things like adjust pricing, payment plans, and the like without you having to write custom code to make that possible.

Current options include things like Stripe, Chargebee, and Payhere. You’ll typically integrate with these by using a browser widget (or iFrame) to send data to them and have a webhook on your end to receive updates from them.