Our CEO Wants No-Code in Production. I Disagree — And I'm Ready to Quit

I have 25 years of experience in web development. I've seen technologies come and go, stacks rise and fall. But what's happening now in our company has pushed me to the edge — and I'm ready to walk away.

Our CEO has decided that we should adopt no-code platforms — specifically Lovable and Base44 — for production development in our mature product. Not for prototypes. Not for internal tools. For the actual product that customers pay for. I believe this is a catastrophic mistake, and here's why.

The Technical Nightmare

Incompatible tech stacks. Our product runs on PHP, Python (FastAPI), and Vue.js. Lovable generates React code. Mixing different frontend frameworks in a single product means losing manageability. You can't share state cleanly between Vue and React components. You can't maintain a consistent design system. You end up with two parallel frontends duct-taped together.

Integration hell. Every update to the Lovable-generated modules breaks authentication with our Python services. Cache format mismatches, CORS issues requiring separate deployment rules, token-based auth that works differently across the two stacks — it's a constant stream of firefighting.

CI/CD fragmentation. We now need three separate pipelines: one for PHP, one for Python+Vue, and one for Lovable. Unified testing across all three is impossible without building an elaborate layer of workarounds — which itself becomes a maintenance burden.

Logging chaos. Errors from the PHP backend go to Kibana. Python errors go to Sentry. Lovable errors go to... stdout? Its own internal console? When a user reports a bug, we now have to check three completely different systems to trace what happened. Cross-service debugging becomes a nightmare.

The Supabase trap. Lovable uses Supabase as its default database. Our production infrastructure runs PostgreSQL with carefully tuned schemas, migrations, and replication. Everything built in Lovable's Supabase will eventually need to be migrated to our PostgreSQL — negating whatever time was supposedly saved by using no-code in the first place.

The Process Degradation

Documentation collapse. When product managers can "see" a working interface generated by Lovable, they stop writing detailed specifications. Why document edge cases, validation rules, and error states when the screen "already works"? Except it doesn't — it just looks like it does. The validation is missing. The error handling is nonexistent. The accessibility is broken.

The designer illusion. Designers create beautiful interfaces in the no-code tool without implementing any real business logic. No input validation. No error states. No loading indicators. No accessibility. They hand off something that looks finished but is actually a hollow shell. Then developers are told to "just connect it to the backend" — as if that's the easy part.

Untestable code. Code generated by visual interfaces cannot be meaningfully integrated into automated testing frameworks. You can't write unit tests for drag-and-drop components. You can't run integration tests against a black-box visual builder. Quality assurance becomes manual-only, which means it becomes optional, which means it stops happening.

Where No-Code Belongs

I'm not a Luddite. No-code tools have legitimate uses:

• Prototyping — absolutely. Spinning up a clickable mockup in an afternoon to validate an idea with stakeholders? Perfect use case.
• MVPs — with caveats. If you accept that the MVP will be thrown away and rebuilt properly, fine. If you plan to "iterate" the no-code MVP into a production system, you're building on sand.
• Production systems at scale — absolutely not. Any serious product that needs to be maintained, tested, debugged, and scaled requires code control. Period.

What We Should Do Instead

If the goal is to speed up UI development — and I understand that goal — there are better paths:

• Figma + Storybook — designers work in Figma, developers build a component library in Storybook. The handoff is clean, the components are real, and everything is testable.
• Plasmic — a code-first tool with visual editing capabilities. It generates real React components that live in your codebase, go through your CI/CD pipeline, and can be tested like any other code.

These approaches give you the speed gains management wants without sacrificing engineering control.

The Real Issue

This isn't really about no-code. It's about a fundamental question: does this company value engineering culture, or does it view engineering as an obstacle to be routed around?

Replacing engineering discipline with visual convenience is a path to collapse. The first few months feel magical — screens appear quickly, stakeholders are impressed, velocity metrics look great. Then the bugs start. The integration breaks. The performance degrades. The team that was supposed to move faster is now spending all its time on workarounds.

I know I'm not alone in this opinion. Many of my colleagues share these concerns but stay silent out of fear. Someone has to say it plainly: substituting engineering culture with convenience is a path to ruin.

If the company doesn't change course, I'm prepared to leave. After 25 years, I know what sustainable software development looks like — and this isn't it.