Case studyVibe Code Rescue
Cedarwell: rescuing an AI-built app before it took on payroll
From 19% to production-ready, without a rebuild
Bespoke joinery · React · Firebase · Vercel
Cedarwell built the tool their workshop runs on: staff scheduling, job tracking from manufacture through to install, a payroll clock, materials and leave. It was built internally, using AI, and it worked.
What it had never been was productionised, and Cedarwell knew it. The app had not been through the security review, testing or accessibility work that any application meant to hold payroll and staff records needs, so payroll and staff records had not been put through it either. It ran internally while they worked out who to call, not for the people who would depend on it.
That is worth stating plainly, because it is the position a great many businesses are now in: software that works, built by someone who is not a developer, doing a real job, and never put through the steps that make it safe to depend on. Building it was the easy part, and the tools have made it easier still. Making it something a business can rely on is separate work, and it does not happen by itself.
The health check
A full review across security, reliability, code quality and accessibility. The app came out at 19% (red), with critical findings in every category except performance, where it was already quick.
The pattern was the familiar one: credentials in places they should not be, permissions enforced in the browser rather than on the server, no automated tests of any kind, and nothing standing between a change and the live system. None of it was a bad decision. It was the absence of a decision: the gaps an AI leaves when nobody reviews the output, which is exactly what nobody had been asked to do.
The verdict was rescue, not rebuild. The architecture was sound, and the domain logic (how this particular workshop actually schedules and bills work) was correct and hard-won. What was missing can be added to working software far more cheaply than working software can be recreated.
How it was done
Security first, in phases, before anything cosmetic.
Automated tests were built as a safety net before the structural work, not after, so the large changes had something to fail against. Then roughly fifty reviewed pull requests, each closing a named finding, each merged only once the tests passed.
How it went, step by step
- 1
The call
Cedarwell got in touch because they knew the app was not ready for payroll, and wanted someone to tell them how far off it was.
- 2
The health check
A full review across security, reliability, code quality and accessibility. It came back at 19%, a fail, with critical findings in every area except speed.
- 3
Rescue, not rebuild
The architecture was sound and the workshop logic was correct and hard-won. What was missing could be added far more cheaply than the whole thing could be recreated.
- 4
Safety net first
Automated tests went in before the structural work, not after, so the large changes had something to fail against rather than being made blind.
- 5
Roughly fifty reviewed changes
Each one closing a named finding, each merged only once the tests passed. No single large rewrite that nobody could check.
- 6
Handed back
Every check now runs automatically before anything reaches the live system, and Cedarwell can keep building on it.
Results
Failing checks
Automated tests
Gated on every deployment.
Main application file
Pre-deployment checks
Tests, lint, types, dependency audit, performance.
Beyond the numbers, three things changed that matter more than the score.
Administrator access became a real server-side permission rather than a flag the browser could set. Removing someone who leaves now genuinely revokes their access, rather than hiding them from a list, verified rather than assumed. And Cedarwell now has a safe way to make changes: branch, pull request, automated checks, a preview running against test data rather than real staff, then merge.
That last one is the part that lasts. The engagement ends; the process does not. Cedarwell still builds with AI (they should, it works), but now there is something between the AI’s output and their staff’s payroll.
“Our app did what we needed, but small changes kept breaking things elsewhere, and we had no way of knowing what security work it needed. Amplify talked us through the Vibe Code Rescue package and set out exactly what would be audited, and against what benchmarks. We came out of it able to scale safely, with the security issues found and fixed. We now have the confidence to put it into production and keep building on it.”
Built something with AI that people now depend on?
A Vibe Code Health Check tells you where you stand, against the same review, before something goes wrong rather than after.