Low-Code/No-Code FAQ: 8 Critical Questions About the $65B Boom
The low-code/no-code market is supposedly hitting $65 billion by 2027. Every vendor is screaming about "democratizing development" and "empowering citizen developers." Your CEO forwarded you three articles about it last month.
Here's what those articles don't tell you: low-code platforms are technical debt factories wrapped in a pretty UI. They're not inherently bad — they're just wildly misunderstood by the people buying them.
I've watched companies go from "we'll just build a quick prototype" to having 47 critical business processes running on platforms that three people in the company actually understand. The questions below are what CTOs actually ask me after the honeymoon phase ends.
1. What Happens When Low-Code Generates More Code Than My Dev Team Writes?
This isn't hypothetical. At a Series B fintech I consulted for, their OutSystems deployment was generating 3x more code than their engineering team wrote in a year. The problem? Nobody could explain what any of it did.
Low-code platforms abstract away complexity, which sounds great until something breaks. Then you're staring at auto-generated code that looks like it was written by an alien intelligence. Because it was — it's an abstraction layer on top of an abstraction layer, optimized for the platform's runtime, not human comprehension.
The real issue: your traditional code intelligence tools don't work on this stuff. Static analysis fails because the "real" code is generated at build time. Your dependency graphs are useless because everything routes through the platform's proprietary runtime.
This is where companies realize they need something that can actually reverse-engineer what they've built. Tools like Glue can index low-code outputs the same way they index traditional codebases — discovering features, mapping dependencies, and documenting what actually exists rather than what the platform thinks exists.
2. How Do I Stop Shadow IT Without Becoming the No Police?
You can't. That's the uncomfortable truth.
Business units are going to use low-code platforms whether you approve them or not. Your options are to either acknowledge this reality and create guardrails, or pretend you have control while everything happens behind your back.
I've seen this play out the same way at a dozen companies: Marketing builds a customer portal on Webflow. Sales creates a pipeline management tool in Airtable. Operations automates vendor onboarding with Zapier. All without IT approval, naturally.
Here's what actually works: create a "supported" tier and an "experimental" tier. Supported tier gets your security review, SSO integration, and disaster recovery. Experimental tier is allowed but clearly marked as unsupported with data classification limits — no PII, no financial data, no customer info.
You document everything in both tiers. Not because you're micromanaging, but because when someone leaves and their 47 Zapier workflows break, you need to know what they were actually doing. This is another area where automatic discovery helps — platforms like Glue can map out what features exist across your stack, including the shadow IT stuff, so you at least know what you're dealing with.
3. What's the Real TCO After Year Three?
Nobody talks about this honestly. The first year looks cheap. Year three is when the bills arrive.
Low-code platforms charge per user, per environment, per API call, per row, per execution — pick your poison. That $10k/year Retool license becomes $150k when you factor in the production environment, staging, dev environments for each team, and the "premium" features you discover you can't live without.
But the real cost isn't the platform fees. It's the specialized talent you need to hire because Sarah from Marketing who built that critical workflow got promoted and moved to a different team. Now you need someone who knows both your business logic AND the platform's quirks. Those people charge $150-200/hour as consultants.
One enterprise I know spent $400k on Salesforce licenses and another $800k on consulting fees to maintain the custom workflows their "citizen developers" built. The citizen developers, by the way, had all moved to other roles.
You need to track this stuff. Who owns what? Who last modified it? What's the blast radius if it fails? These are basic questions that become impossible to answer when you have low-code apps scattered across six different platforms.
4. Can I Actually Migrate Off This Platform If Things Go Sideways?
The honest answer from vendors: "Of course, we have export APIs!"
The real answer: Not without rewriting everything from scratch.
Low-code platforms create portability theater. Sure, you can export your data. You might even get some JSON representation of your workflows. But try rebuilding the business logic in actual code and you'll discover that what looked like a simple "send email when status changes" workflow actually has 47 conditional branches, data transformations, and integration points that only make sense within the platform's ecosystem.
I watched a company try to migrate off Mendix after their vendor relationship went south. Six months and $2M later, they'd rewritten about 60% of their applications. The other 40% is still running on Mendix three years later because the migration cost exceeded the value of the features.
Before you commit to any low-code platform, do the exit interview in reverse: What would it take to leave? Document the answer. Get a number. If that number makes you uncomfortable, don't sign the contract.
5. How Do I Enforce Code Review on Visual Workflows?
This is my favorite question because it exposes the fundamental tension in low-code: it's supposed to bypass developer processes, but it still needs developer rigor.
You can't run git diff on a drag-and-drop workflow. You can't leave code review comments on a decision tree built in a visual editor. Most platforms have some version control, but it's a poor imitation of what developers actually need.
What actually happens: someone makes a change to a critical workflow, tests it in production (because dev environments cost extra), and breaks the quarterly board report pipeline at 4 AM. Nobody knows who changed what or why.
The solution isn't to force low-code into git. It's to treat it like infrastructure-as-code: require export to version control on every deploy, mandate approval workflows for production changes, and automatically document what changed and who changed it. You need visibility into your low-code deployments the same way you need visibility into your traditional code.
This is where code intelligence platforms prove their worth — they can track changes across both traditional repos and low-code platforms, giving you a unified view of your entire technical estate.
6. What Happens to Performance at Scale?
Low-code platforms optimize for developer velocity, not runtime performance. That's fine when you're building an internal tool used by 10 people. It becomes a problem when that tool becomes the primary interface for 10,000 customers.
I've seen apps built in Bubble that fell over at 50 concurrent users. The platform wasn't designed for that load. The abstractions that made development easy created performance bottlenecks that no amount of caching could fix.
The worst part? You often don't discover these limits until you're committed. The demo performs great. The prototype works fine. Then you launch and discover that the platform charges you per API call, and your architecture makes 47 API calls per page load.
Before you build anything customer-facing on a low-code platform, run actual load tests. Not the vendor's benchmarks — your real workflows, with your real data, at 10x your expected peak traffic. If it fails, you need to know now, not during your Black Friday launch.
7. How Do I Maintain Security and Compliance?
Every low-code platform claims to be "enterprise-ready" and "SOC 2 compliant." That's meaningless if your citizen developers are building apps that leak PII or expose admin functions to unauthenticated users.
The platform might be secure. The things people build on it probably aren't.
Traditional security scanning doesn't work here. You can't run Snyk or Dependabot on a visual workflow. You need human review, which defeats the whole "move faster" promise of low-code.
What you actually need is automatic documentation of what data flows where. Map your PII. Track which workflows have access to financial data. Document who can modify production systems. This isn't optional — it's table stakes for any regulated industry.
Companies using Glue for this get automatic feature discovery that includes data flow analysis. They can answer "which systems touch customer PII" in seconds instead of weeks. That's the difference between passing an audit and spending six months in remediation.
8. Is Low-Code Actually Faster, or Does It Just Feel Faster?
Here's the uncomfortable truth: low-code is faster for the first 80% of any project. That last 20% takes longer than if you'd just written code.
You hit platform limitations. You need custom code anyway. You spend days fighting the abstraction layer instead of hours writing the actual logic. The "no-code" solution requires three paid plugins and a custom JavaScript block that nobody understands.
I'm not saying don't use low-code. I'm saying be honest about where it fits. Internal tools with straightforward logic? Perfect use case. Complex, customer-facing applications with integration requirements? You're going to suffer.
The companies that succeed with low-code treat it as another tool in the toolbox, not a replacement for engineering. They maintain clear ownership, enforce documentation, and most importantly, they know what they've actually built.
That last part is harder than it sounds. When you have features scattered across GitHub, Retool, Salesforce, and Airtable, nobody has the full picture. You need something that can index all of it, understand the dependencies, and tell you what you actually have. Otherwise, you're flying blind with a $65 billion tailwind pushing you forward.
The question isn't whether to use low-code. It's whether you can maintain it after the initial excitement wears off and the real work begins.