To Code or Not to Code: Pros and Cons of No-Code Website Tools
Insights, delivered.
Whether it’s a website builder (like Wix, Squarespace, or Webflow), a page-builder utility that’s part of a larger ecosystem (like an AMS), or some other low-code/no-code platform, the pros and cons of these types of systems are generally the same. Are these systems the holy grail that they market themselves to be? Or are you better off working with a development team to make your dreams a reality? Of course, the answer is very dependent on your particular use case, but hopefully, these distinctions can help you decide what’s right for your organization.
But first, what qualifies as low-code/no-code?
For this article, we’re defining low-code/no-code as any system that uses a drag/drop type of builder where there is ready-made functionality that can be added with a few clicks or configuration through a GUI (Graphical User Interface). These systems operate without the user having to write any code, or at the very least, only having to write a small amount of code.
Low-Code/No-Code Pros
Accelerated implementation and easy deployment
Because these tools have an array of functionality ready to go, getting something set up and out the door can be a few clicks away.
Builders don’t have to be coders
Traditionally, developers have been the gatekeepers for the creation of new functionality. These systems allow non-coders to potentially spin up new pages, or even new sites without touching a line of code.
Fewer functionality bugs
Many of these platforms rely on building blocks that have been thoroughly tested. Because of that, you won’t have to worry as much about bugs in your code.
Low-Code/No-Code Cons
Lack of flexibility and customization
While the ability to incorporate new building blocks onto your website/application may seem like the ultimate flexibility, anything you want to do beyond that flexibility may require developer intervention. The functionality could be 80% of what you need, but not having that last 20% might be a dealbreaker for you.
May require a developer beyond simple use cases
As mentioned, for that last 20%, you may still need a developer. The problem then becomes compatibility. Your platform (and all its digital environments) may not be built to facilitate development, so the developer may end up writing sloppier and/or inefficient code to be compatible.
Builders may need to still be tech-savvy or have a UX eye
Some platforms use web design/development concepts as a basis for configuring the page to cater to the savvy crowd. These platforms allow for more options to those already familiar with the web, but that comes at the cost of not facilitating the needs of those who just want to make simple text edits to a page.
Many of these tools require the page builder to make design decisions that either the person may not have the expertise or the time to make like padding, alignment, animation, or font size settings.
Scalability, consistency, and maintainability
Speaking of design decisions, these settings are sometimes allowed to be configured on a module-by-module basis. If you created a module in 20 places and you realize you need to make a change globally to all of these modules, you may need to go back and make the change 20 times. Increases in flexibility typically come at the cost of maintainability. And if you’re having multiple people maintain the pages on the site, there is a high likelihood that there will be inconsistent design patterns throughout the site.
Platform-specific
Some of the low-code and no-code tools are provided as a cloud service or as part of an application that you are now locked into moving forward. Enhancements and functionality tied to this proprietary code could potentially not be reusable if you move to a different platform later down the road.
What’s Right for Me?
As with any decision like this, it depends. Based on the pros and cons we’ve discussed in this article, here is a quick breakdown of when a low-code/no-code platform might make sense vs. when it should be avoided:
Good for low-code/no-code
Smaller sites with 10 pages or less e.g. a portfolio site (like this one from Pretty Useful Co.) or one-off marketing one-pagers like this one.
- When your list of requirements matches exactly the functionality that the platform provides e.g. you need to output a visual report of data in your CRM and your CRM has the plug/play capability.
Note: If using a platform that requires design decisions, it’s important to have a dedicated design team that is trained in using and is responsible for this platform.
Bad for low-code/no-code
Dense information-heavy sites that have many interrelated pieces of content or data (e.g. association websites like the American Association of Nurse Practitioners or government websites like the Texas Department of Information Resources.
Custom requirements that are tied to your organization’s business logic and/or display needs. A good example of this is when your design team has a particular design or user flow that they would like to implement but it’s not compatible with the plug/play platform capabilities or your organization needs specific integrations between platforms that don’t have plug/play integrations available.
When you don’t have a dedicated team who wants or has the expertise to make piecemeal design and/or UX decisions.
