You already have an application, and it went badly
Provider gone, project stalled, code nobody dares touch any more. It is an ordinary situation and it can almost always be recovered. We start by looking at what you actually have.
Does one of these sound familiar?
These are the five reasons people call us. None of them is beyond saving.
- Your provider has stopped replying, or has shut down.
- The application works, but nobody knows how to change it any more.
- Every new feature breaks something else.
- You have been told it all needs rebuilding, and you can’t tell if that is true.
- You are not even sure you have the code.
How we go about it
- 01
We recover what exists
The code, the credentials, the accounts, the servers. It is often the most tedious step and we take it on, including dealing with your previous provider if they can still be reached.
- 02
We look, and tell you what it is worth
In one to two weeks we examine the application in detail and hand you a written assessment in language you can read: what is sound, what is fragile, what is dangerous.
- 03
We give you a straight verdict
Continue, repair, or rebuild. We tell you which of the three, why, and what each would cost. Sometimes the honest answer is “start again” — we say so when it is.
- 04
We take it over, if you want us to
You are under no obligation to give us the work. The assessment is yours and you can hand it to whoever you like.
What the assessment contains
A ten-page document, written to be read by a director rather than by a developer.
- What the application actually does today, screen by screen
- What is solid and can be kept as it is
- What is fragile and will cost you dearly if left alone
- Security holes and poorly protected personal data
- Whether you really have all the code, and what is missing if not
- Three costed scenarios: continue, repair, rebuild
What we will tell you, even when it costs us
-
Sometimes it really does all need rebuilding
When the cost of repair exceeds the cost of rebuilding, we say so — and we show you the arithmetic rather than asking you to take our word for it.
-
Sometimes your previous provider was right
A project that went off the rails is not always the previous team’s fault. Sometimes the scope changed ten times. We are not looking for someone to blame, we are looking for a way out.
-
Sometimes nothing should be done at all
If your application does the job and the improvements you are dreaming of would add nothing, we will advise you to keep your budget.
Takeovers we have carried out
- Migrating an ageing hybrid app to Flutter safely Complete Flutter rewrite of Télépro, a TV listings app previously built on Cordova, with a back-end aggregating editorial content. Read the case study
- Two mobile SDKs for an e-commerce SaaS vendor Android and iOS SDKs for an e-commerce personalisation vendor: public API, demo applications and full documentation. Read the case study
- A head-up display on smart glasses for light aviation A Flutter application driving two models of smart glasses and a flight probe over Bluetooth, with a custom-built artificial horizon. Read the case study
- TV and mobile applications for telecom operators One shared application foundation turned into several television and video-on-demand apps, each branded for a telecom operator. Read the case study
The questions we get
I am not sure I have the code. What now?
That is common, and it is the first thing we check. The code may sit on a server you still have access to, at a host you are paying without knowing it, or in an account in your former provider’s name. We help you recover it, and failing that we tell you what can be rebuilt from the live application.
My provider refuses to hand over the code. Are they allowed to?
It depends entirely on what your contract says. If it assigns the rights to you, the code is yours. If the contract is silent, the situation is more complicated and calls for legal advice — we can help you understand what is technically at stake, but we are not lawyers.
Do you ever turn takeovers down?
Yes, when taking it over would not serve your interests. We would rather say no and explain why than bill six months of work on a doomed foundation.
How long before the project moves again?
The assessment takes one to two weeks. After that, a well-run takeover restores a normal delivery rhythm in about a month. The first thing we do is restore the ability to ship without breaking anything.
What if the app is written in an old technology?
That is not an obstacle in itself. Plenty of old applications work perfectly well and have no need to be rewritten. The real question is not the age of the technology but the cost of every future change — and that is exactly what the assessment measures.
The technical audit in detail For your technical team — feel free to skip.
The audit covers code quality and readability, architecture and its coupling, test coverage, outdated dependencies and their known vulnerabilities (CVEs), build and deployment reproducibility, the state of database migrations, secret management, GDPR compliance of the processing, and the technical debt that is genuinely blocking — as opposed to the debt that is merely ugly. We regularly run Cordova and Ionic migrations to Flutter, Objective-C to Swift and Java to Kotlin transitions, major version upgrades of Angular, Django or React Native, and takeovers of projects with no usable Git history.
Let’s start with the assessment
Describe your situation in a few lines. We come back within one business day to tell you whether we can help — free, with no strings attached.