← All insights

Insights

The "80% Rule": Why Your Vibe-Coded App Fails Without a Schema

Skipping the database schema in vibe coding is like choosing the curtains before pouring the concrete. Getting it 80% right is often the threshold between a working product and one that eventually collapses under its own weight.

Vibe coding — describing what you want in natural language and letting AI generate, run, and refine the code — feels like magic. You say stuff, run stuff, and copy-paste stuff, and suddenly you have a working prototype. The trap is the illusion of progress: features ship at record speed until you hit an invisible cliff where the app becomes impossible to fix or scale, because it never had a structured foundation.

Malaysian SMEs and enterprise teams are already vibe-coding internal CRMs, dashboards, and GenAI copilots. Speed is real. So is the cost of skipping the data model.

The Story of the Phantom CRM

Consider a developer who vibe-coded a custom CRM for their sales team. On day one, it looked perfect. The AI generated a polished dashboard and a contacts table. Because nobody defined a schema first, the model started taking shortcuts.

The fail. To "save time," the AI stored multiple phone numbers as a single comma-separated string and saved deal values as text — "$5,000" instead of a number.

The crash. Three months later, when the developer asked the AI to "calculate total quarterly revenue," the app broke. You cannot do reliable math on currency strings. The model began hallucinating fixes that created duplicate records. That became a doom loop of the same bug, patched in slightly different wrong ways, until the project died.

The UI was never the problem. The data model was.

Why the 80% Rule Matters

You do not need a perfect database on day one. You do need a clear enough target that the AI cannot invent its own rules for how data works.

It prevents context rot. Unstructured vibe coding rarely gives the model precise guidelines. Without a clear data contract, the AI hallucinates how records should be shaped, duplicated, and joined — and you end up with inconsistent logic scattered across the codebase.

It breaks the doom loop. AI-generated code optimises for "make it work right now." If the underlying structure is flawed, every fix is temporary. The same class of bug returns because the foundation never changed.

It protects scale and integrity. A coherent schema is what keeps queries fast, constraints enforceable, and reports trustworthy as the dataset grows. Without it, every new feature is another patch on sand.

The first 80% of an app can often be vibe-coded in minutes. The last 20% — schema discipline, edge cases, security, and operational reality — is what turns a prototype into a product.

Common Pitfalls of Vibing Without a Schema

Happy-path bias. AI tools are excellent at the path where everything goes right. They under-specify failure modes, empty states, partial updates, and conflicting writes unless you force those constraints into the brief.

Bad normalisation. Teams either cram everything into one table or over-fragment into unnecessary joins. Storing registered courses as a comma-separated field is the classic example: it works in a demo and makes real queries impossible later.

Security as an afterthought. Vibe coding often leaves secrets in client code, skips input validation, and invents SQL that invites injection. Speed without a data boundary is how credentials and messy writes leak into production — a particular risk when Malaysian organisations also have PDPA obligations.

"Almost right" code. The most expensive code is code that mostly works. It passes the first demo, then fails silently in one browser, one race condition, or one malformed row — exactly where senior review would have caught it.

The Do's of Vibe Coding

  1. Aim for an 80% schema before UI. Define core entities and relationships — Contact, Deal, Interaction — before the AI writes screens.
  2. Plan before you prompt. Write a one-page spec: inputs, outputs, constraints, success metrics. Paste it into every session so the model has explicit rails.
  3. Use plan mode. Ask the AI to propose a migration plan, including a rollback path, and get confirmation before it touches the schema.
  4. Review AI code like a junior contractor's PR. Concentrate review on authentication, SQL, migrations, and credential handling — not on whether the button looks nice.
  5. Use a second agent as reviewer. Once one agent implements a change, have another specifically hunt for bugs, security flaws, and over-engineering.

The Don'ts of Vibe Coding

  1. Don't ignore context rot. Giant single-file projects breed phantom code — duplicate functions and dead exports — because the model loses the map. Prefer modular files with clear ownership.
  2. Don't ship almost-right code. If a flow fails silently, treat that as a blocker, not a polish item.
  3. Don't skip input validation. AI will omit safeguards unless you demand them. Validation is part of the schema contract, not a later hardening pass.
  4. Don't hardcode secrets. API keys and database credentials in source control or client bundles are not "temporary scaffolding." They are a breach waiting to happen.

How to Get to 80% Before You Code

1. Entities and relationships first. For a CRM: how does a Contact link to a Deal? Who owns an Interaction? Draw the links before any React component exists.

2. Normalise for clarity. Aim for Third Normal Form (3NF) so each fact lives in one place. You can denormalise later for performance once you understand real query patterns.

3. Explicit keys and audit fields. Every entity gets a primary key. Relationships get foreign keys. Add created_at and updated_at from day one — you will need history sooner than you think.

4. Draft a written migration plan. Ask the AI for forward migration and rollback before it edits production-shaped tables. Schema changes without a way back are how teams freeze in fear of their own database.

For a CRM, an "80% right" day-one schema usually means: canonical entities (Lead, Contact, Account, Deal), explicit keys and relationships, typed money fields, and audit timestamps. That is enough structure for the AI to stop inventing storage formats — and enough flexibility to evolve.

Free Tools That Help You Reach 80%

You do not need an enterprise modelling suite to get the foundation right.

  • dbdiagram.io — Write a quick DSL, see the ER diagram immediately, share a link with anyone reviewing the design. Ideal for the "entities first" step before code.
  • DBeaver — Free desktop client for Postgres, MySQL, and most other engines. Inspect live tables, constraints, and sample data when the AI claims a migration "worked."
  • ChartDB — Visual schema exploration and diagramming when you need to reverse-engineer what already exists (or what the AI quietly created).
  • Plain SQL migration files in git — Still the highest-signal artefact. If the schema change is not reviewable as text, it is not under control.

Use the diagramming tool to think. Use DBeaver to verify. Use migrations to own the change.

The Point

Vibe coding is an acceleration tool, not a replacement for engineering rigor. AI Technical Debt is what you create when you trade today's speed for tomorrow's rewrite — usually because the model was never given a data model firm enough to obey.

Get the schema to 80%. Give the AI a target vision and unambiguous data rules. Review the dangerous parts like a senior engineer. Do that, and when your vibe meets reality, the app has a chance of surviving.

The first 80% can be magical. The foundation is what keeps the magic from becoming a demolition.

This is the same principle we apply when Malaysian teams ask for GenAI copilots, agentic workflows, or data readiness before AI: accelerate delivery, but never skip the contract that tells the system what "correct" means.

Oxydata Software helps Malaysian organisations design data foundations, ship governed GenAI, and avoid AI technical debt before it becomes a rewrite. Talk to us about AI-assisted delivery with production-safe architecture.