Leverandøren er stoppet, bureauet er blevet for dyrt, eller den udvikler, der byggede systemet, har sagt op — og nu tør ingen røre koden. Det er en af de mest almindelige grunde til, at virksomheder kontakter mig, og det første, de skal høre, er som regel en lettelse: det er næsten altid billigere at redde kodebasen end at bygge forfra.
En overtagelse behøver ikke være et tillidsspring. Gjort rigtigt er den en struktureret proces med et beslutningspunkt undervejs, hvor du kan stoppe uden at have forpligtet dig til andet end et code review. Sådan griber jeg det an efter 15+ år med Laravel udvikling — fra begge sider af bordet.
Sjældent — men det sker. Hvis kodebasen er lille, kernen er rådden, og forretningen alligevel skal noget helt andet, kan en fokuseret genopbygning være ærligere end en lang redningsaktion. Det er dog undtagelsen: en kørende applikation indeholder årevis af indarbejdede forretningsregler og kanttilfælde, som en genopbygning skal genopdage én produktionsfejl ad gangen.
Derfor er min anbefaling næsten altid: stabilisér først, modernisér derefter trinvist — mens systemet er i drift. Og fordi review og plan kommer før beslutningen, behøver du ikke tage mit ord for det; du får grundlaget sort på hvidt.
En overtagelse går hurtigst, når adgangene er på plads. Du skal typisk bruge: læseadgang til Git-repositoriet, adgang til eller dokumentation af hosting og databaser, en liste over tredjepartstjenester (betaling, mail, integrationer) — og gerne den gamle leverandørs sidste faktura, så omfanget af løbende arbejde er kendt. Mangler noget af det hos den tidligere leverandør, hjælper jeg med at få det hjem; det er i sig selv en vigtig del af at eje sin egen løsning.
Fortæl mig kort om systemet og situationen, så får du et fast prissat tilbud på et code review — og derefter en risikoliste og en plan, du ejer, uanset hvem der skal udføre den. Første samtale er gratis og uforpligtende.
Få et code review-tilbud