Hybrid development: where Low-Code meets traditional code
Design Process
13 min read
Software development is constantly changing.
New frameworks appear. Platforms become more capable. Infrastructure becomes easier to deploy. Artificial intelligence is changing how developers interact with APIs, tools and data.
But one of the most important changes is not the arrival of another programming language or framework.
It is the disappearance of the boundary between low-code development and traditional software development.
For years, teams tended to treat the two approaches as opposites.
Low-code meant speed, visual development and simpler applications.
Traditional development — often called pro-code — meant flexibility, performance and full technical control.
That distinction is becoming increasingly outdated.
Modern software products often benefit from both.
A team might build the customer-facing interface in Webstudio, connect existing Bubble.io workflows, use Supabase for authentication and application data, embed part of an existing web application inside a mobile WebView, expose native functionality through a JavaScript bridge, and connect AI tools or external systems through MCPs.
Some parts are visual.
Some parts are coded.
Some run in the browser.
Some run natively.
Some are managed services.
The result is not a low-code application with a few customisations.
It is a hybrid software architecture.
And when it is designed correctly, hybrid development can give companies something neither approach delivers as effectively on its own:
speed without giving up control.
Hybrid development is an approach to software engineering that combines low-code or no-code platforms with traditional custom code within the same product or technology stack.
Instead of deciding that an entire application must be built using one methodology, the development team chooses the most appropriate tool for each part of the system.
A visual development platform might handle:
content-driven pages
dashboards
internal tools
forms
standard CRUD interfaces
workflow configuration
simple API integrations
Traditional code might handle:
specialised business logic
advanced integrations
native mobile functionality
security-sensitive operations
performance-critical processes
complex data transformations
custom protocols
proprietary algorithms
The objective is not to minimise code.
It is to minimise unnecessary engineering.
If a visual platform can reliably solve a problem in two hours that would take two days to build manually, rebuilding it from scratch rarely creates additional value.
At the same time, forcing a complex product requirement into a low-code platform simply because the rest of the application was built there can create unnecessary limitations.
Hybrid development avoids both extremes.
Companies often begin with:
Should we use low-code or custom development?
A better question is:
Which parts of this system benefit from low-code, and which parts require custom engineering?
The answer frequently changes from one part of the product to another.
A marketing website does not require the same architecture as a payment engine.
An administrative dashboard does not require the same implementation as a real-time mobile tracking system.
A workflow that sends an email after a form submission should not necessarily require the same engineering effort as a proprietary recommendation algorithm.
Hybrid development allows these differences to be reflected in the architecture.
Low-code platforms reduce the amount of manual software engineering required to create common application functionality.
Instead of writing every interface, layout, form and workflow from scratch, developers work with visual systems and reusable components.
This can significantly shorten the path from an idea to working software.
Speed is the most obvious advantage.
Visual development tools can make it possible to create interfaces, validate concepts and connect data much faster than conventional implementation.
This is especially valuable during the early stages of a product.
Instead of spending weeks building infrastructure before users can interact with anything, teams can create functional experiences quickly and start collecting feedback.
The result is a shorter feedback loop:
Build → Test → Learn → Improve
rather than:
Specify → Build for months → Launch → Discover assumptions were wrong
That difference can have a larger business impact than almost any individual technology decision.
A significant percentage of business software consists of familiar patterns.
Forms.
Tables.
Authentication flows.
Dashboards.
Filters.
Content pages.
Administrative screens.
Basic API requests.
Developing every one of those patterns manually may provide technical control, but it does not automatically provide business value.
Low-code platforms allow teams to reuse established building blocks and focus engineering time on the parts of the application that actually differentiate the product.
Visual development platforms can also reduce the distance between design and implementation.
A designer or product specialist can often understand the structure of a Webstudio or Bubble.io application much more easily than a conventional frontend codebase.
That does not eliminate the need for developers.
It changes where developers spend their time.
Instead of manually implementing every visual detail, engineers can focus on architecture, integrations, reusable logic and the parts of the system that genuinely require technical depth.
Low-code platforms are becoming more capable, but custom code remains essential.
Traditional software development gives engineers direct control over the behaviour of the system.
That matters whenever product requirements move beyond the abstractions provided by the platform.
With custom code, the question is usually not whether something is available as a predefined component.
The question is whether it can be engineered.
This is critical for products with:
unique interaction patterns
proprietary business logic
unusual integrations
specialised security requirements
advanced native-device functionality
performance-sensitive workloads
complex background processing
The further a product moves away from standard application patterns, the more valuable direct engineering control becomes.
Visual platforms necessarily introduce abstractions.
Those abstractions are often worth the trade-off, but there are situations where engineers need tighter control over execution, rendering, networking or memory.
Traditional development allows the team to optimise the exact operation that creates a bottleneck.
Hybrid architecture makes it possible to optimise those specific areas without rebuilding the entire application.
A web interface running inside a mobile application cannot automatically access every capability of the device.
Features such as:
biometrics
camera access
push notifications
filesystem access
Bluetooth
device sensors
secure native storage
may require native implementation.
This is where hybrid mobile development becomes particularly powerful.
Hybrid development works best when it is planned intentionally.
The objective is not to randomly combine technologies.
Each layer should have a clear responsibility.
At Limy, this can mean combining technologies such as:
Webstudio + Bubble.io + Supabase + WebViews + native JavaScript bridges + custom APIs + MCP-based connections.
Each technology solves a different type of problem.
The result is a system where complexity is placed in the layer best equipped to handle it.
One of the most common hybrid development patterns is using low-code for the visible application structure while traditional code handles specialised logic underneath.
For example, a company might use a visual platform to create:
navigation
user-facing screens
account pages
forms
dashboards
reporting interfaces
The difficult calculation behind those interfaces might run in a custom backend service.
Imagine a financial application.
The user interface may contain relatively conventional screens:
enter parameters
select an account
configure assumptions
view results
There is little advantage in manually coding every one of those screens.
But the financial calculation engine itself could contain proprietary formulas, risk modelling and optimisation logic.
That is where traditional development provides value.
The frontend and the computational core do not need to be built using the same methodology.
WebView architecture is a particularly useful example of hybrid development.
A WebView allows a web application or web-based interface to run inside a native mobile application.
This can make it possible to reuse existing web interfaces instead of rebuilding every screen separately for iOS and Android.
However, the application can still retain access to native functionality.
A native JavaScript bridge creates communication between the web layer and the native mobile layer.
Conceptually:
Web interface → JavaScript bridge → Native application
and:
Native application → JavaScript bridge → Web interface
Suppose a WebView interface needs the user to scan a QR code.
The web layer can request:
openScanner()
The JavaScript bridge passes the request to native code.
The native mobile layer opens the camera and performs the scan.
The result can then be returned through the bridge to the web application.
The interface remains web-based while the feature itself uses native device functionality.
Without a bridge, teams may have to recreate a significant amount of application functionality separately for:
web
iOS
Android
A hybrid approach can allow much more of the application to remain shared.
Native development is then reserved for the areas where it provides a genuine advantage.
That can reduce development time while still allowing access to capabilities that browsers cannot provide effectively.
Hybrid applications become much easier to manage when different frontend technologies share a common backend.
This is one reason Supabase fits well into hybrid architecture.
A Webstudio frontend, Bubble.io workflow, custom JavaScript application and mobile client can interact with the same underlying application data.
Instead of each interface becoming its own isolated system, Supabase can provide a common data layer.
Depending on the application, that can include:
PostgreSQL database
authentication
file storage
APIs
row-level security
real-time functionality
server-side functions
Consider a business platform containing:
Public website
Built in Webstudio.
Customer portal
Built partly using Bubble.io.
Mobile application
Built using a WebView plus native functionality.
Administration interface
Built using another internal interface.
All four experiences can still communicate with the same Supabase backend.
This reduces duplication and makes gradual technology changes much easier.
The frontend can evolve without requiring the entire system to be replaced.
Webstudio is particularly useful in a hybrid architecture when teams want visual control over frontend development while retaining the ability to connect the interface to external systems.
A website does not need to become a monolithic application simply because it contains dynamic functionality.
Webstudio can handle the presentation layer while APIs and backend services handle application logic.
For example:
Webstudio → API / connector → Supabase → Business logic
Or:
Webstudio → Existing Bubble.io application → Supabase / external services
This separation is valuable because the marketing and presentation layer can evolve independently from the product backend.
Companies that already have substantial functionality built in Bubble.io do not necessarily need to rebuild everything to adopt another technology.
This is one of the most important advantages of hybrid development.
Migration does not need to happen all at once.
An existing Bubble.io application might contain:
business workflows
customer data
internal administrative logic
integrations
API workflows
years of accumulated product behaviour
Replacing all of that simultaneously introduces significant risk.
Instead, a team can expose or connect the necessary functionality and gradually introduce new components.
For example:
New Webstudio frontend → Connector / API → Existing Bubble.io workflows
Another part might use:
Mobile application → Custom API → Supabase → Bubble.io integration
Hybrid development allows existing systems to become components of the new architecture rather than obstacles to it.
Rewriting an entire working product is rarely as simple as it appears.
Existing applications contain years of edge cases and business rules that may not be fully documented.
A gradual hybrid migration lets teams modernise one layer at a time.
That can mean:
introducing a new frontend
retaining existing backend workflows
moving selected data to Supabase
replacing bottlenecks with custom code
gradually decommissioning old components where it makes sense
This is usually much lower risk than attempting a complete rewrite.
As AI becomes part of software products and development workflows, another integration layer is becoming increasingly relevant: MCPs.
MCP-based integrations can provide a structured way for AI systems and agents to access tools, services and contextual information.
In a hybrid architecture, that can sit alongside traditional APIs and platform connectors.
Conceptually:
AI / Agent → MCP → Application tools → Supabase / APIs / business systems
This does not replace conventional APIs.
It introduces another way for software systems to expose useful capabilities to AI-driven workflows.
A product might therefore combine:
traditional REST APIs for application traffic
low-code connectors for standard integrations
custom services for specialised operations
MCPs for AI-accessible tools and context
Again, the architectural principle remains the same:
Use the interface that best fits the problem.
Integrations are another area where hybrid development performs particularly well.
Many external services expose straightforward APIs.
There is little reason to manually engineer every request if a platform connector can reliably handle it.
But enterprise integrations are not always straightforward.
A system may require:
unusual authentication
custom signing
complex transformation
high data volumes
retry systems
queues
strict security controls
legacy protocols
A low-code connector may still handle the standard integrations while traditional code handles the difficult ones.
This prevents the architecture from becoming either unnecessarily complicated or artificially constrained.
Low-code is often associated with prototypes.
That is useful, but the relationship between prototype and production does not need to be binary.
A company can use low-code to validate:
user journeys
navigation
workflows
business assumptions
pricing
onboarding
market demand
After validation, engineers can examine the system and decide what should remain and what should be replaced.
Some components may already be perfectly suitable for production.
Others may need to move to custom infrastructure.
This creates a much more efficient development strategy.
A prototype does not automatically need to be discarded.
If a component:
performs well
is secure
is maintainable
satisfies the product requirements
then rewriting it simply because it was created with low-code may provide no business benefit.
Hybrid development encourages teams to make that decision based on engineering requirements rather than ideology.
A realistic modern application might look something like this:
Webstudio → API / Logic → Supabase
with additional connections to:
Mobile WebView
native iOS / Android functionality
JavaScript bridges
Bubble.io workflows
custom backend services
MCPs and AI agents
There is no single technology responsible for the entire product.
And that is precisely the point.
Each layer handles the work for which it is best suited.
Low-code and visual development reduce implementation time for conventional functionality.
Custom engineering effort can then be concentrated on the components that genuinely require it.
The result can be a significantly shorter development cycle.
Developer time is expensive.
The goal should not be to eliminate developers, but to avoid using expensive engineering time for problems that have already been solved.
If a visual tool can create a reliable content page, form or dashboard, developers can spend their time on more valuable problems.
Pure low-code architecture can become restrictive when requirements exceed the platform's capabilities.
Hybrid architecture provides an escape route.
A custom service, JavaScript component, native module or API can be introduced where necessary.
The entire product does not need to be migrated simply because one feature is difficult.
The opposite problem also exists.
Building every interface, content system, administrative screen and integration manually provides enormous control but can consume substantial development time.
Hybrid development allows the team to reserve that control for areas where it matters.
Many companies already have working software.
The challenge is not always building a new product.
It is improving an existing one without breaking the business.
Hybrid architecture makes gradual replacement possible.
Hybrid development is not automatically simpler.
Poorly designed hybrid systems can become more complicated than either low-code or traditional architecture alone.
There are several risks to manage.
Using ten tools because each one solves a small problem can create unnecessary operational complexity.
Every additional platform introduces:
another dependency
another billing model
another authentication system
another potential failure point
another technology the team must understand
The objective is not to use as many technologies as possible.
It is to use the minimum combination that solves the product effectively.
One of the most dangerous hybrid architecture problems is logic scattered everywhere.
For example:
some validation in Bubble.io
some validation in JavaScript
another rule inside Supabase
another copy inside the mobile application
Now nobody knows which implementation is authoritative.
Important business rules should have a clearly defined source of truth.
Low-code platforms can create dependency on platform-specific functionality.
That is not automatically a problem.
Every technology creates some degree of dependency.
The important question is whether critical data and business logic can be accessed or moved if the architecture changes later.
Good hybrid architecture creates boundaries around platform-specific functionality.
More connections mean more security boundaries.
A hybrid application may contain:
frontend credentials
backend APIs
database permissions
connector authentication
native application permissions
MCP tool access
These boundaries need to be designed deliberately.
Hybrid development should never mean placing privileged business logic directly into a frontend simply because it is convenient.
At Limy, hybrid development means choosing technologies according to the role they need to perform rather than forcing an entire application into one platform.
That can include combinations of:
For visually flexible websites and frontend experiences where rapid design iteration is valuable.
For integrating with existing Bubble.io applications and preserving useful workflows instead of rebuilding functioning systems unnecessarily.
For shared application data, authentication, storage, real-time capabilities and backend infrastructure.
For reusing web-based application interfaces inside mobile applications where that architecture makes sense.
For connecting WebView interfaces with native iOS and Android functionality.
For features that require more control, specialised behaviour or performance than a visual platform provides.
For connecting AI-enabled systems and agents with tools, application capabilities and structured context.
The important part is not any individual technology.
It is how the technologies work together.
Hybrid development is particularly effective when a company:
already has a working low-code application but needs functionality beyond the platform
wants to modernise an existing Bubble.io product gradually
needs both web and mobile experiences
wants to reuse a web application inside a native mobile shell
requires native mobile features alongside web-based interfaces
needs to launch and validate a product quickly
has specialised backend or integration requirements
wants a visual frontend connected to a more powerful custom backend
needs to introduce AI or MCP-based integrations into an existing system
wants to avoid an expensive full-platform rewrite
It is less about the size of the company and more about the shape of the problem.
A successful hybrid architecture needs rules.
Every major component should have a clear responsibility.
For example:
Webstudio → presentation
Supabase → data and authentication
Native layer → device functionality
JavaScript bridge → communication
Bubble.io → existing workflows
Custom services → specialised logic
MCP → AI/tool access
That separation makes the system easier to understand and maintain.
Where practical, important application data should live in systems that expose clear interfaces and standard formats.
Your business should not become dependent on a visual interface simply because that is where the data happened to originate.
Privileged operations belong behind a trusted backend boundary.
Frontend applications should not contain secrets or unrestricted credentials.
The fact that part of an application is low-code does not change fundamental security principles.
Hybrid products depend heavily on connections.
Document:
APIs
webhooks
JavaScript bridge messages
Supabase functions
Bubble.io workflows
MCP tools
authentication boundaries
The architecture becomes much easier to maintain when the contracts between components are explicit.
Good architecture assumes that technology will change.
A specific frontend, workflow system or AI integration may not remain the best choice forever.
If components communicate through clean boundaries, one layer can be replaced without rebuilding everything else.
That is one of the biggest long-term benefits of hybrid development.
Hybrid software development combines low-code or no-code technologies with traditional custom programming.
Instead of using one methodology for an entire application, developers select the most appropriate approach for each component.
Not exactly.
Hybrid mobile development generally refers to mobile applications that combine web technologies with native application functionality.
Hybrid software development is broader.
It can include combinations of low-code, pro-code, visual frontend development, custom APIs, managed backend services, native applications and AI integrations.
Yes.
Modern low-code platforms commonly provide APIs, webhooks, custom code components and integration points that allow them to work with traditionally developed systems.
A low-code interface can call a custom backend, while custom applications can interact with workflows created in low-code platforms.
Yes.
Existing Bubble.io applications can form part of a broader architecture through APIs, workflows and connectors.
This can allow teams to modernise an application incrementally instead of rebuilding the entire product.
Supabase can provide a common backend for applications built using multiple frontend technologies.
Web applications, mobile clients, visual development platforms and custom code can interact with the same data and authentication layer.
A JavaScript bridge allows code running in a web environment, such as a WebView, to communicate with native mobile code.
This makes it possible for web-based interfaces to request native functionality such as camera access, biometrics or device storage.
MCP can provide a structured way for AI systems and agents to access tools, data and application functionality.
It can coexist with traditional APIs, database connections and low-code integrations as another interface within a hybrid architecture.
The debate between low-code and traditional development assumes that software products must belong entirely to one category.
Modern applications increasingly show that this assumption is unnecessary.
Low-code is excellent at accelerating common development tasks.
Traditional code is excellent when software requires deep control.
Web technologies make interfaces portable.
Native code provides access to the device.
Supabase can provide shared infrastructure.
Webstudio can accelerate frontend development.
Bubble.io can preserve and expose established application workflows.
MCPs can create new interfaces between AI systems and software capabilities.
The strongest architecture may use several of these approaches together.
The objective is not to build a product with the least code.
It is not to build a product with the most sophisticated technical stack either.
The objective is to build software that is fast to develop, reliable to operate, flexible enough to evolve and appropriate for the problem it needs to solve.
That is where hybrid development becomes valuable.
Use low-code where abstraction saves time. Use traditional code where control creates value. Connect the two through a well-designed architecture.
That is not a compromise between two development methodologies.
It is increasingly what modern software development looks like.
