How we compared them
We sell fixed-scope rescue work through Continuum, so we say where the other routes fit better.
A stuck Lovable app can mean a broken screen, a leaking database or a project nobody dares touch. Each route was weighed on what a founder cares about when choosing:
- The kind of problem it suits, from a visible bug to a hidden data risk.
- Who does the work and who checks it.
- What it costs and how it is billed.
- Whether you keep the code and a history of every change.
- What it cannot do.
The options
Routes are listed from the cheapest and nearest to the biggest commitment. Facts about other companies come from the sources at the bottom, with the date they were looked up.
Keep fixing inside Lovable
The tool that built the app
You stay in the editor and ask Lovable to fix the problem. It also has a Project security view, where each finding shows a severity and evidence, and you can fix it or ignore it.
- Good at
- It is the quickest route for a contained bug and for the issues its own scan raises. No new person needs access to anything.
- Fits
- A founder who can describe the problem in a sentence and see it on screen.
- Drawbacks
- Findings from the publish scan do not stop you publishing unless a workspace admin turns blocking on, so a warning can sit unread. In our view the tool that wrote the code is a weak reviewer of that same code, so use this route for small fixes and not for questions about data or money.
Sources: [1] [2]
Sync to GitHub, then work in your own editor
Move the code somewhere you control
Lovable’s GitHub integration keeps a project in two-way sync with a repository. You can clone it, edit with your own editor or a coding assistant, and push the result back.
- Good at
- You get a record of every change, and any developer can open the repository and read it.
- Fits
- Someone comfortable with Git, or a founder with a developer friend who has an hour to spare.
- Drawbacks
- Lovable’s docs say only one branch syncs at a time and that you should not force push, rebase or squash commits already on it. You cannot import an existing repository into Lovable. Its status page has also logged an incident where pushed commits did not appear in the editor, resolved by making a new external commit.
Sources: [3] [4]
A freelancer from a marketplace
One person, hired by the task
You hire an individual to fix named problems, usually through a marketplace such as Upwork, Toptal or Fiverr, and you set the scope.
- Good at
- It is the lowest cost for a well-defined task, and you pick the person.
- Fits
- A founder who can list the exact tasks and has the time to manage the work.
- Drawbacks
- You scope and review the work yourself, which is hard when you cannot read the code. Upwork shows most web developers at $15 to $50 an hour (captured December 2025), so the total depends on how long the job runs, and a stuck app is hard to size from outside.
Sources: [5]
A development agency
A team under a contract
An agency scopes, builds and fixes with a team under a written contract.
- Good at
- It has capacity for a large rework, plus design and project management in one place.
- Fits
- A company with a budget for a team and a job closer to a rebuild than a rescue.
- Drawbacks
- Clutch’s pricing guide puts agency rates at $25 to $99 an hour, which runs higher at the top end than marketplace rates. Read the contract for who owns the code.
Sources: [6]
Continuum
Fixed-scope rescue, by one senior engineer
Continuum is Matt Turley, one senior engineer working directly with each client. It starts with a free Leak Check that reads your live URL from outside. Next comes a $299 Ship Check, where the codebase is read and a costed plan written, then Ship Fix at $4,000 to $15,000 for the repair.
- Good at
- Each step has a price before work starts, and you own all the code.
- Fits
- A Lovable app with real users, payments or private data where you want the problem scoped before you commit money.
- Drawbacks
- Anything past the free Leak Check needs access to your code. Ship Fix is a fixed-scope job, so it is more than a one-line bug deserves.
See what a Ship Check covers →
Check for data exposure before anything else
A broken screen is visible. A database that strangers can read is not, and it is the part of a rescue that can hurt your users.
Continuum scanned 500 live apps built with Lovable, Bolt and base44 in October 2026. 177 of them ran on Supabase, and 31 of those 177 (17.5%) had at least one table that returned a row to a request with no login. 8 of the 177 (4.5%) had a table holding clearly non-public records. [7] Method and data.
Whichever route you choose, ask for a check of who can read your tables without logging in.