Client project · Product takeover
Getizy: the second development company.
The iOS and Android apps already existed. The company that wrote them had moved on. We took the codebase over, cleared what was broken in it, and kept shipping new functionality to both stores.
- Client
- Getizy
- Engagement
- Product takeover
- Platforms
- iOS and Android
- Shipped
- App Store and Google Play
Two flows from the app as it shipped: ordering, and payment. We did not design these screens or write the first version of them. We made them work, then added to them.
The situation
A live product, and nobody left who knew it.
Getizy had an app on iOS, an app on Android, and users on both. What it no longer had was the development company that built them — and every reason a file looked the way it did had left with it.
Nothing about that is unusual. Working software is a record of decisions, and most of that record lives in the heads of the people who made them, not in the repository. What the owner keeps is a product that runs, a list of things wrong with it, and no way to tell which parts are safe to touch.
The real constraint: no rewrite.
A rewrite is months in which nothing reaches the people already using the app, and it throws away the one thing old code is good at: being right about a hundred small cases nobody wrote down. So the job was to make someone else's decisions work, and keep shipping while doing it.
What we did
Stabilise first. Extend after.
Four steps, in this order. A takeover that adds features while the old defects are still open only makes the defect list longer.
Read it before touching it.
The first work was not a fix. It was reading the codebase, running both apps against the real backend, and writing down how a release actually happens. Until you can build, sign and submit the app yourself, you have not taken anything over — you are only borrowing it.
Triage the inherited defects.
Every known bug went into one list, ordered by what it cost the user rather than by how it looked in the source. Crashes and anything blocking a payment first. Cosmetic debt last, and some of it never — inherited code is full of things that are ugly and correct.
Make releasing boring.
Certificates, signing keys, store accounts and the build itself came under our control before we promised any new functionality, so that a release stopped being an event.
Then extend.
With the app releasable on demand and the defect list short, we started adding. New functionality went to both stores in the same rhythm as the fixes, in versions small enough that a bad one could be replaced quickly.
The person who read the codebase is the person who shipped from it.
Takeovers, as a service
We can build from scratch — or take over what exists.
A build that stalled, a contractor who left, an app shipping bugs faster than features. Inheriting a codebase is a normal way to start with us.
It begins with a paid code review.
A takeover is quoted from the code, not from a screen share. The first thing we sell is a review of it, priced on its own: the Product Decision Sprint, €2,500 and five business days, nothing to production, credited in full against a build that starts within 30 days.
What we look for
- Whether we can build, sign and release the app from our own machines, without anyone from before.
- What the code does when things fail — errors, retries, and payments that half-happen.
- Which dependencies are abandoned, and which OS versions are about to stop tolerating them.
- Where the data sits, who can read it, and what a GDPR request would actually require.
- How much is covered by tests, and whether those tests still pass.
- The parts nobody should touch yet, and what it would take to make them touchable.
What you get before anyone quotes a build
- What is wrong, in plain language, with the risk of each item rather than a severity label.
- What has to be fixed before anything new can be built on top of it.
- What we would deliberately leave alone, and why.
- Where a rewrite of one part is genuinely cheaper than repairing it — that goes in the review too.
Then the build is quoted in that order
Stabilisation first, new functionality second, both at a fixed price. The second half is priced on what the review found, not on a guess made before anyone opened the repository. If the review says the codebase is beyond what we should take on, we say so, and you have still bought an honest answer.
The honest part
Where it stands now.
Getizy shipped to the App Store and Google Play. The service is no longer publicly available.
That sentence stays on the page. What we can speak for is the engineering: we took over a product built by someone else, made it stable, and kept it shipping. What happened to the business afterwards is not ours to narrate.
There are no numbers on this page either. We were the development company, not the company — installs, revenue and growth were never ours to publish.
What we would do differently.
Take the release pipeline on day one.
We were fixing real defects before we could produce a release on our own terms. Signing, certificates and store access are now the first thing we ask for in a takeover, ahead of the bug list — until that is settled, the fixes are finished and still not delivered.
Price the reading.
We learned that codebase on the build's clock. Reading someone else's product properly takes days, so it is now separate, paid work that happens before the quote — and the number that comes out of it is based on what is actually there.
Start something, or take something over.
Both are normal here. A new build is scoped and priced before a line is written. A takeover starts with the paid code review; the build quote comes after it.
One short form, a reply within one business day. If we are not the right studio for it, we will say so.