AI-koderedning — Lever det AI startet

//symptomene

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

MVP-et ditt fungerte dag én. Så begynte det å bli rarere.

Funksjoner som pleide å leveres på en time tar en uke.
En kunde rapporterer noe som ikke skulle være mulig — og du kan ikke finne ut hvordan det skjedde.
AI-en skriver fortsatt gjerne kode. Men hver nye ting den legger til ser ut til å ødelegge noe eldre.
Du mister søvn over "hva mer er galt der inne?"
En konsulent sluttet (eller ble sparket), og ingen i det nåværende teamet kan lese koden.
Du har vokst ut av Bubble / Webflow / Supabase Edge Functions og må flytte uten å ødelegge produktet.

Høres kjent ut? Det er engasjementets form.

//hva en redning faktisk er

Revisjon er et dokument. Redning er en kodebase.

I et redningsengasjement tar jeg over eierskapet til det tekniske arbeidet. Jeg leser koden din slik jeg ville lest en kodebase jeg nylig ble ansatt på — raskt, men grundig. Jeg prioriterer etter forretningsrisiko. Så fikser jeg.

Arbeidet skjer i risikosorterte passeringer, ikke som en enkelt big-bang-omskriving. Du ser fungerende fremgang hver par dager; ingenting "gå mørk i tre måneder og komme tilbake med en ny app". Hver passering leveres uavhengig, testet, i et ekte miljø. De fleste redninger utvikler seg i denne rekkefølgen:

SikkerhetshullAutentisering, autorisasjon, hemmeligheter, inputvalidering. Alt som kan lekke data, la noen utgi seg for å være bruker, eller eksponere betalingsflyter. Disse går først fordi de er den største forretningsrisikoen og billigst å fikse når de er identifisert.

DataintegritetSkjemaproblemer, manglende begrensninger, stille datatap, ødelagte migrasjoner. Tingene som stille korrumperer produktet ditt hvis de forlates. Data du mister til disse problemene kommer vanligvis ikke tilbake.

Deployment og observerbarhetDomeneoppsett, HTTPS, miljøseparasjon, CI/CD, overvåkning, backupper, disaster recovery. De "siste 20%" AI-verktøy hopper over. Uten disse 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å dager når du vet hvor du skal lete.

KodevedlikeholdbarhetRefaktorering av delene som ville blokkere neste ingeniør fra å være effektiv. Å slette død kode. Legge til testene som betyr noe (ikke "hver funksjon har en enhetstest" — de kritiske flytene med integrasjonstester).

//omfang

Hva som er inkludert, hva som er ekstra

Inkludert som standard

Full gjennomlesning og triage av den eksisterende kodebasen
Sikkerhetsfikser — auth, autorisasjon, hemmeligheter, inputvalidering
Deployment-pipeline — domene, HTTPS, miljøseparasjon, CI/CD, overvåkning, backupper
Databaseopprydding — indekser, migrasjoner, ytelse, integritetsbegrensninger
Herding av tredjeparts-integrasjoner (Stripe-webhooks, e-postlevering, auth-leverandører)
Refaktorering av kritiske baner for vedlikeholdbarhet
Skriftlig overleveringsdokument for neste ingeniør

Ikke inkludert som standard

Utvikling av nye funksjoner utover det som trengs for sikker levering
Visuell front-end-redesign
Full migrasjon til en ny plattform (f.eks. Bubble → Node.js) — skopes separat som et migrasjonsprosjekt
Løpende fractional CTO / langsiktig teknisk eierskap — tilgjengelig som oppfølgingsengasjement
Mobilapputvikling
Produkt- / UX-arbeid

Omfanget er ikke rigid — hvis situasjonen din krever en variant av standarden, skoper vi deretter. Men standarden er der 80% av redningsengasjementene lander.

//how it works

Process

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 blindt — vi ville enten overskopere (dyrt for deg) eller gå glipp av noe kritisk (dårlig for oss begge). Revisjonen gjør også redningsomfanget konkret.

2. Redningsplan

Bygget fra revisjonens funnlogg. Du godkjenner omfang, prioriteringsrekkefølge og tidslinje før noe arbeid starter. Fast pris, fast omfang.

3. Fikse i risikosorterte passeringer

Arbeidet skjer i 3–5 distinkte passeringer, hver leveres uavhengig på 1–2 uker. Du får fremgang du kan verifisere hver par dager — ingen lange mørke perioder.

4. Produksjonsgodkjenning

Appen kjører. Overvåkning er på. Backupper er testet. Dokumentasjon er skrevet. Jeg demonstrerer hver av disse tingene i funksjon før vi avslutter.

