Xera Lab
Dental case management platform
Read the case study →
Services
Rebuilds and modernization: taking over an existing product
A slow app, a platform nobody can safely change any more, or a developer who stopped replying. We start by reading what exists and giving you a written verdict — fix it, refactor it or rebuild it — so the decision is yours and it rests on evidence instead of a sales pitch.
Who this is for
- An app or platform that has become slow, unstable, or expensive to change.
- A product whose developer or agency stopped replying, left, or handed over nothing you can use.
- A system that still works but cannot be extended — every new feature takes longer than the last one did.
- A business that owns a codebase and genuinely does not know whether it is worth keeping.
It starts with a verdict, not a quote
Nobody can price a rebuild honestly without reading what is already there. So the first piece of work is a review, and what you get out of it is a written document: what the code does well, what is actually wrong, what it would take to fix, and what it would take to replace.
The document is yours. If it says the right move is to repair what you have, that is what it says, and you can hand it to your current developer and never speak to us again. That has to be a real possibility or the review is worthless.
The review is scoped and priced on the free call, in writing, before it starts — like every other piece of work here. You can stop when you have the document.
What the review covers
- Architecture: whether the structure can carry the next year of features, or fights every one of them.
- The data model, which is usually where an expensive problem is hiding.
- Dependencies and platform versions — what is out of date, what is unsupported, and what will stop working at the next OS or store deadline.
- Security basics: how accounts, permissions and secrets are handled.
- Deployment and hosting: whether anyone can ship a change safely, and what happens when it goes wrong.
- Ownership: whose name the code, the repository, the hosting and the store accounts are actually in.
Getting your accounts back in your own name
The most common damage in an abandoned project is not the code. It is that the App Store account, the Google Play listing, the domain, the hosting and the database sit in someone else's name, and that someone is not answering.
Part of taking a product over is putting all of it back in your name, and keeping it that way. Every account we create for you is created as yours from the start — that is the standing rule here, not a concession for rescue work.
Then the work itself
Once you have decided, the work runs like any other project: a fixed price in USD, three or four milestones, working software you can open at each one, and nothing invoiced until you accept it.
A rescue usually starts with stabilising what is live — stopping the bleeding — before anything is improved. Users do not care that a rewrite is coming; they care that the thing is broken today.
Twelve months of free support follows launch, exactly as it does on a new build.
Related work
Ezhal
Multi-role car-service platform
Read the case study →
Common questions
We do not have the source code. Is that the end of it?
Not necessarily, but it changes the answer. The first step is establishing what you actually control — the store listings, the domain, the database, the hosting — because those often matter more than the code. If the code is genuinely gone, a rebuild is the only honest route, and we will tell you that plainly rather than bill you to find out slowly.
Will you just tell us to rebuild, because rebuilding is the bigger job?
It is a fair suspicion, so the verdict is written and it shows its reasoning. If repairing is cheaper, the document says so and explains why, and you are free to take it to your current team. We would rather lose a rebuild than be the studio that recommends one to everybody.
Can you work with the developer who built it?
Yes, where they are still involved and willing. A review is not an accusation — plenty of code is reasonable work that simply outgrew its original scope, and the fastest route is often to tell the existing developer exactly what to change.
How long does taking over a product take?
The review is a matter of days. The work after it starts from two weeks for a stabilisation and runs to a full build timeline for a genuine rebuild — you get a milestone plan with a date before anything begins.
Will you sign an NDA before looking at our code?
Yes. Send yours before the call, or we will provide a simple mutual one. Reading a private codebase without one is not something we would ask you to agree to.
Get a verdict on what you already have
Tell us what exists and what is going wrong with it. You get a written answer on whether to fix it or replace it — and the document is yours either way.