15
15 Comments

Code vs NoCode: which is right for you?

Code vs NoCode: Which is Right For You?

Both Code and NoCode have very passionate champions on both sides. It comes as no surprise that there can sometimes be a very divided view on which route is the best to take for a budding IndieHacker looking to embark on their next project.

Ask a coding fanatic which you should use, and they'll laugh.

Ask a NoCode devotee and they'll scoff at the notion that there's even a choice between the two!

These two camps have gotten so divided.. and it's genuinely puzzling.

The division and somewhat playful animosity between the two reminds me of the way some older musicians view DJs and EDM artists in the music industry, and vice versa. Some of the old dogs have embraced the new technology, whilst others swear by their tube amps and old school recording techniques. Neither is wrong in their preference. Both are equally capable of creating quality music.

Both those for Code and those for NoCode are equally capable of creating a product that can make a difference. And both parties are ultimately looking to achieve the same goal: they want to be able to do more work with less effort.

Both achieve this, in albeit very different ways.

I'm hoping that with this post, I can help shed some light on both sides, and outline some of the difficulties that you'll experience on either side of the aisle. Perhaps even find out ways that you can bridge the gap between the two to bring your next project the powers of both.

But wait, who are you?

My name is Andrew. I've been a developer for the past 16 years of my life and had an almost borderline obsession with some of what I'd consider the earliest NoCode tools as a kid: Microsoft Frontpage, Microsoft Visual Basic, Borland Delphi.

As a teen I played around a lot with various different "game makers", which were software that basically let you create a fully functioning game with little to no code. Platforms like GameMaker Studio are still alive and kicking, though they've since become less NoCode and more low code, embracing scripting.

Later on in my career, when I started working for a pretty well known tech company based out of the Bay Area, I was leading the development of some of our company's API integrations to various different platforms (Salesforce, Dynamics CRM, Microsoft Power Apps). I was absolutely astounded at what some of our customers had built using workflows within all of these CRM platforms without code.

This led me down the rabbit hole of Zapier and Integromat. The idea that you could build an entire application by just leveraging several different services and gluing them together from across the web is one of the coolest concepts I'd ever come across. My interest in NoCode was reignited.

Currently, I eat/sleep/breathe Airtable and have it wrapped around all aspects of my business, the product I build, and my overall life. I leverage Integromat and try to automate everything. I've spent a decent amount of time with Bubble, and Adalo just tinkering with stuff. I love apps that are "builders". I just really dig the scene.

I've got an insatiable desire to build new products, and love just playing around in these apps building out different app concepts. Letting my imagination run and just.. building.

Having spent so much time playing with these platforms, but having the background of a developer, has given me a certain perspective on these two camps and what they have to offer. I'm hoping that in this post I can help to explain the benefits and cons of both approaches to software development, without injecting too much bias into the equation.

I'm of the sole belief that there are certain circumstances where NoCode makes the most sense for a new project, and others where Code is the best way to go.

With all that said, let's start with a little history..

NoCode History

NoCode is not a new concept. It's certainly gotten more popular now, but it was also very popular a while ago too -- it just didn't have a fancy name nor movement to go along with it.

COBOL is a programming language that was invented by the Department of Defense in 1959 to essentially be able to write code.. but without knowing code. The idea behind it was that you were almost chatting with a machine, having a conversation. Coding in plain English. The thought was that this conversational style was going to take the coding world by storm in the business sector. The goal was to lower the gates to entry, so to speak, for new programmers to learn to speak the language.

Thankfully, this never actually took place. The computer scientists at the time were appalled by the commercially designed COBOL. Most COBOL you'll find these days lives at the heart of ancient old banking systems.

Sooner or later, Microsoft and a company formerly known as Borland started duking it out releasing some of the first "low code" products we had seen in Visual Basic and Delphi in the 90s. These tools let you drag and drop to design most of the application's UI, dramatically reducing the amount of code you'd need to develop applications. They had extensive plugin architectures where you could add third party custom plugins to do the majority of the work for you in any given application. You had to just configure a few things and add a little bit of glue code and voila, you have a working application. Both languages were also fairly simple, with Visual Basic taking a similar COBOL approach with a very verbose English looking language.

One of the novel things about these apps was that the UI was front and center. The code was hidden from you initially. You had to click through to reveal the code (what was commonly called the "code behind"). This approach was pretty groundbreaking at the time these tools first came out.

Fast forward another decade to the 2000s and these tools are now mostly obsolete because there's a new king in town: the web. Coding got more complicated due to the popularization of the web and client/server interactions (a frontend or mobile app talking to an API). Security got a lot more important. Big data is now a thing.

