Voor een klant · Overgenomen project
Getizy: het tweede ontwikkelbedrijf
De apps voor iOS en Android bestonden al. Het bedrijf dat ze had geschreven, was vertrokken. Wij namen de codebase over, losten op wat erin kapot was en brachten nieuwe functionaliteit uit in beide stores.
- Klant
- Getizy
- Opdracht
- Overgenomen project
- Platformen
- iOS en Android
- Uitgebracht
- App Store en Google Play
Twee gebruikersflows uit de app zoals die is uitgebracht: bestellen en betalen. Deze schermen hebben we niet ontworpen en de eerste versie ervan niet geschreven. We hebben ze laten werken en ze daarna uitgebreid.
De situatie
Een draaiend product, en niemand meer die het kende.
Getizy had een app op iOS, een app op Android en gebruikers op allebei. Wat er niet meer was, was het ontwikkelbedrijf dat ze had gebouwd – en met dat bedrijf verdween ook elke reden waarom een bestand eruitzag zoals het eruitzag.
Daar is niets bijzonders aan. Werkende software is een verslag van beslissingen, en het grootste deel van dat verslag zit in de hoofden van de mensen die ze namen, niet in de repository. Wat de eigenaar overhoudt, is een product dat draait, een lijst met wat eraan mankeert en geen manier om te zien welke delen veilig aan te raken zijn.
De echte beperking: niet opnieuw bouwen
Opnieuw bouwen betekent maanden waarin de mensen die de app al gebruiken niets krijgen. En het gooit weg waar oude code juist goed in is: kloppen in honderd kleine gevallen die niemand heeft opgeschreven. De opdracht was dus om de beslissingen van iemand anders te laten werken, en ondertussen nieuwe versies te blijven uitbrengen.
Wat we deden
Eerst stabiel. Daarna uitbreiden.
Vier stappen, in deze volgorde. Een overgenomen project waar functionaliteit bij komt terwijl de oude defecten nog openstaan, maakt de lijst alleen langer.
Lees het voor je het aanraakt.
Het eerste werk was geen reparatie. Het was de codebase lezen, beide apps draaien tegen de echte backend en opschrijven hoe een release werkelijk tot stand komt. Zolang je de app niet zelf kunt bouwen, ondertekenen en indienen, heb je niets overgenomen – dan leen je het alleen.
Sorteer de overgeërfde defecten.
Elke bekende bug ging op één lijst, geordend naar wat hij de gebruiker kostte en niet naar hoe hij er in de broncode uitzag. Crashes en alles wat een betaling blokkeerde eerst. Cosmetische schuld als laatste, en een deel ervan nooit – overgeërfde code zit vol dingen die lelijk zijn en toch kloppen.
Maak een release saai.
Certificaten, ondertekening, de accounts bij de stores en de build zelf kwamen onder ons beheer voordat we nieuwe functionaliteit beloofden. Zo hield een release op een gebeurtenis te zijn.
Daarna pas uitbreiden.
Met een app die op elk moment uit te brengen was en een korte defectlijst begonnen we functionaliteit toe te voegen. Die ging in hetzelfde ritme naar beide stores als de oplossingen, in versies die klein genoeg waren om een slechte snel te kunnen vervangen.
Wie de codebase las, bracht ook de releases uit.
Bestaande code overnemen
We bouwen vanaf nul, of nemen over wat er al staat.
Een bouwtraject dat is vastgelopen, een externe ontwikkelaar die vertrok, een app die sneller bugs uitbrengt dan functionaliteit. Beginnen met een bestaande codebase is hier heel gewoon.
Het begint met een betaalde doorlichting van de code.
De overname van een bestaande codebase offreren we vanuit de code, niet vanuit een scherm dat je deelt. Het eerste wat we verkopen is een doorlichting daarvan, apart geoffreerd: de Product Decision Sprint, € 2.500 en vijf werkdagen, niets naar productie, volledig verrekend met een bouwtraject dat binnen 30 dagen start.
Waar we naar kijken
- Of we de app vanaf onze eigen machines kunnen bouwen, ondertekenen en uitbrengen, zonder iemand van vroeger.
- Wat de code doet als er iets misgaat – fouten, herhaalpogingen en betalingen die half doorgaan.
- Welke afhankelijkheden niet meer onderhouden worden, en welke OS-versies ze bijna niet meer accepteren.
- Waar de data staat, wie die kan lezen en wat een GDPR-verzoek in de praktijk zou vergen.
- Hoeveel er door tests gedekt is, en of die tests nog slagen.
- De delen die nog niemand zou moeten aanraken, en wat er nodig is om daar verandering in te brengen.
Wat je krijgt voordat iemand een bouwtraject offreert
- Wat er mis is, in gewone taal, met bij elk punt het risico in plaats van een ernstniveau.
- Wat er hersteld moet zijn voordat er iets nieuws bovenop kan.
- Wat we bewust met rust laten, en waarom.
- Waar één onderdeel opnieuw bouwen echt goedkoper is dan het repareren – ook dat staat in de doorlichting.
Daarna wordt de bouw in die volgorde geoffreerd
Eerst stabiliseren, dan nieuwe functionaliteit, allebei voor een vaste prijs. De prijs van dat tweede deel volgt uit wat de doorlichting heeft gevonden, niet uit een gok van voordat iemand de repository had geopend. Blijkt de codebase er te slecht aan toe om over te nemen, dan zeggen we dat – en dan heb je nog altijd een eerlijk antwoord gekocht.
Het eerlijke deel
Hoe het er nu voor staat.
Getizy is uitgebracht in de App Store en Google Play. De dienst is niet langer publiek beschikbaar.
Die zin blijft op deze pagina staan. Waar we voor kunnen instaan, is het technische werk: we namen een product over dat door iemand anders was gebouwd, maakten het stabiel en bleven er nieuwe versies van uitbrengen. Wat er daarna met het bedrijf gebeurde, is niet aan ons om te vertellen.
Cijfers staan hier ook niet. Wij waren het ontwikkelbedrijf, niet het bedrijf zelf – het was nooit aan ons om installaties, omzet en groei te publiceren.
Wat we een volgende keer anders doen.
Het releaseproces meteen overnemen.
We losten al echte defecten op voordat we op eigen kracht een release konden uitbrengen. Ondertekening, certificaten en toegang tot de stores vragen we bij het overnemen van een codebase nu als eerste, nog vóór de buglijst – zolang dat niet geregeld is, kan het werk af zijn en toch niemand bereiken.
Het lezen apart offreren.
We leerden die codebase kennen terwijl het bouwtraject al liep. Het product van iemand anders goed doorlezen kost dagen, dus is dat nu apart, betaald werk dat vóór de offerte gebeurt – en het bedrag dat eruit komt, is gebaseerd op wat er werkelijk staat.
Iets nieuws beginnen, of iets bestaands overnemen
Allebei even normaal. Een nieuw project wordt afgebakend en geprijsd voordat er één regel geschreven is. Bij een bestaande codebase begint het met de betaalde doorlichting; de prijs voor de bouw komt daarna.
Eén kort formulier, antwoord binnen één werkdag. Zijn we niet de juiste studio ervoor, dan zeggen we dat.