NoCode has arrived and it's everywhere. It’s popular with entrepreneurs who are creating their own apps without developers, and with developers who can now quickly build apps faster than when they were using code. As it’s so in demand, you might think that there’s no question as to whether you’d use code or NoCode; but in reality, that question is there and it’s valid.
To help you understand NoCode a bit more, this article will address the benefits (reduced time to market and building without a developer) and the future of NoCode.
Speedy
NoCode gives users the ability to build things rapidly, which is appealing when you’re trying to find your market fit. If your first build doesn’t take off, which is highly likely, you only have to throw away a week’s worth of work using NoCode compared to a month’s worth with code. If you view it in this way, NoCode appears to be the smart choice.
Building in NoCode seems like it would always be quicker; but actually once you’ve learnt about the software libraries and frameworks that you use for coding, you can build rapidly. This was shown in a SaaS blog which analysed the process of building a SaaS in two weeks on top of the SaaS bootstrap Parthenon. The time spent building each day, over that two-week period, amounted to a few hours per day, with quite a few days amounting to zero hours. These timings mean that you won’t be too attached to a project if you end up having to scrap it, and that this can be a side project for you to do after you've finished work. Although code seems to take longer, the hours spent coding are equivalent to those spent using NoCode.
It’s also important to consider the time spent maintaining your app, as you will spend more time on maintenance than you will on writing code to launch the app.
It seems that the benefit of NoCode’s speed may be oversold. To me this is a 50/50 - neither side really wins.
Nodeveloper
If you’re a non-technical person trying to create a product on the internet, you’re going to need help from a technically-minded person. In this case, you have three options: 1) Find a technical co-founder; 2) Hire someone technical; 3) Become technical yourself. Let’s break that down:
Find a technical co-founder
Let’s be serious: finding a technical co-founder is hard and can be hit or miss. Developers can be difficult to work with as they have their own plans, ideas, and projects going on. There also aren't many developers who want to build someone else’s cool idea just for the sake of it. Typically because of this, your ideas are safe with them as they can’t be bothered to build your ideas, much less steal them. Overall, if you’re building a tech product, then having a technical co-founder is the ultimate best, but in reality it’s often a pipe dream.
Hire someone technical
Again, this is fairly hit or miss; however, less hit or miss than finding a technical co-founder. Hiring someone technical is a proven way to get your product built. The issue is, you don’t know what you don’t know. There are a lot of subpar developers who make their living by building complete and utter crap for people. Then there are also developers whose job is to improve that crap. Until you’re working with them, you might not be able to tell the ‘greats’ from the ‘duds’. Although that makes life difficult, your starting product doesn’t need to be perfect, it just needs to work well enough that people pay for and find value in it. Although this option is expensive for most people, and that expense isn’t always an option, it can be a good route to take if you can afford it.
Become technical yourself
This final one essentially involves you learning to code which is, well, super hard. Developers typically forget how hard it was to learn, even though they constantly write code that doesn’t work and struggle to make it work sometimes. Although it’s super hard, it’s also very cool. Being able to build something in itself is cool, but building something that other people want is even better. The ability to independently build your ideas into your own project, and to understand everything is honestly amazing. The only downside to doing it yourself is: it’s time consuming. It takes time to learn, build the app (which can take months), and also launch and maintain it; however, unlike your financial investments in the last two points, this investment will be in yourself and your skillset for the future.
**If you don’t know a friendly technical person or if you have no burning desire to learn code - use NoCode. NoCode 100% wins out in this situation. Save that developer money for marketing.**
The future
In my opinion, the future of NoCode and code is really important to consider. For comparison, unlike code, NoCode nearly always ties you directly to the company. So if that company goes under, has technical issues, or decides that they don’t like you: your app is done. If in the future, you decide that you don’t like the company or that the service they’re offering is poor, you’re stuck there until you build your app in another no-code system or hire someone to rewrite it in code.
Another downside of NoCode is that it can be really hard to judge what kind of traffic you can manage. Let’s say you build a super cool app rapidly using NoCode. If it starts getting traction, it may be very difficult to tell if you can handle 100 concurrent users, 1000 or just 10. Using NoCode through a company will likely mean that you have no idea what sort of traffic they can manage, which may affect your application's growth.
Comparatively with code, if you don’t like your hosting provider, when you have written your app in a specific programming language, you can just move to a new hosting provider. It may not be fun to move and can sometimes be a lot of work; but, it’ll always be a lot less work than completely rewriting your application. Another benefit of code is that you can easily build out from your original application.
Future wise, using code over NoCode seems to be the clear winner.
What does it all mean?
So it’s 50/50: one win for NoCode and one win for code. It seems like there’s no winner, right? Well, there are actually winners for different scenarios.
If you’re a non-technical person who is just starting out, you should use NoCode to get traction. Then once you get traction, you can start to move towards hiring someone to build your app. In this scenario, the benefits of using a bootstrap don’t apply as you’ll need to learn to code or hire someone, and then you can migrate in the future.
If you’re a technical person, then using a bootstrap like Parthenon to build your app is the most efficient way. Using bootstrap will allow you to build your app rapidly, especially if you use the same bootstrap multiple times. In addition to the rapid speed, it also gives you flexibility for the future. In this instance, time to market is no longer a winner and lack of technical expertise isn’t a factor.