Low-code platforms have had a real moment over the last several years, and for good reason. Tools like Bubble, Retool, Webflow, Airtable, Make, and Zapier have enabled businesses to build applications and automate workflows faster and at lower cost than traditional development.

But like most tools, they're right for some problems and wrong for others. This guide is an honest look at when low-code genuinely makes sense, when it doesn't, and how to decide which category your project falls into.

We'll name specific platforms throughout because the nuances matter and vague generalities aren't useful.

What low-code actually means

"Low-code" and "no-code" are often used interchangeably, but there's a loose distinction worth understanding.

No-code platforms are designed to be used without writing any code at all. Webflow lets you build and design websites visually. Bubble lets you build web applications with a drag-and-drop interface. Zapier and Make let you automate workflows by connecting apps with a visual trigger-and-action builder. Airtable gives you a database-spreadsheet hybrid with built-in views and automations.

Low-code platforms typically assume some technical capability, but minimise the amount of code required. Retool is a good example, it's designed for building internal tools quickly, and a developer can produce a functional admin panel in hours rather than weeks, by assembling pre-built components and writing lightweight logic.

In practice, most real-world implementations blur these categories. A Bubble application for a non-trivial use case requires someone who understands data modelling. A Make (formerly Integromat) workflow that handles business-critical data requires someone who can think through edge cases and error handling. "No-code" often means "no custom code required by the platform" rather than "no skill required."

When low-code genuinely makes sense

There are several scenarios where reaching for a low-code tool is the right call.

Internal tools and dashboards. If your team needs a way to view and edit data, customer records, inventory, job statuses, anything operational, a Retool or Appsmith build can be done in a day or two where a custom build would take weeks. The interface doesn't need to be beautiful, it just needs to work. Low-code wins here most of the time.

Workflow automation. If you're moving data between systems, sending notifications based on triggers, or automating routine tasks, Zapier or Make are often the fastest and most maintainable solutions. A developer who writes custom code to pull data from one system and push it to another is doing work that Make was built to do. Use the right tool.

MVPs and early-stage products. If you're trying to validate whether a product idea is worth investing in, building it in Bubble or a similar platform before committing to a full custom build is often sensible. You can get something in front of real users in weeks rather than months, and if the concept doesn't land, you haven't spent $80,000 finding that out. It's also worth knowing that custom software costs significantly less than it used to, so the bar for when a custom build makes sense has shifted.

Simple form-and-database applications. If the core of what you need is "people fill in forms, data is stored, someone reviews it," many low-code tools handle this elegantly. Airtable with Zapier automations can satisfy this kind of requirement with relatively little effort.

Non-technical operators who need to maintain it. Low-code platforms often have interfaces that non-developers can manage. If the person maintaining the system after launch isn't a developer, a low-code platform with a visual editor is sometimes a more sustainable choice than custom code only a developer can modify.

When low-code hits walls

Low-code platforms are opinionated. They've made decisions about how things work, and those decisions were made for the common case. When your requirements diverge from the common case, you start hitting limits.

Complex custom logic. Bubble has a visual logic editor, and it's capable, up to a point. When business rules get complicated, implementing them visually becomes genuinely harder than writing code. You end up with deeply nested conditional blocks that are difficult to read, debug, and maintain. For applications where the business logic is intricate, custom development is usually more reliable.

Performance requirements. Bubble in particular has known performance constraints for data-heavy applications. When you're working with large datasets, complex queries, or real-time updates, custom-built applications on purpose-built infrastructure will significantly outperform what a low-code platform can deliver.

Custom integrations. Low-code platforms support common integrations well, Stripe, Mailchimp, Google Sheets, major CRMs. When you need to connect to something less standard, particularly older enterprise systems, government APIs, or industry-specific platforms, you often need custom code. Zapier's library of integrations is extensive but not infinite.

Specific security and compliance requirements. If your application handles sensitive data and you have specific requirements around data residency, audit logging, access controls, or compliance frameworks (healthcare, financial services, legal), low-code platforms may not give you the control you need. Custom development lets you implement exactly what's required; platform limitations may make that impossible in a low-code environment.

Mobile performance. Web applications built in Bubble are not native mobile apps. They'll work in a mobile browser, but they won't deliver a native mobile experience. If your users need a native app, low-code web application builders aren't the answer.

The lock-in problem: what happens when you outgrow your platform

This is the issue that doesn't get enough attention early in a project.

When you build in Bubble, your application lives in Bubble. Your data lives in Bubble's database. Your business logic is expressed through Bubble's visual editor. If Bubble changes its pricing, if the platform is acquired or shut down, or if your application grows beyond what Bubble can handle, your only option is to rebuild from scratch elsewhere.

This has happened. Companies have built significant applications on platforms that have changed their pricing dramatically or sunsetted features, and faced an expensive choice between paying whatever the platform now charges or undertaking a complete rebuild. If you're at that point, our guide on replacing legacy software in Australia covers what a migration actually involves.

It's also worth noting that migrating data out of some low-code platforms is genuinely difficult. Data export options vary, and some platforms have made it harder than it should be to take your data with you.

None of this means you shouldn't use low-code platforms. It means you should go in with clear eyes about the trade-off. You're trading ownership and portability for speed and cost, and for many projects that's the right trade. Just make sure you're making it consciously, not discovering it later.

Low-code + custom hybrid approaches

Some of the most cost-effective architectures combine both.

A common pattern: use Retool or a similar tool for the internal-facing parts of an application, admin panels, operational dashboards, data management views, and write custom code for the customer-facing parts where design, performance, and experience matter. The internal tools get built cheaply and quickly; the external product gets the investment it needs.

Another pattern: use Zapier or Make for the integrations and automations between systems, and write custom code only where those tools can't reach. The automation layer is low-code; the core application logic is custom.

A third pattern: use Airtable or Notion as the data layer for an early-stage product, connect it to a lightweight custom API, and build a proper database later when the data model has stabilised through real use. You're not building the database twice, you're deferring the investment until you know what you actually need.

What a "low-code developer" actually does

There's a misconception that low-code platforms eliminate the need for developer skill. They don't, they shift what kind of skill is required.

A good low-code developer understands data modelling, knows how to design a system that won't paint itself into a corner, can think through edge cases and error states, and understands the limits of the platform they're working in. They can tell you when a platform is right for the problem and when it's going to make things harder.

The difference between a good low-code developer and someone who's just learned to use the tools is most visible six months later, when the first developer's work is still running smoothly and the second developer's work is held together with workarounds.

Code Workshop's view: we use whatever tool is right

We're not ideologically committed to custom code. We use low-code platforms when they're the right answer for a project, and we'll tell you honestly when we think they are. When AI is part of the picture, our AI development services page explains how we approach building AI-powered tools for Australian businesses.

If you're building an internal tool for a small team and the requirements are straightforward, we'd probably suggest Retool or a similar platform over a fully custom build. If you're automating a workflow between standard SaaS tools, we'd start by looking at what Zapier or Make can do. If you need a quick MVP to test an idea, we might suggest Bubble.

But if your application has complex logic, performance requirements, specific security needs, or needs to scale, we'll say so and explain why custom is the better choice for your situation.

The right answer depends on your specific project. That's the conversation we like to have.

We're based in Bowral, NSW, and we work with businesses across Sydney and Australia. If you're not sure whether your project is a low-code or custom build, we're happy to help you figure it out.

Book a chat with us