Vibe Coding and base44: When It's Enough, and When It Ends in a Rewrite

For the past two years you have been able to describe an application in a sentence and get a working version back. The tools genuinely work. The demo is genuinely impressive. That is not a trick.

The problem arrives later, when you try to turn what was built into a real product with real users.

In 2025 the application-security firm Veracode tested code generated by more than 100 large language models across four programming languages. In 45% of cases the generated code failed security testing and introduced vulnerabilities from the OWASP Top 10.

The more troubling finding was a different one: as models advanced, they did not write more secure code. Security performance stayed flat regardless of model size or release date. This is not a problem that resolves itself in the next release.

This is not an argument against AI. We work with models every day. It is an argument about the distance between something that works in a demo and something that works in production.

When vibe coding is the right call

There are cases where the right answer is not to hire a software house, and we will tell you so even when it costs us the work:

• Testing an idea. If you want to know whether anyone wants the product at all, build it yourself with AI tools in two days. That is exactly what these tools are good at, and it is the cheapest, fastest way to fail cheaply.
• A demo for an investor or a customer. A prototype meant to show an idea, not to run a business.
• A small internal tool. Something serving one team, with no sensitive data and no external users. If it falls over, you lose a day of work for a few people, not the business.

In those three cases vibe coding is not a compromise. It is the correct tool.

The question begins when the thing succeeds.

Why success is the problem

A prototype that fails costs nothing. You delete it and move on.

The real danger is a prototype that succeeds. An investor gets excited, the first customers sign up, and suddenly the thing built in three days has to serve real people, hold real data, and survive real load.

That is precisely the moment — with momentum, with commitments, and with no time — that you discover it has to be rebuilt. It is the most expensive possible moment to find out.

This is why we say an application built through vibe coding is not an MVP. It is a prototype. An MVP is a minimal product you can keep building on; a prototype is something you throw away.

"In the demo it worked perfectly. A week after real users arrived, it didn't."— Ofer Davidyan, iGates

For the path from prototype to a product you can keep building, see App Development.

What we found when we opened them

Clients have come to us with products built on these tools, asking us to continue from where they stopped. Four things recurred almost every time:

Security holes
Data reachable without authorisation, validation performed only on the client side, and keys stored in the wrong place. This is not accidental: in Veracode's testing, model-generated code failed to defend against cross-site scripting in 86% of relevant samples. A model writing code is not thinking about an attacker — it is thinking about what you asked for.

Code that cannot be maintained
Duplicated logic, inconsistent patterns, circular dependencies. The system works today, but every change threatens something else — until at some point people stop touching it.

Failure under real load and real data
What worked for ten demo users fell over with hundreds of real ones and real data volumes.

No architecture
In some cases there was nothing worth saving. The fastest way forward was to rebuild.

"We opened the system and saw the database returning every record to anyone who asked. There was no permissions layer — just an assumption that nobody would check."— Ofer Davidyan, iGates

The infrastructure cost nobody mentions

When you build on one of these platforms, you also get its runtime environment. That is convenient at first, and it is exactly what hides the cost.

The moment you need the real things — separate development and production environments, backups, monitoring, cost control, regulatory compliance, or simply the ability to run the system somewhere else — you find the platform was not built for it, and that leaving is expensive.

Three things recurred in the projects that reached us:

No real separation between environments. Development, testing and production effectively ran in the same place, which means every change was tested against real users' real data. It is a problem you do not feel at prototype stage, and it becomes urgent exactly when you have customers.

Costs jump at real usage. These platforms are cheap at demo scale and expensive at product scale, and the transition between the two is not gradual.

Security and regulatory requirements cannot be met. When an enterprise customer's security review arrives, or a question about where data is stored, you discover the platform simply does not support it — and there is no way to fix that from the inside.

Infrastructure is not a technical detail. It determines whether you can grow, whether you can meet requirements, and whether you can change vendor if you want to.

How we work with AI

We work with models every day. The difference is not whether AI is used — it is how.

A model here does not receive a vague sentence and start building. It receives a defined unit of work, after the architecture, specification and documentation already exist. The technology choice is ours, not the model's.

Every agent output is reviewed by trained reviewer agents before it reaches an engineer. Development cycles are preserved in full — continuous integration, testing, QA and deployment. DevOps stays under your control, not inside a vendor's limited environment.

Proprietary information and intellectual property are not passed through models, and on sensitive projects we run local models with no internet connection.

Put simply: we treat an agent like an engineer. We build its knowledge base, train it, and test it before it starts working. That is the difference between a tool inside an engineering process and a replacement for one.

See AI Development & Integration.

If you have already built one

If you have a product built with AI tools and it is starting to creak, the first question is not "rewrite or not". It is "what exactly is here".