AI-koderedning — Lever det AI startet

//symptomene

Mønsteret som får gründere til å komme hit

MVP-en din fungerte den første dagen. Så begynte det å bli rart.

Funksjoner som før tok en time å levere, tar nå en uke.
En kunde melder fra om noe som ikke skulle være mulig — og du klarer ikke å finne ut hvordan det skjedde.
AI-en skriver fortsatt gjerne kode. Men for hver nye ting den legger til, ser det ut som om noe gammelt ryker.
Du ligger våken om natten og lurer på "hva mer er galt der inne?"
En innleid utvikler sluttet (eller fikk sparken), og ingen på teamet i dag klarer å lese koden.
Du har vokst ut av Bubble / Webflow / Supabase Edge Functions og må over på noe annet uten å ødelegge produktet.

Høres dette kjent ut? Da er det et typisk oppdrag for meg.

//hva en redning faktisk er

Revisjon er et dokument. Redning er en kodebase.

I et redningsoppdrag tar jeg over ansvaret for det tekniske arbeidet. Jeg leser koden din slik jeg ville lest en kodebase jeg nettopp hadde blitt satt til å overta — raskt, men grundig. Jeg prioriterer etter forretningsrisiko. Så fikser jeg.

Arbeidet skjer i risikosorterte runder, ikke som én stor omskriving på en gang. Du ser fungerende fremdrift med noen dagers mellomrom; ingenting forsvinner inn i et "vi går i kjelleren i tre måneder og kommer tilbake med en ny app". Hver runde leveres for seg, testet, i et ekte miljø. De fleste redninger forløper i denne rekkefølgen:

SikkerhetshullAutentisering, autorisasjon, hemmeligheter, validering av inndata. Alt som kan lekke data, la noen utgi seg for å være en annen bruker, eller blottlegge betalingsflyter. Disse tar vi først, fordi de er den største forretningsrisikoen og billigst å fikse når de først er funnet.

DataintegritetProblemer med datamodellen, manglende begrensninger, stille datatap, ødelagte migreringer. Det som i det stille ødelegger produktet ditt hvis det får ligge. Data du mister på denne måten, kommer vanligvis ikke tilbake.

Drift og overvåkingDomeneoppsett, HTTPS, atskilte miljøer, CI/CD, overvåking, sikkerhetskopier, katastrofegjenoppretting. De "siste 20 prosentene" som AI-verktøy hopper over. Uten dette har du ikke et produkt — du har en demo som tilfeldigvis kjører på internett.

Ytelse og skaleringManglende indekser, N+1-spørringer, minnelekkasjer, ingen caching. Det som skiller en app som fungerer med 10 brukere, fra en som fungerer med 1 000. Vanligvis fikset på noen dager når du vet hvor du skal lete.

Vedlikeholdbar kodeRydde opp i de delene som ville stått i veien for at neste utvikler kan jobbe effektivt. Slette død kode. Legge til de testene som faktisk betyr noe (ikke "hver funksjon skal ha en enhetstest" — men de kritiske flytene, dekket av integrasjonstester).

//omfang

Hva som er inkludert, hva som er ekstra

Inkludert som standard

Full gjennomlesning og prioritering av den eksisterende kodebasen
Sikkerhetsfikser — autentisering, autorisasjon, hemmeligheter, validering av inndata
Driftsoppsett — domene, HTTPS, atskilte miljøer, CI/CD, overvåking, sikkerhetskopier
Opprydding i databasen — indekser, migreringer, ytelse, integritetsbegrensninger
Sikring av tredjepartsintegrasjoner (Stripe-webhooks, e-postlevering, autentiseringsleverandører)
Opprydding i kritiske kodeflyter for bedre vedlikeholdbarhet
Skriftlig overleveringsdokument til neste utvikler

Ikke inkludert som standard

Utvikling av nye funksjoner utover det som trengs for å sette i drift på en trygg måte
Visuell redesign av front-end
Full migrering til en ny plattform (f.eks. Bubble → Node.js) — avtales separat som et migreringsprosjekt
Løpende fractional CTO / langsiktig teknisk ansvar — tilgjengelig som et oppfølgingsoppdrag
Utvikling av mobilapp
Produkt- / UX-arbeid

Omfanget er ikke hugget i stein — trenger situasjonen din en variant av standarden, tilpasser vi omfanget deretter. Men det er standarden 80 % av redningsoppdragene lander på.

//slik foregår det

Prosessen

1. Revisjon først

Alltid. Hvis du ikke allerede har hatt en med meg, gjør vi en revisjon først. En redning uten revisjon er å fly i blinde — da ville vi enten tatt for mye i omfanget (dyrt for deg) eller oversett noe kritisk (dårlig for oss begge). Revisjonen gjør også redningens omfang konkret.

2. Redningsplan

Bygget på funnene fra revisjonen. Du godkjenner omfang, prioriteringsrekkefølge og tidsplan før noe arbeid settes i gang. Fast pris, fast omfang.

3. Fiks i risikosorterte runder

Arbeidet skjer i 3–5 atskilte runder, hver leveres for seg på 1–2 uker. Du får fremdrift du kan etterprøve med noen dagers mellomrom — ingen lange perioder i blinde.

