Renovating a vibe-coded app: readable code, no reasoning behind it

A client had been building an education platform in Lovable for months. Too many issues piled up, so they brought in devs. I got assigned to it. The job was to turn a vibecoded app into something production ready.

First time I'd worked on a fully vibecoded app.

First thing I did after getting access and exporting the code was try to run it locally. React/Vite frontend, Supabase backend. Quick read through: 132 migration files. Figured I'd spin up a fresh Supabase project, run them, and have the app up. Took two days instead. Fine, that's just work.

Ran an audit over the whole thing through an agent, came back with 319 findings, 29 critical. Security was about what you'd expect. A student could create a school and set themselves up as administrator. All fixable though.

What I wasn't ready for was the stuff where I could read the code fine and still not tell what it was supposed to be doing.

The core of the product is a daily score for each student, shown to their parent as a letter grade. That's the thing the schools are paying for.

Found 4 completely separate engines computing that daily score. Two of them weight the same sub-score differently, sixty-forty against forty-thirty-thirty, so the same kid gets a different number depending on which one ran last. All four write to the same field.

That's what makes it bad. Imagine four engines all doing their job, nothing throwing, nothing erroring, because why would it. But in business terms it's off the rails. Same input, different grade, and if you're not technical you've got no way of telling anything is wrong.

Nothing anywhere says which one is the real one. Not in the code, not in a comment, not in anything the client said. So I can't just pick, because picking changes what grade a kid gets. Sent it back to them as a product question.

Normally you'd get this off a commit message, a PR thread, or just asking whoever wrote it. None of that exists here.