What no-code and low-code mean
No-code platforms give non-developers easy tools to create custom software without coding. They let people set up data models, workflows, pages and other configurable components and put them together into an application quickly. Some are geared towards enterprise customers, others suit smaller businesses.
Low-code platforms have a similar aim but are designed for more technically capable users, including developers. They may include no-code elements or be purely code based. Either way they are tools to speed up the coding of custom applications.
Two questions apply to both. Does the platform sit in the provider's cloud on a SaaS basis, or can it be deployed in your own environment? And can it meet the functional requirements of the application at all?
Mobile apps and MBaaS
The options for low-code and no-code mobile apps are more limited, both in number of providers and in results. Only fairly formulaic apps can be created, which can serve well for standard in-house use.
You can still speed up a custom mobile app by using a mobile back-end as a service (MBaaS). MBaaS has its limits and is not suitable for every project, but where the requirements fit it can get an app to proof-of-concept or MVP much faster. Once the app is proven, it is usually still best to build a custom back-end to handle scaling, specific business needs and integrations.
The case for low-code
At first glance low-code looks like a no-brainer. Not every solution can be built with these tools, but for the ones that can, why would you not? The pros are obvious: vastly reduced development cost and time to completion. A common expectation is a 4X to 10X productivity improvement, and for the easiest tools it can be 100X or more, with the trade-off that those tools are limited in what they can produce.
Low-code also lowers the skill level needed. Developer-level tools let more junior staff contribute, while platform-style tools can be configured by a tech-savvy staff member with no software background. Many platforms give greater certainty around best-practice security and trouble-free deployment, though that comes back to cost, since with enough budget the same standards go into a custom application.
The case against
The obvious negative is ongoing licence cost. For many of the top platforms, Applicable has worked out that our average customer would spend NZ$30K to NZ$100K a year on licence fees. For a reasonable sized mid-market company that may seem manageable, but consider what you will have spent after 10 years, and that you will still own nothing: no IP and no solution you can keep using without paying and paying. As an IT consultant said to us, "low code solutions; there's legacy technical debt right there."
If you plan to sell the software to your own customers, licence fees that scale with users make the product hard to price. A high-code build that you own has no such ceiling.
You are also tied to someone else's technology roadmap. In the extreme case that means the platform being switched off, as happened with Adobe Business Catalyst, the no-code websites system.
Then there is the user experience. Going the low-code way often means compromising on the ideal UX of your product, because the platform decides what a screen can be. Once that is in the balance, it is harder to call low-code a no-brainer.
Not a definite right or wrong
There is no definite right or wrong. Custom versus low-code needs careful evaluation, and the right pathway varies with the situation and the product. Four questions do most of the work:
- Internal only, or something you will sell? Internal only, low-code may be a good option. Selling it, stick with custom.
- A specific user experience, or all pretty standard? Standard, a platform your staff can configure may work. Specific, you need a developer-level tool or custom code.
- What licence fees can you tolerate? Set the budget, then see which options fit within it for the next 10 years, not the first.
- Disposable, or large and core to the business? Simpler low-code tools are good for fast-moving, sometimes temporary, needs. If the system is large, complex and core, treat it as a serious build.
Where Applicable stands
Applicable builds custom web applications with zero licence fees that the client owns outright. The code is deployed in accounts in your name, so you can move vendors or take it in-house without asking anyone. Our own build accelerator, Hypercode, generates most of the back-end, the database, business logic and APIs that eat project budgets, so you get much of the speed that made low-code attractive without the annual bill.
We still say when a low-code tool is the right answer, usually for a temporary internal workflow that does not need to integrate with anything. Custom applications from Applicable range up to around NZ$250,000, and the small internal tools that low-code competes with sit at the bottom of that range. The scoping call is where we work out which side of that line your project sits.
Key takeaways
- No-code tools let non-developers configure applications; low-code tools speed up coding for more technical users. Both can be SaaS or deployable, and the deployment question matters.
- Applicable estimates the leading low-code platforms cost an average customer NZ$30K to NZ$100K a year in licences, and after 10 years the customer owns nothing.
- Low-code is a good fit for internal, standard, temporary tools; custom is the fit for customer-facing products, specific UX and anything you plan to sell.
- Adobe Business Catalyst being switched off shows the roadmap risk of building on someone else's platform.
- Applicable builds custom web apps with zero licence fees, owned by the client, using Hypercode to keep build time down.