The NoCoders got left in the dust for a few years in the early 2000s while us developers got used to the new normal on the web.

Eventually, WordPress (and others like Drupal, Joomla) came along and showed how you could build a tremendously customizable platform that does one job really, really well: to create a fully functioning website and content portal, complete with custom themes and a fantastic plugin platform. This is the start of the modern NoCode ecosystem.

It wasn't until recently in the past 10 years in the 2010s, almost a decade after WordPress and its brethren showed up, that we had seen low code and NoCode exploding in popularity: tools like Webflow, Zapier, Integromat, Wix, Squarespace, Airtable, Bubble, and much more. Somewhere along the way we discovered we were solving the same problems over and over again with code, and we didn't really need to. So solutions were built that were tremendously customizable and could do many things.

Zapier and Integromat try to solve the "gluing platforms together" problem.

Airtable tries to solve the problem of people using spreadsheets as databases.

Bubble tries to solve the problem of abstracting away many of the common problems that are common across web applications: user registrations and log ins, a drag and drop editor instead of forcing you to use HTML / CSS, and setting up workflows for handling actions triggered via the UI.

Now we have a variety of NoCode platforms that give you a significant amount of power, and we also have a really vibrant Code ecosystem where the barrier to entry has never been lower.

The question is: when do you use NoCode, and when do you use Code?

When should I use NoCode?

Existing NoCode solutions are very good at specific types of apps.

They are ideal for apps that have a limited scope of interactions. Apps that don't have very complicated and dynamic permissions structures, complex user interactions, and complex datasets. Types of apps that can really benefit from a NoCode development stack are: content gateways, communities, directories, membership sites, appointment schedulers, etc.

