I was talking to a consulting client recently. I’ll call him Mike. Mike is a big fan of NoCode. He learned to create unique automation for his company without engineering help.
Mike told me how he automated a manual task. This was a task he had to repeat every month. It used to take him hours and hours of work. Mike built the automation in just a few hours using standard no-code tools like Zapier and Airtable, plus some advanced steps in Make.
It took a few hours total. That includes the time to try things out using Zapier’s AI code generation. If my engineering team took this on, it would take at least a month. It could be six months for some teams that need to become more familiar with the company or industry. Five months would be spent studying the complexities of the project and domain.
Does this mean software developers will become obsolete? Should engineers look for new jobs and prepare to drive for Uber? I don’t think so. Let me explain why with an example.
A Travel Example
Imagine you need to fly from San Francisco to Paris. If your company is just two people with limited funds, you’ll plan the trip yourself. You’ll find the cheapest flight, even if it has multiple transfers. You’ll get the most affordable plane seat and stay in the cheapest Paris hostel. You’ll take public transportation to your meetings.
Now, imagine you’re the CEO of a Fortune 500 company. Your company has cash, but you need more time. So, you have assistants to help optimize travel. Plus, there are policies on approved hotels and flights based on employee needs.
In this case, you won’t do any trip planning. Your assistant puts the trip on your calendar. They tell you you’re meeting with Ben from Coca-Cola in Paris next week. You’re picked up at 11 a.m. Monday and return at noon Wednesday. Your main concern is having a smooth trip where you can work the whole time, including WiFi on the plane.
Business class tickets cost more for a reason. Business hotels and transfers also come at a premium. Sometimes, it seems ridiculous, but it’s not just for show. It’s for practicality, not showing off. This doesn’t mean you must always fly business class; it has its purposes.
Working with developers is similar — it saves executive time but costs more. It also requires upfront processes, which take time to build.
Testing and Reliability
Software developers invest heavily in testing their code. Scrappy startups may skip testing at first to move faster. But once live users come, they must add tests. Otherwise, things break too easily.
Here’s why: Software components depend on each other. A change in one place can break another area. As systems grow, these interdependencies become complex. It’s impossible to thoroughly keep track of what might break.
With larger teams, no one understands the whole system and all connections. So there’s a high chance of unexpected breaks. Testing is the only way around this. Software teams have entire QA departments running manual tests. They do rigorous automated testing, too. Updates go through multiple testing phases before release.
NoCode platforms test their own services for reliability. But they don’t test your specific workflows. When things do break, it’s painful to diagnose and fix. Each automation makes this more challenging. More scenarios mean more potential issues.
Challenges of Delegating NoCode Work
“I would hire someone to maintain my automations,” you might say. This can work but has downsides.
First, you must explain all existing scenarios to the person. Describe how each works, how they connect, and how to test them. Explain how to make changes safely.
They need context on your company processes to build new solutions, too. Give detailed descriptions of all steps. Conduct regular meetings to provide feedback. Set KPIs and goals to track progress.
With many scenarios, you need multiple people. A manager, customer support, etc. The more complex the system, the more it needs traditional software team practices — documentation, knowledge sharing, progress tracking, etc.
NoCode Prototypes Aren’t Complete Products
NoCode is excellent for quick prototyping and proving concepts. It’s also great for building quick, non-critical solutions. But turning these into reliable, production-ready products requires engineering discipline. Whether made with code or no code.
I’m not saying NoCode and automation are bad for business. They have many uses when applied correctly. But each tool excels at specific jobs. Use the right tool for the task.
Coding can build complex logic and systems faster than no code. But it requires background knowledge and experience. NoCode opens app building to more people. However, no-code projects still need solid software practices as they scale.
There’s a difference between a proof of concept and a complete product. An engineer could quickly code a script to transfer money between bank accounts. But it’s just a prototype, not a robust product yet.
No-code is very useful but doesn’t replace the need for engineering discipline and best practices, and they take time and cost money. Custom software principles like rigorous testing apply to no-code projects as they grow. Using the right tools for each job is critical.
Originally published on Medium.com