5. Overlevering

To alternativer: enten til teamet ditt (med dokumentasjon + 2 uker Slack-basert støtte inkludert), eller jeg blir værende som fractional part-time-utvikler i 3–6 måneder mens du ansetter. Ditt valg.

Tidslinje: 4 til 12 uker. De fleste redninger lander på 6–8 uker. Du får et forpliktelse om tidslinje 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. Ellers, fokuser på trafikken først.
Du har hatt en revisjon og du vet at dette ikke bare er noen ettermiddagsfikser — det er ekte ingeniørarbeid å gjøre.
Du kan ikke finne en senior utvikler å ansette raskt, og du vil ikke bruke de neste seks månedene på intervjuer.
Du foretrekker at noen tar over den tekniske byrden helt så du kan fokusere på salg, produkt eller kapitalinnhenting.
En finansieringsrunde, enterprise-kundekontrakt, eller regulatorisk gjennomgang er på vei, og din nåværende kodebase vil ikke overleve gransking.

Du bør ikke bestille en redning hvis…

Du har ikke validert produktet ennå. En redning er et flerukers engasjement — ikke verdt det for en uvalidert idé.
Du vil fortsette å bruke AI-verktøy for å skrive koden på ubestemt tid mens jeg "rydder opp etter dem". Det er ikke avtalen. Jeg fikser kodebaser; jeg passer ikke på prompts.
Du har bare en eller to spesifikke ting å fikse (f.eks. bare CORS-oppsettet). Hyr meg for de individuelle funnene i stedet — billigere og raskere.

//pricing

How pricing works

Priset per engasjement, ikke per time. Revisjonen produserer en konkret funnliste; vi skoper redningen mot den listen. Du får en fast sum og en fast tidslinje før arbeidet starter. Hvis engasjementet må utvides, skoper vi om sammen — ingen overraskende fakturaer midt i prosjektet.

Hva som driver summen: kodebasens størrelse, hvor mye av stacken som trenger utbedring, hast, og om engasjementet slutter med en ren overlevering eller går over til en midlertidig fractional-ordning. Vi avgjør alt dette på introduksjonssamtalen.

//common questions

Questions founders ask before they book

Det er ditt. Redningen leverer en kodebase som neste ingeniør kan vedlikeholde uten meg. Et skriftlig overleveringsdokument følger med. Hvis du vil ha meg rundt etter leveransen i en midlertidig periode mens du ansetter, er det et separat engasjement — ingen avhengighet.

Nei. Omskrivninger er vanligvis feil svar — de er dyre, tar lengre tid enn planlagt, og fikser ofte ikke det underliggende problemet. Redningen fikser de ødelagte delene og lar de fungerende være i fred. Hvis en spesifikk modul virkelig trenger utskifting, skoper vi det som et navngitt arbeidsstykke i stedet for en altomfattende omskriving.

Revisjonen alene leverer ekte verdi selv om du aldri redder. Du kan også hyre meg for enkelte funn fra revisjonen — bare CORS-fiksen, bare auth-omskrivningen, bare CI/CD-oppsettet. Dette er spesielt nyttig når revisjonen avdekker ett eller to store problemer du kan håndtere uavhengig.

Fractional teknisk medgründer-engasjementer er tilgjengelige etter en vellykket redning. Dette er vanligvis en 3–6 måneders midlertidig ordning hvor jeg blir værende deltid mens du rekrutterer en heltids senior ingeniør eller CTO. Ingen permanent forpliktelse på noen av sidene.

Sterk ekspertise i PHP (Symfony, Doctrine), Node.js, TypeScript, React, AWS (ECS, Lambda, RDS, SQS, SNS), Docker, Terraform. Jeg har reddet apper bygget med Supabase, Firebase, Vercel og de fleste no-code-verktøy. Hvis stacken din er utenfor disse områdene, sier jeg deg ærlig på introduksjonssamtalen om jeg er riktig redder for situasjonen.

4 til 12 uker. De fleste redninger lander i området 6–8 uker. Nøyaktig tidslinje avhenger av hva revisjonen finner og hvor stor MVP-et ditt er. Du får et fast tidslinjeforplikelse før arbeidet starter, ikke et åpent timebasert engasjement.

Ja, men det skopes separat fra en vanlig redning. Å migrere bort fra no-code til en ny kodebase er en annen engasjementsform — det inkluderer å designe den nye arkitekturen, datamigrasjon og en cutover-plan. Samme audit-first-tilnærming likevel: vi starter med en scoping-samtale og en revisjon av det du flytter fra.

Want to see what an engagement like this looks like in practice? Read a real case study →