AI-koderedning — Lever det AI startet
Jeg tar over den AI-genererte eller no-code-baserte MVP-en din, fikser det som er ødelagt, og setter den i produksjon som et ekte, vedlikeholdbart produkt. Ingen omskriving. Ingen lappverk. Ingeniørarbeidet som gjør appen din virkelig klar for betalende kunder.
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.
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:
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å.
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.
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.
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.
Vil du se hvordan et slikt oppdrag ser ut i praksis? Les en ekte casestudie →
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.
Bestill en uforpliktende samtale
Gratis. 30 minutter. Fortell meg hva som er i stykker, hva som står på spill, og når. Jeg sier ifra om en redning er rett trekk — eller om det gir mer mening med en revisjon først i ditt tilfelle.
Book en gratis samtale →