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.
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.
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:
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:
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.