Low-code and custom code don't have to be enemies.
I've spent years working with both. I've built systems in Monday.com, Retool, and Make.com. I've written custom Rails applications, designed database schemas, and deployed production infrastructure.
The best systems I've built use both — not as a compromise, but as a strategy.
The false dichotomy
The tech industry loves binaries. Custom vs. no-code. Build vs. buy. "Real" engineering vs. citizen development.
This framing misses the point.
The question isn't which approach is better. The question is: what problem are you solving, and what's the right tool for that problem?
Some problems need custom code. Some don't. Most real-world systems have both kinds.
Where low-code wins
Low-code platforms — Monday.com, Airtable, Retool, Make.com — excel at certain things:
Fast iteration. Building a form that triggers a workflow takes minutes in Make.com. Building the same thing from scratch takes days. For business logic that changes frequently, the ability to iterate quickly is worth more than architectural purity.
Visual interfaces for non-technical users. Operations teams can manage their own workflows in Monday.com. They can't manage Rails controllers. If the people closest to the problem can modify the solution, problems get solved faster.
Commodity functionality. User authentication, payment processing, email delivery — these are solved problems. Using a platform that handles them means not rebuilding what thousands of teams have already built.
Prototyping. Before committing to a custom solution, build a prototype in low-code. If the requirements change (they will), you haven't invested months in the wrong direction.
Where custom code wins
Custom software wins when:
Scale demands it. Low-code platforms have limits. Monday.com caps at 30,000 items per board. Retool dashboards slow down with complex queries. At some point, you need real infrastructure.
Data models are complex. Relational databases model reality better than spreadsheet-style structures. When your data has real relationships — orders to customers to products to inventory — custom data models are worth the investment.
Performance matters. SQL queries complete in milliseconds. API-heavy workflows introduce latency at every step. When users notice slowness, it's usually because you've daisy-chained too many integrations.
Differentiation is the goal. If your competitive advantage depends on a unique process or customer experience, don't build it on a platform your competitors can copy.
The hybrid approach
The systems I'm proudest of aren't pure low-code or pure custom. They're hybrids that use each approach where it makes sense.
Here's a real example:
A client running tens of thousands of orders per year needed:
- Field team management (task assignment, status updates, mobile access)
- Order processing and CRM
- Financial reporting and payroll calculations
The solution:
| Component | Technology | Why |
|---|---|---|
| Field ops | Monday.com | Task management is Monday's strength. Teams already knew it. |
| CRM + Orders | Custom PostgreSQL | Complex data relationships. High volume. Need for SQL analytics. |
| Admin dashboards | Retool | Fast to build. Internal users only. Easy to modify. |
| Integrations | Make.com | Connects systems without custom code. |
Each layer does what it does best. The field team doesn't notice they're using a hybrid stack — they just see Monday.com. The finance team doesn't care that their reports come from a custom database — they just see accurate numbers.
The glue layer
The hardest part of hybrid systems isn't choosing the tools. It's connecting them.
Every connection is a potential point of failure. Data can get out of sync. Formats can mismatch. APIs can change. Rate limits can bite.
What makes hybrid systems work:
One source of truth. Pick one system to own each piece of data. Other systems read from it. Never let the same data be edited in two places.
Clear boundaries. Define exactly what each tool is responsible for. Monday.com manages tasks; it doesn't try to be a CRM. The database stores customer data; it doesn't try to manage workflows.
Idempotent integrations. Design automations to handle being run twice. If Make.com processes the same webhook twice, the system should still work correctly.
Monitoring. Hybrid systems fail silently. Build in visibility — logs, alerts, reconciliation reports — so you know when something breaks.
The migration path
Most companies don't start hybrid. They start with low-code, hit limits, and panic.
The transition works better when planned:
Phase 1: Low-code foundation. Start with platforms. Ship fast. Learn what the business actually needs.
Phase 2: Extract critical paths. When low-code limits hurt, move those specific pieces to custom solutions. Don't rebuild everything — just the bottlenecks.
Phase 3: Hybrid operation. Run both in parallel. Keep low-code where it works. Use custom code where it's needed. Invest in the glue layer.
This is the path I took with the client I mentioned. We didn't throw out Monday.com when we built the custom database. We kept Monday.com for what it does well and built around it.
The real skill
The real skill isn't knowing how to build custom software. It isn't knowing how to use low-code platforms. It's knowing which to use when.
This requires understanding both sides. Engineers who've never touched no-code dismiss it too quickly. Low-code enthusiasts who've never written production code underestimate what it enables.
The best solution is usually obvious once you understand the tradeoffs. The problem is that most teams only understand one side.
The questions I ask
When deciding how to build something:
How often will this change? High change = favor low-code. Stable requirements = custom code is fine.
Who needs to modify it? Technical team = custom is fine. Business users = low-code.
What's the data volume? Low volume = anything works. High volume = think carefully about platform limits.
Is this a differentiator? Commodity = low-code or buy. Competitive advantage = build custom.
What's the cost of failure? Low stakes = iterate fast with low-code. High stakes = invest in reliability.
Most systems are a mix. The art is knowing where to draw the lines.
For questions about hybrid architectures and platform choices, reach out here.