Everything from one team
Design, build and operations with the same team, from the first call to launch.
Your vibe-coded app works in the demo. We make it hold in production.
Built with Lovable, Cursor, Bolt or Replit and stuck at 80%? We audit it, fix auth, data separation and backups, and take it live. The code audit takes days, production-readiness typically 3 to 6 weeks.
12+ projects delivered
every one on deadline, in production
Fixed price and deadline
in writing, and if we slip, the next payment waits
Reply within 24 hours
on working days, to every enquiry
In writingQuoted after the code audit
The audit is its own stage at its own price; the rescue is quoted in the proposal after it.
Where your app stands now
The demo runs perfectly. What sits behind the login, nobody can tell you.
The database is open to anyone who asks, because the row-level rules were never switched on.
A senior sold the project, juniors built it, and today you cannot even get into the repository.
Which of these is your project
Vibe-coded MVP taken live
A demo assembled with AI tools that runs, but cannot take traffic without sign-in, permissions and backups.
Legacy system modernised
A codebase patched for years that nobody dares touch. We put it in order, and it stays developable afterwards.
Handover from the previous team
Your developer moved on or stopped answering. We map the code, write down what is in it, and carry it on from there.
Security and performance cleanup
The system runs, but it buckles under load or leaks data. We close the holes and measure the speed.
From vibe-coded demo to production system
- Call
We look under the demo
You show us what works and what falls over. At the end we say what we recommend auditing, and whether a rewrite is the cheaper path.
- Scoping
A written verdict and repair plan
The audit ends in a written result: a map of the codebase and its architecture, the findings in priority order, the flows we clicked through and where they stopped, and the four outcomes with what each one costs. That price holds to handover.
- Build
We fix what is worth keeping
Security and data-protection items go first, then the tests. At the end of every stage you see what changed on a live link.
- Live
Launch, and watching the inherited parts
We take it live and keep watching what you inherited.
A paid-for, half-finished app still gets a second run.
Plenty of apps start life as a demo built by talking to an AI, then real money changes hands and production is where it falls over.
That is exactly what the code audit is for: in a few days you get it in writing, what is salvageable, what is missing, and what production-ready costs. And when a rewrite is the cheaper path, we write that down too, with the numbers. You find out at the price of an audit, not at the price of the next invoice.
Three questions that get settled before the call
These three come up most often, and usually in this order. The figures come from industry research, and each one carries its source beside it.
- A rewrite, then?
When do we actually say rewrite it?
The audit knows four outcomes: keep it, harden it, rebuild part of it, rebuild all of it. The findings decide, and when a rebuild is the cheaper answer we quote that instead.
45%
of AI-generated code samples carried a security flaw (100+ models, 80 tasks, re-measured in spring 2026) - Signing blind?
Where does a price come from before anyone has read the code?
The audit is its own stage, on its own price, bounded to a few days. It ends in a findings list and a repair plan that stay on your side even if you stop there.
CVE-2025-48757
one known flaw that let 170+ live apps hand over their entire user table with no login at all - Held hostage again?
Who keeps the code and the findings list if we stop?
The repository and the cloud accounts are registered to your company, and we work in them as invited users. The audit findings and the repair plan stay on your side, whichever team carries on.
80%
of companies knowingly ship vulnerable code, and 18% have any policy at all for AI coding tools
What a rescue and modernization engagement includes
- A code audit that ends in a written repair plan
- Vulnerabilities patched and open data access closed
- Architecture cleaned up, the patchwork taken out
- The vibe-coded MVP made ready for real traffic
- Speed and load capacity sorted out, with tests
- Handover with documentation, and maintenance after it
Example
On a vibe-coded booking MVP we would start with sign-in and permissions, because that is where the exposure sits. Then the data model, a daily backup with a restore drill, and payments taken live. Cosmetic issues go to the end of the list: the goal is a system that carries traffic, not a prettier one.
What the rescue works with
In a rescue the most expensive bug is the one the fix itself causes. The flows are therefore replayed by Playwright, so the next change shows straight away if something broke.
This is the sheet the audit ends with
Six checkpoints, each with a finding and a state beside it. The same six run against your own codebase.
Code audit verdict sheet
Sample Ltd. · sample.com · 6 checks
- to fix
Auth that actually enforces
Login works; the server never checks who is allowed to see what.
- clear
Dev and production data split
Test and production data run on separate database instances.
- to fix
Closing the security holes
Secrets committed to the repository, and incoming data is never validated.
- to fix
Backups with tested restores
Nightly backups run; nobody has ever tried a restore.
- clear
Monitoring and logging
Structured logging and failure alerts are live.
- to fix
Tests and safe deploys
No automated tests, and releases go out to production by hand.
Sample data. Yours reads your own codebase, against these same six checks.
Who should build it
Rescuing a half-finished system can be bought from several places, and the choice comes down to who carries the risk.
In-house developer
Freelancer
Hourly agency
Brecon
Who is accountable for the deadline
You are. They estimate; your company carries the consequence.
Whatever you agree. With no deadline in writing there is nothing to hold.
An hourly rate covers the effort; the date stays an estimate.
Us. The rescue deadline lands in the proposal after the audit, and if we slip, the next instalment waits.
What happens if the person leaves
The knowledge leaves with them unless it was written down. A new hire, a new ramp-up.
One person, one calendar. If they disappear, the project stops.
People can be swapped, and the ramp-up still takes time.
The written findings, the source code and the documentation stay with you, so carrying on does not depend on one person.
What happens to the code
Yours, as it is written.
Depends on the contract. One sentence in it settles the question.
Depends on the contract, and licences and accesses are part of the question.
Yours, with the accounts, on the final invoice, even if somebody else takes it on after the rescue.
When this is the better choice
When development runs for years and someone is there to direct it daily.
For small, precisely described work this is often a sound choice.
When the scope only becomes clear as you go and you can carry an open budget.
When you have a system you paid for that will not hold in production, and you want to know what is salvageable.
- In-house developer
- You are. They estimate; your company carries the consequence.
- Freelancer
- Whatever you agree. With no deadline in writing there is nothing to hold.
- Hourly agency
- An hourly rate covers the effort; the date stays an estimate.
- Brecon
- Us. The rescue deadline lands in the proposal after the audit, and if we slip, the next instalment waits.
- In-house developer
- The knowledge leaves with them unless it was written down. A new hire, a new ramp-up.
- Freelancer
- One person, one calendar. If they disappear, the project stops.
- Hourly agency
- People can be swapped, and the ramp-up still takes time.
- Brecon
- The written findings, the source code and the documentation stay with you, so carrying on does not depend on one person.
- In-house developer
- Yours, as it is written.
- Freelancer
- Depends on the contract. One sentence in it settles the question.
- Hourly agency
- Depends on the contract, and licences and accesses are part of the question.
- Brecon
- Yours, with the accounts, on the final invoice, even if somebody else takes it on after the rescue.
- In-house developer
- When development runs for years and someone is there to direct it daily.
- Freelancer
- For small, precisely described work this is often a sound choice.
- Hourly agency
- When the scope only becomes clear as you go and you can carry an open budget.
- Brecon
- When you have a system you paid for that will not hold in production, and you want to know what is salvageable.
Who software rescue fits, and who it does not
This fits you if
- You have a working demo and real traffic is next.
- The system runs, and every change breaks something else.
- You will not put it in front of a client without auth, data security and tests.
We would point you elsewhere if
- The codebase is small enough that a rewrite costs less. The audit says so, and we quote the rewrite instead.
- You are still finding the product's direction. Direction first, rescue after.
If the audit says a rewrite is the better route, this is how we would rebuild it.
40-50%
of the IT budget goes on maintaining and repairing technical debt at many companies, by industry surveys.
This figure comes from industry research.
Companies we've built for
Gloster
Palm Group
Habibi
The Garage
Design Glass
Kék Padlizsán
Jungle Burger
D+D Solar
Fawa
On every project
Your goal sets the bar
The first call is about what you want to achieve; if less will get you there, we say so.
Tested before it goes live
We measure what we hand over before launch, and watch the first week with you, measurements included.
How we work
From code audit to launch, with one team
- Clickable progress on a live link, stage by stage
- Fixed price and deadline, in writing
- The code and the infrastructure are yours
- Monthly maintenance after launch: updates, fixes, extensions
- If we slip, the next instalment waits
The proposal is itemised: what we build, by when, for how much.
In writing
Quoted after the code audit
The audit is its own stage at its own price; the rescue is quoted in the proposal after it.
The audit result. Security fixes and test coverage are priced by how much code there is, and how much of it is worth keeping.
Request a code auditWhat happens after launch
After a rescue the inherited parts stay the weakest ones, and those are what we keep watching as real traffic leans on them.
First month
A clean handover, a watched launch
Source code, credentials and documentation in your hands. We watch the first week with you, measurements included.
Every month
Maintenance that keeps it moving
Updates, fixes, extensions, and the measurements watched as your product grows.
If something breaks
You write, we answer
A first reply within 24 hours on working days, to every enquiry.
What owners ask before a vibe coded rescue
The price list says the price is quoted after the code audit, and that is deliberate: until we have read the code, any number would be a guess. The audit is its own stage at its own price, and at the end you get the findings and the price together. If the list runs longer than the budget, the security and data-protection items go first and the rest becomes its own stage, at its own price.
It does real work: it reads the configuration, and it catches a database setting left open or a permission rule nobody ever switched on. What a configuration scan structurally cannot reach is the relational half: whether the permission rule allows what the screen actually shows, whether a multi-step flow holds when someone takes the steps out of order, whether a foreign key exists so two records cannot disagree about the same customer, and whether yesterday's backup restores. The audit walks those four as well.
Often it would, and we will say that on the first call. If you are chasing one specific bug, or you want a second opinion on a single decision, a senior developer reading the code is faster and cheaper. The audit earns its place when the question covers the whole system: permissions, the data model, backups and the flows have to be read together, and each finding comes out with a price beside it you can plan around.
The audit answers that too, and it is one of the possible outcomes. We then price both the rescue and the rewrite, and you decide. Often the users, the data model and the integrations survive, and the new layer is built on top of them.
The code and the infrastructure are yours, and the accounts stay in your name. For the audit we ask for read access to the repository and the staging environment; we never copy live customer data out.
The code audit takes a few days and ends in a written remediation plan. The work itself depends on what the audit finds: taking an MVP to production quality usually runs 3-6 weeks, modernising a system patched for years runs longer. The deadline is in the proposal.
We quote it when the rescue closes: monthly maintenance with updates, fixes and extensions. The audit's written repair plan stays with you, so after the rescue you still see what got done and what is left on the list. If your own team takes it from here, the documented codebase is handed over for exactly that.
We write it down and we talk before building anything. The figure recorded in the proposal covers the scope the audit set out, so it does not grow mid-project. Bad news is cheap in an audit and expensive in production, which is exactly what those few days are for.
They get stuck for the same reason nearly every time: something surfaces that the estimate never covered, and from then on the deadline is a negotiation. That is why we start with an audit. And the proposal is staged: at the end of every stage the system runs, so if you stop, you stop on something that works. We go through the repair list together throughout, so no finding reaches you only at the end.
Start with a code audit
We open with a short call, then the audit answers what can be saved and for how much. If a rewrite is cheaper, we write that down too.