Why I threw away my low-code stack mid-build
How agentic development changes the low-code trade-off
On 5 April this year, I made a decision that cost me several weeks of work. I abandoned the entire front-end and business logic layer of Eva — the UI scaffolding I’d built in FlutterFlow, the workflow automation I’d configured in BuildShip — and started again in Next.js.
The proximate cause was a build pipeline blocker that had been open for a while. FlutterFlow’s build was desynced; a support ticket was open; I was waiting on someone else’s platform to fix a problem in my project. Anyone who has spent serious time in a low-code tool recognises this moment. You hit the ceiling, and the ceiling belongs to the vendor, either as a defect in their own platform or simply a tool limitation requiring you to compromise on your optimal design.
Visual tools trade opacity for speed. You move faster in the early stages because someone else has written the plumbing, made the rendering decisions, and abstracted away the things you’d otherwise have to configure. The trade-off is that when something goes wrong, or when you need something the platform didn’t anticipate, you’re dependent. The logic lives in their system, not yours.
I’ve known this trade-off for years. Most builders who’ve used these tools have. I accepted it consciously when I chose FlutterFlow.
What I hadn’t fully reckoned with was how that trade-off changes when your primary developer is an AI agent.
In my recent attempt to adopt AI wherever and however I can, I started using Claude Code as the principal builder for Eva. Not as a code completion tool or a search assistant; as the agent that reads the codebase, writes the implementation, runs the tests, and iterates. That requires the agent to have genuine access to the full codebase: readable, editable, testable files in a repository that it can reason about holistically.
Of course, FlutterFlow doesn’t work like that: no low-code tool does. Prioritising access to the code base works precisely against the foundational principles of low-code. The UI logic is stored in FlutterFlow’s own system. BuildShip’s workflow logic lives in visual nodes on its platform. Neither produces a plaintext codebase that Claude Code can read in full. The agent could see the Supabase layer. It could see anything I’d handwritten. But the UI and the business logic were black boxes. The agent was working half-blind.
This wasn’t a tooling quirk I could work around. It was structural. The whole point of an agentic build is that the agent owns the codebase end to end — can refactor, can add tests, can trace a bug from the UI layer down through the API to the database and back. With FlutterFlow and BuildShip in the stack, that wasn’t possible. I was using a primary development tool that couldn’t fully develop my application.
So I stopped.
I migrated to Next.js for the frontend, GitHub Actions for CI, and Vercel for hosting. Next.js API routes replaced the BuildShip workflows. The Supabase layer — auth, schema, RLS policies — carried over unchanged. About six weeks of FlutterFlow UI work did not.
What happened after the migration is the part worth talking about, honestly. In roughly two weeks since the switch, the build has covered more ground than the preceding six weeks combined. LinkedIn authentication end-to-end. Home screen, add contribution, profile, and contribution detail. GDPR data export and account erasure. Organisation identity with logo enrichment. A full CI pipeline running 364 491 (at the last count) tests on every commit. The agent owned all of it because it could finally see all of it.
The broader argument, for anyone building with AI tools right now: low-code’s core value proposition was closing the gap between human intent and working software. For a long time, that gap was real. Humans write code slowly, and visual tools have helped.
That gap is closing from the other side now. An AI agent that writes production-quality code in minutes doesn’t need the visual scaffolding in the same way. What it needs is transparency — a codebase it can read, run, and reason about without impediment. Low-code tools can’t provide that. They were never built to.
The speed advantage shrinks. The opacity cost grows. The trade-off that made low-code worthwhile for this kind of build no longer balances.
One honest caveat. This argument holds when the builder has enough technical judgement to supervise an agentic build (and it’s arguably questionable whether I do, despite my 1993 Bachelor’s degree in Computer Science and a background in software development ending in the C++ days) - to review what the agent produces, catch its mistakes, and direct it meaningfully. Not everyone is there yet, and for a genuinely non-technical founder who cannot evaluate code, low-code still offers something real.
But for anyone building with an AI agent as primary developer: the stack that serves the agent serves the build. Low-code, for all its early convenience, doesn’t serve the agent. I found that out six weeks in, one support ticket too late.