4. Klarsignal for produksjon

Appen kjører. Overvåkingen er på. Sikkerhetskopiene er testet. Dokumentasjonen er skrevet. Jeg viser deg hver av disse tingene i funksjon før vi avslutter.

5. Overlevering

To alternativer: enten til teamet ditt (med dokumentasjon + 2 ukers støtte over Slack inkludert), eller så blir jeg værende som fractional deltidsutvikler i 3–6 måneder mens du ansetter. Du velger.

Tidsramme: 4 til 12 uker. De fleste redninger lander på 6–8 uker. Du får en bindende tidsramme før arbeidet starter.

//hvem det er for

Du bør bestille en redning hvis…

Du har en MVP med betalende kunder eller en signert pilot. Hvis ikke, bør du satse på å skaffe brukere først.
Du har hatt en revisjon og vet at dette ikke bare er et par raske fikser på en ettermiddag — det er reelt ingeniørarbeid som må gjøres.
Du klarer ikke å få tak i en senior utvikler raskt, og du vil ikke bruke de neste seks månedene på intervjuer.
Du vil heller at noen tar over hele den tekniske byrden, slik at du kan konsentrere deg om salg, produkt eller kapitalinnhenting.
En finansieringsrunde, en kontrakt med en stor bedriftskunde eller en myndighetsgjennomgang er på vei, og dagens kodebase tåler ikke å bli sett nærmere etter i sømmene.

Du bør ikke bestille en redning hvis…

Du har ikke validert produktet ennå. En redning er et oppdrag som går over flere uker — ikke verdt det for en idé som ikke er validert.
Du vil fortsette å bruke AI-verktøy til å skrive koden på ubestemt tid mens jeg "rydder opp etter dem". Det er ikke avtalen. Jeg fikser kodebaser; jeg passer ikke prompter.
Du har bare én eller to konkrete ting som må fikses (f.eks. bare CORS-oppsettet). Da bør du heller leie meg inn for de enkelte funnene — billigere og raskere.

//pris

Slik fungerer prisen

Pris per oppdrag, ikke per time. Revisjonen gir en konkret liste over funn, og vi setter omfanget på redningen etter den listen. Du får en fast sum og en fast tidsramme før arbeidet starter. Må oppdraget utvides, avtaler vi nytt omfang sammen — ingen overraskelser på fakturaen midt i prosjektet.

Det som avgjør summen: hvor stor kodebasen er, hvor mye av teknologien som må utbedres, hvor mye det haster, og om oppdraget avsluttes med en ren overlevering eller går over i en midlertidig fractional-ordning. Vi avklarer alt dette på den første samtalen.

//vanlige spørsmål

Spørsmål gründere stiller før de bestiller

Den er din. Redningen leverer en kodebase som neste utvikler kan vedlikeholde uten meg. Et skriftlig overleveringsdokument følger med. Vil du ha meg med en periode etter leveransen mens du ansetter, er det et eget oppdrag — ikke noe du blir avhengig av.

Nei. Å skrive om fra bunnen er som regel feil løsning — det er dyrt, tar lengre tid enn planlagt, og løser ofte ikke det underliggende problemet. Redningen fikser de ødelagte delene og lar de som fungerer, være i fred. Hvis en bestemt modul virkelig må skiftes ut, avgrenser vi det som et tydelig definert arbeidsstykke i stedet for en omskriving av alt.

Revisjonen alene gir reell verdi selv om du aldri går videre til en redning. Du kan også leie meg inn for enkeltfunn fra revisjonen — bare CORS-fiksen, bare omskrivingen av autentiseringen, bare CI/CD-oppsettet. Det er spesielt nyttig når revisjonen avdekker ett eller to store problemer du kan ta hånd om på egen hånd.

Oppdrag som fractional teknisk medgründer er mulig etter en vellykket redning. Det er vanligvis en midlertidig ordning på 3–6 måneder der jeg blir værende på deltid mens du rekrutterer en senior utvikler eller CTO på heltid. Ingen permanent forpliktelse for noen av partene.

Solid ekspertise i PHP (Symfony, Doctrine), Node.js, TypeScript, React, AWS (ECS, Lambda, RDS, SQS, SNS), Docker og Terraform. Jeg har reddet apper bygget med Supabase, Firebase, Vercel og de fleste no-code-verktøy. Hvis stacken din ligger utenfor disse områdene, sier jeg ærlig fra på den første samtalen om jeg er rett mann for jobben.

4 til 12 uker. De fleste redninger lander i området 6–8 uker. Nøyaktig tidsramme avhenger av hva revisjonen finner og hvor stor MVP-en din er. Du får en fast forpliktelse på tidsrammen før arbeidet starter, ikke et åpent oppdrag basert på timepris.

Ja, men det avtales separat fra en vanlig redning. Å migrere bort fra no-code til en ny kodebase er en annen type oppdrag — det omfatter å designe den nye arkitekturen, datamigrering og en plan for selve overgangen. Men samme revisjon-først-tilnærming gjelder: vi starter med en samtale om omfang og en revisjon av det du flytter fra.

Vil du se hvordan et slikt oppdrag ser ut i praksis? Les en ekte casestudie →