No-code Tools: Why They Are an Incredible Opportunity for Your Dev Team
I have been a founder for most of my working years, so a sizeable part of my network is made of other founders.
I talk with many of them on a regular basis, and we often discuss technical strategy — how to develop something, what's the best framework for this, etc.
More and more often I find myself saying: "Just use this no-code tool".
For those who are not familiar with them, no-code tools allow to develop features / websites / entire apps without writing code. They fit a range of purposes and go from the very specific (e.g. Memberstack) to the very generic (e.g. Bubble).
Over time, they have become an incredible opportunity for any team, for two main reasons: Speed and empowerment.
When they fit your needs, such tools aren't just faster than writing code, they are 50x faster. They are often "2 hours vs 2 weeks" faster.
They cut both your time to market, and the time you are going to spend on maintenance down the line.
They allow non-technical people to become active contributors and replace engineers in many tasks, producing two benefits:
You empower these people and motivate them, by making their work independent from the development process.
You optimize your team resources by freeing up engineering time.
No-code myths and fallacies
Most engineers today know about no-code / low-code tools and they may even appreciate a few of them, but I believe they don't use them nearly as much as they should.
There are three common fallacies I hear over and over to discount the usage of no-code tools:
1) "They are only useful to non technical people"
No-code tools are only useful to people who can't code — because those who can code should build things that way.
This is far from the truth, for two reasons:
Coding is the most expensive activity you can perform, it is slow and creates ever-increasing operating costs. Building something with code should be kind of your last resort, instead of your default solution.
No-code tools save you from actual coding, but still require similar analytical thinking. Engineers who embrace no-code are spectacularly efficient — it becomes a superpower.
2) "They are limited"
All tools have boundaries — some are specific for a few use cases, while others are more generic. You are always trading off some flexibility for speed and ease of use.
Just start with your use case and look for a tool that fits your needs. Most often, there is one.
3) "They are only useful for prototypes and MVPs"
Many startups create MVPs with no-code tools. This is wise because of 1) speed and 2) ease of changing direction over time.
And this is particularly empowering for non-technical founders, who can build something and demonstrate traction before actually adding a technical founder to the team.
However, there are also entire businesses who have been built with little to no code, and are still run this way past the MVP stage. Here is a list of notable ones.
When to use No-Code?
The code vs no-code choice closely resembles the make vs buy one.
My point of view is that you should make (with code) only what is a core, innovative asset to your company, and buy (or make with no-code) pretty much everything else.
When in doubt, ask yourself these questions:
Is the solution to my problem different than what others have done in the past?
Does this bring a core competitive advantage to my business?
If both answers are no, then go for no-code or a pre-made solution. And for most businesses, 80% of these questions should end up with a buy decision.
Do you want to contribute with an article, a blog post or a webinar?
We’re always on the lookout for informative, useful and well-researched content relative to our industry.