When to Use No-Code vs. Traditional Development
When it comes to building an app, you now have 2 development options available: no-code vs. traditional development.
No-code allows users to create apps without writing lines of code, promising to make software development (which is typically really slow and expensive) much faster and cheaper by a 5-10x margin. And thanks to the hundreds (if not thousands) of no-code tools available, you can now build just about any app a consumer or business might need with no-code.
But not every use case or project is right for no-code. Sometimes traditional development (i.e. code) is a better fit. However, because custom code is slower to build and requires more ongoing maintenance effort than fully-hosted no-code platforms, it’s best reserved for cases where no-code tools can't achieve what you need.
A framework that’s helpful to understand when to use no-code vs. traditional development is this: easy, solved problems vs. hard, new problems. Let us explain.
Solved Problems (Great for No-Code)
In software development, solved problems are those that have been seen lots of times before and, as a result, there exists a standardized way of solving them.
For example building a two-sided marketplace (e.g. Airbnb for x) is a solved problem. Under the hood there is a table of users, properties, bookings, etc. When a new booking is made, the application makes an API call to a payment service like Stripe to charge the user and then a new booking object is created. None of this functionality is particularly hard and, because of that, it can be abstracted and built without code.
New Problems (Best for Code)
On the other hand, you have new problems. For example, we don’t yet have standardized solutions for products like a new kind of a video editing tool or software that allows a novel IoT device to capture the right data, which is why these products need to be built using a lower-level tool of code.
Other common reasons for bypassing no-code and instead needing traditional development include:
- Novel technology (e.g. machine learning algorithms)
- Huge scale (e.g. app needs to support millions of daily users)
- Custom visual interface (e.g. create something like Photoshop or iMovie within app)
- Team capabilities (e.g. you have existing developers who need to stay busy)
But the reality is that 90%+ of custom software needs fall into the solved problem category. That’s why we think that most such software is going to be built without code. At the same time, we also believe that hardcore coders will have plenty of work solving the new problems. And then there will be lots of products that are a blend of the two – no-code solutions accomplishing 90% of the functionality that then integrate with coded solutions that accomplish the other 10%.
Examples of these hybrid builds might include:
- Embedding a code-based tool into a no-code application
- Using an API to have a no-code tool send requests to a code-based algorithm or service
- Using single-sign-on (SSO) to allow users to link between different parts of an app built with code/no-code
- Having a no-code user-facing tool connect to a custom code backend database
- Creating workflow automations in a no-code tool, that get triggered by code-based tools in your existing stack
Either way, both no-code and traditional development represent two distinct, but valid, approaches to creating an app. Each has its own pros and cons. However, because custom code is slower to build and requires more ongoing maintenance effort than fully-hosted no-code platforms, it’s best reserved for cases where no-code tools can't achieve what you need. In other words, traditional code should be used on an "as-needed" basis.