The main thing that differentiates these kinds of apps from a more complicated app, is that the overall design of the data is well formed and the data flow is largely one way. The way that the user interacts with the app is very defined and not as open as something like a spreadsheet app (e.g. Google Sheets), where you could have potentially multiple users collaborating on the same item at a time. An app like that has data flow coming from multiple different directions (in Google Sheets' case: multiple different contributors).

Think of apps like Notion, Confluence, and JIRA. These would be very tough to build in a NoCode environment because of the amount of data complexity that is present. Some of the abstractions you would need to implement in the backend systems to accommodate these sorts of features and user interactions are incredibly complex.

In a sustainable NoCode app, the database design needs to be simple. The relationships between the tables are trivial. The way the data flows (either to the user, or from the user) is very straightforward, well defined, and the possibility of data conflicts is slim to none.

Mobile apps in particular are especially well suited for NoCode, especially when the majority of their functionality is tucked away in a backend API. Solutions like Adalo and AppGyver, give you the ability to create full CRUD apps in just hours. Everything from custom storefronts, simple chatting interfaces, to appointment scheduling apps and more.

Most of your time in NoCode is spent working on the UI layout, the user's interactions within the app, and simple business logic.

Generally speaking, if the primary value that your app is going to offer to your end users is in the UX presentation and it is your re-interpretation of a simple conceptual app - i.e. you're not trying to break new ground with something advanced on the backend: NoCode could be an excellent choice for you.

If your app does have some backend complexity - for instance take Tiktok, a seemingly simple mobile app on the frontend with an incredibly powerful and expansive algorithm running on the backend.. you should steer clear of NoCode.

Some NoCode platforms provide ways to implement potentially complicated backend functionality. Like Bubble and its workflows, or Zapier/Integromat and their take on workflows: but I can tell you first hand, this is more difficult to maintain than a properly written codebase implementing the same logic.

You have more tools at your disposal in Code to tackle these complex concepts and turn them into components and/or services, dramatically simplifying the codebase and making maintenance and scaling up a breeze.

Scale, I would argue, is one of the critical things that is difficult for NoCode solutions to tackle. Not just scaling in terms of adding more servers to accommodate load because of a growing userbase: scaling of the team building the product, and scaling of the product itself as you zero in on your product-market fit.

In modern codebases for big SaaS apps, code can be actively maintained by potentially thousands of developers. Modern source control solutions like GitHub are leveraged, along with a healthy dollop of process and help from other project tracking tools (JIRA, etc), in order to effectively ship/maintain existing applications without introducing any hiccups to the overall user experience. The moment you add more people, things get vastly more complicated.

I have yet to see an effective NoCode solution that handles the source control, deployment, and maintainability factors as well as a well-tuned Code setup can do. I've seen people try with Bubble, but ultimately there can be a significant amount of frustration.

But you know what? I'm of the opinion that is not what NoCode is for. NoCode is for the simpler apps that don't need a big team of developers maintaining it.

That leads us to our next section: when should I choose Code in the beginning?

When should I start with Code?

Beyond choosing to use code for your next project because you're looking to learn more about coding, there are definitely some situations where you probably want to start with code to begin with.

If you anticipate that your product will need to scale quickly: in terms of team size and overall growth, and there isn't an existing NoCode solution that tackles your problem space head on, you should generally opt for code.

If the data flow in your application is more complex than simple create/read/update/delete done by one actor at a time, and the relationships are more complicated than a stereotypical post/comment type relationship you'd see on a blog or community site, you should opt for code.

There are a number of benefits that come with choosing Code over NoCode for some applications:

  • Far more talent is available. NoCode consultants are considerably more rare than coders. You can find great talent for an affordable price on platforms like Upwork
  • Flexibility. You can choose the stack that will work best with the type of product you're aiming to create, and avoid many of the common problems that are typically experienced on NoCode platforms (these problems generally occur when users try to extend the platforms beyond their limits)
  • Performance. Well designed code written specifically to solve a particular problem will generally always be more performant than a generic NoCode platform
  • Control. You have more control over your users' data, over the deployment of your application, and your code is not silo'd on one single platform (ala Bubble). You don't have to deal with vendor lock in
  • Maintenace. Far more tools are available for maintaining existing code, and with the oversight of a good developer a codebase can be used for years without having to do any expensive major rewrites.

And some drawbacks:

  • Time. NoCode development is generally significantly faster than code based development
  • Expensive. Unless if you know how to code yourself, costs can quickly add up when developing your MVP. Finding product-market fit is not easy, and can involve expensive rewrites of core application features
  • Difficulty. Coding can be difficult. Even the most talented engineers routinely run into problems in code that are real head scratchers
  • Deployment complexity. NoCode solutions tend to take care of deployment for you. When you're dealing with code, you're also dealing with servers and devops. This adds more complexity

The good news is: there has been no better time to learn how to code than today. There are a vast amount of resources available, StackOverflow, countless YouTube videos, and the toolsets available are absolutely top notch.

Being a developer used to be a lot harder. Especially pre-StackOverflow!

That said, NoCode is still the way to go for a good amount of applications in their beginning stages. Apps that are B2C tend to be simpler, and naturally lend themselves more to NoCode, as do apps that target very small businesses (e.g. entreprenuers).

How can I extract the benefits of both?

NoCode's primary benefit is in speed of development and time to market.

If you are still trying to figure out your product-market fit, or you're validating your idea, NoCode and low code are a great way to be cost effective in trying your product out on your target audience without expending too much effort.

A lot of NoCode platforms like Zapier and Airtable actually allow you to use code within them, making them more low code platforms. Zapier allows for use of JavaScript and Python within code Zaps, and Airtable allows you to write custom scripts using JavaScript. Integromat has a handful of connections to outside apps that also allow for custom code to be executed where you can write some business logic.

Bubble also recently added the ability to write custom components in JavaScript to handle trickier business logic you can't handle with Bubble alone.

In fact there's been a bit of a movement catching on again that's been bridging the gaps, so to speak: low code.

There are platforms out there like Autocode and Pipedream, which basically give you one of the key selling points of Zapier and Integromat (gluing platforms together and dealing with credentials/connections) but let you use more code by default for more flexibility. Custom Zaps that span tons of different steps can sometimes be much easier expressed with just a couple of lines of code.

I use Autocode myself and it is wonderful for those of us who like the Zapier/Integromat concept, but enjoy working with code.

Some folks have built very interesting internal apps using nothing but Google Sheets (which I would say is one of the original NoCode apps, along with Excel + VBA) and Google Cloud Script, another variation of JavaScript.

In a sense, it seems that a lot of NoCode platforms are starting to understand the advantage of supporting some level of code and/or scripting for those circumstances where the limits of NoCode will be pushed a little too far.

On the opposite end of the spectrum: the Code scene has absolutely exploded with more advanced tooling to simplify a programmer's job.

Advanced applications exist that can generate your entire app for you via advanced code generation, and all you need to do is tweak a few configuration settings to get up and running. You still need to have a rough understanding of how the code works and how to navigate it, but your job is made much easier by letting the code generation take care of a lot of the boilerplate for you and you only need to make a handful of tweaks.

I personally sense that there is a closing of the gaps taking place, and that eventually these two rivals will be shaking hands in the middle, delightfully embracing low code as a happy middle ground. We're seeing it already on both sides.

It remains to be seen what happens, but what we do know right now is: coding is more popular than ever, and NoCode has been rapidly becoming more popular and mainstream as well.

I see no reason why people cannot embrace both paradigms of software development. Both have their place and excel in specific circumstances. I embrace both and couldn't be happier.

Questions?

Let me know if this post was helpful!

  1. 1

    A great post! Thanks:)
    As I looked recently (October 2023) the NoCode tools look rather expensive which is not surprising as it is a most convenient solution, with no dev/ops headaches and such.

  2. 3

    As an ex-dev, I believed nocode to be only useful for small prototypes or things like landing pages/portfolio pages etc

    After tinkering around with Bubble for a bit, I now see that you can indeed build fully fledged apps! It is still not ideal, but I reckon nocode builders will only get more powerful as time goes by

  3. 2

    That's a wonderful article! Never understand why people oppose code and no-code.
    They could work together and you could get the best from both of them.

    For example, low-code BPM platforms like Corezoid, n8n, NodeRED, you name it, fit extremely well with services/microservices architecture. That reduces pressure to devs, cuts down time to market, allows fast hypotheses validation.

    In this case, you have a solid foundation for critical processes and a rapid way to automate things you always want to automate.

    1. 2

      Yep! It's about selecting the right tool for the job.

      This is one of the things I see junior level Code and NoCode developers struggle with when they start building.

      If you are very good with a hammer, everything looks like a nail.

      Part of being an expert is knowing limitations, and to remove ego from the equation when building something new.

      In the end we all have a limited amount of resources: time, mental energy, money. If there's an effective NoCode or low code stack that can solve the problem (the problem space itself, scale, future changes), it's irresponsible to ignore it.

      I was always a proponent of a microservice style architecture even for pure Code based platforms. I've seen the kind of nasty you can run into with big monolithic component based architectures. With a microservice architecture and something to operate as the "glue" (NodeRed, n8n, Intregromat, Zapier, etc) between services, you can easily split complex applications up in such a way that Code and NoCode live in harmony. And do it very efficiently with respect to time and resources.

  4. 2

    I think there's few legitimate base for this debate:
    No-Code doesn't mean anti-code!
    There's always a place for developers and their expertise. But not knowing how to code shouldn't stop people from being able to launch their ideas, build businesses, and follow their long-held aspirations.

    It's about empowering entrepreneurs🙌

  5. 2

    How do you do version control and testing with no code? Is there a good tool for that?

    1. 2

      I'm not sure that there is.

      Bubble implements some form of version control to my knowledge, but it is limited to a specific methodology that they impose, and you don't have much flexibility in how you leverage it:

      https://manual.bubble.io/help-guides/maintaining-an-application/version-control

      In traditional code setups, tools like Git give you a tremendous amount of power and control over your branching strategies, and specifically how you deal with multiple developers collaborating on the same codebase. This is why I mention that if you're going to have multiple developers, you're better off going the Code route.

      Bubble does allow for multiple NoCode developers to collaborate on the same codebase, but it's fairly limited, and if you have many developers collaborating it may become difficult reasoning about who made what change and which time.

      As applications become more mature and move from "feature" based development to "bug" based maintenance, one of the key things you need to be able to do in maintaining an application is finding out when a bug was introduced, and being able to look through source control to see what changed at that particular time. This is always my #1 go to tactic when trying to figure out why something broke at a particular time.

      To my knowledge, there aren't any NoCode tools really tackling this problem space. I'd be interested in seeing if one of them tackles it, or at the very least opens things up so that you could leverage existing popular version control tools (like Git).

      1. 1

        Sounds like an opportunity…

  6. 2

    Great write-up. I’ve been bouncing between Code and NoCode myself for a long time. Recently decided to jump into coding full-steam over the past few months because of the greater flexibility and the ability to take high-salary jobs if need be.

    However, after discovering Indie Hackers and Minimalist Entrepreneur over the past week or so, I’m realizing that putting all of my time and effort into learning code may just be another delaying tactic to doing what really matters: starting a business and beginning the process of learning, growing and pivoting. And those aspects would be better served by embracing NoCode for now to quickly validate and test ideas.

  7. 2

    What a fantastic article! Thank you for putting so much work into writing this for us.

    1. 2

      Thanks wirewalker!

  8. 1

    Interesting article! In my opinion coding and no-code will work together and as coding is very popular right now. No-code will get more and more attention each year

  9. 1

    Very nice article, thank you very much!

  10. 1

    This comment was deleted 2 years ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments