Sådan erstatter du et afgrænset SaaS-abonnement med dit eget AI-byggede værktøj

Guiden handler om at erstatte et afgrænset virksomheds-SaaS-værktøj, for eksempel en formularbygger, et internt dashboard eller en enkel arbejdsgang, med software bygget gennem en AI-agent. Den erstatter ikke Claude Code eller modeladgangen: Agent og model indgår stadig i bygge- og vedligeholdelsesomkostningerne.

Der findes flere instruktioner i Ailoot-dokumentationen.

Derfor blev det mere omkostningseffektivt at bygge selv end at betale for et abonnement i 2026#

For bare et par år siden krævede det at erstatte en betalt tjeneste med sin egen app, at man ansatte udviklere, ventede i månedsvis og betalte hundredtusindvis. Derfor købte alle bare et abonnement. I dag sætter en iværksætter sig sammen med en AI-agent og bygger et værktøj på en weekend, der løser opgaven.

Det er ikke længere enkeltstående historier. Ifølge Retools rapport “Build vs. Buy” fra 2026, en undersøgelse blandt 817 personer, har 35 % af teams allerede erstattet mindst én betalt SaaS-tjeneste med en intern løsning, og 78 % planlægger at bygge flere af deres egne værktøjer i år. Halvdelen af dem, der fik deres løsning til at fungere, sparer mere end 6 timer om ugen.

Presset er størst i de dyreste og mindst fleksible kategorier: interne administrationspaneler, rapportering, CRM-systemer, formularværktøjer og automatiseringer. Det er præcis den slags, små virksomheder betaler mest for og bruger mindst.

Hvad du bør bygge selv, og hvad du bør beholde på abonnement#

Begyndere forsøger ofte at erstatte alt på én gang med deres egen app, også det, der holder virksomheden oven vande. Det går ikke: Her er der en tydelig grænse.

Det giver mening at bygge selv, når du bruger værktøjet hver dag og ved præcis, hvad der mangler. Behold et abonnement, når fejl er dyre, og alt, der går i stykker, kræver hurtig reparation uden mulighed for nedetid.

Jo tættere opgaven er på penge, lovgivning og andre menneskers personoplysninger, desto stærkere er argumentet for en færdig tjeneste. Jo mere det er dit personlige arbejdsredskab, desto sikrere er det at bygge det selv.

Beregn på 5 minutter: Er det billigere at bygge selv end at have et abonnement?#

Beregn omkostningerne, før du bygger noget. Formlen er enkel:

Omkostninger ved egen løsning = hosting + modelomkostninger + din tid på at bygge og vedligeholde den

Sammenlign derefter med det årlige abonnement.

Der er også en tærskel, som afhænger af antallet af brugere. Når der er få brugere (omtrent op til ti), er en færdig tjeneste næsten altid billigere og enklere. Når antallet af brugere vokser (til et par dusin eller flere), bliver din egen løsning som regel mere omkostningseffektiv – hvis du også medregner din egen tid.

De fem byggesten i enhver tjeneste, du bygger selv#

Når du ser på en færdig tjeneste, kan det virke, som om der foregår magi indeni. I praksis består næsten alle enkle værktøjer af fem byggesten. Hvis du forstår dem, bliver det lettere at tale samme sprog som AI-agenten.

1. Brugerflade – det, en person ser

   Skærmen, knapperne og formularerne. Her indtaster du og dit team data og ser resultaterne.

2. Data – hvor alt bliver gemt

   En kundeliste, forespørgsler, historik. Det sted, værktøjet henter information fra og lægger information ind.

3. Login – hvem der er inde

   Kontrol af, at en person er den, vedkommende udgiver sig for at være. Normalt logger man ind med en kode sendt via e-mail uden brug af adgangskode.

4. Hosting – hvor det kører

   Din tjeneste skal køre et sted døgnet rundt, så den kan åbnes fra et link. Det sted kaldes hosting.

5. Modtagelse af betalinger – hvis du sælger noget

   Hvis der går penge gennem værktøjet, skal du bruge en betalingsgateway. Det er et særskilt emne med egne regler.

AI-agenten klarer næsten alt i de første fire byggesten. Du beskriver med ord, hvad du vil have, og så bygger og forklarer den det. Det er ligegyldigt, hvordan datalagringen er sat op. Det vigtige er, at forespørgsler ikke går tabt, og at søgninger er hurtige.

Sådan bygger du en erstatning på en aften: trin for trin#

Forsøg ikke at genskabe hele den anden tjeneste – det er hele pointen. Du betaler for et produkt med hundrede funktioner, men bruger fem. Byg de fem.

1. Skriv ned, hvad du faktisk bruger

   Åbn den tjeneste, du betaler for, og skriv ærligt de funktioner ned, du bruger hver uge. Som regel er det 3–5 ud af hundrede.

2. Beskriv opgaven med ord

   I et enkelt sprog: Hvad indtaster du, hvad vil du gerne have ud af det, og hvem skal bruge det?

3. Bed om en plan før kode

   Bed agenten om at vise dig en byggeplan, før den begynder at skrive. Så kan du opdage, hvis den er på vej i den forkerte retning, fra starten.

4. Byg en afgrænset første version

   Bed agenten om kun at bygge dine 3–5 funktioner. Ikke andet.

5. Test med dine egne data

   Indlæs reelle data, og kør værktøjet sideløbende med den gamle tjeneste i et par dage uden at lukke den gamle ned.

Her er den færdige prompt, jeg anbefaler at begynde med. Erstat det, der står i firkantede parenteser, med dine egne oplysninger:

You are my technical partner. I am an entrepreneur, not a programmer. I want to build a simple internal tool instead of a paid subscription to [service name].

I pay for this service now, but I only use these features:

[feature 1]

[feature 2]

[feature 3]

Build a prototype that covers only these features and nothing beyond them.

First show me a plan: what parts the tool will consist of, the simplest set of tools available for my account and region, and where the data will be stored. Explain the plan in my preferred language, in simple words, without jargon.

Wait for my approval and only then write the first working version. After each step, explain what you did and why.

Hvad iværksættere allerede har erstattet#

For at gøre det mindre teoretisk får du her nogle offentlige historier fra 2026. De har én ting til fælles: Folk erstattede interne arbejdsredskaber. Ingen rørte ved betalinger eller regulering.

Mønstret er det samme: De, der kender tjenesten, der skal erstattes, i detaljer, vinder mest. De flytter præcis det, de bruger, over i deres eget værktøj uden at forsøge at opfinde produktet på ny. Derfor kan en ekspertbruger bygge en erstatning på en weekend, mens en, der ikke har fundet ud af sin egen opgave, kan kæmpe i ugevis.

Den oprindelige forfatter har i løbet af det seneste år bygget et par interne værktøjer til eget brug i stedet for at købe færdige løsninger. Når man ved præcis, hvad man har brug for, viser det sig at være hurtigere end at sætte en andens produkt op. Jeg viste en lignende gennemgang af, hvordan du selv bygger et fungerende dashboard med virksomhedens nøgletal, i guiden om et dashboard med virksomhedens nøgletal.

Hvad din egen løsning koster om måneden sammenlignet med et abonnement#

Lad os vende tilbage til det, jeg lovede i begyndelsen. Det er let at fejre, at man opsiger et abonnement, og overse, at udgifterne bare har ændret form.

Se på historien om Salesforce-erstatningen igen. Abonnementsregningen faldt til nul – det er rigtigt. Men AI-modellens regning hos samme virksomhed voksede flere gange, og de står selv for vedligeholdelsen. Besparelsen er reel, men den er ikke “hele abonnementsprisen sparet”. Regnestykket er: abonnementsomkostning minus, modelomkostning plus, din egen tid plus.

Beregn derfor alle tre omkostninger ærligt:

• Hosting. Hostingomkostninger.
• Modelomkostninger. Det afhænger af, hvor meget AI arbejder. I begyndelsen, mens du bygger, er omkostningen mærkbart højere; senere er den lavere.
• Din tid. Den mest usynlige omkostning. Byggeri, opdateringer, “det gik i stykker fredag aften”. Sæt en pengeværdi på din time, og medregn den.

Når du har beregnet alle tre, har du et ærligt tal. Ofte er det stadig lavere end et dyrt abonnement – især når du bygger ét afgrænset værktøj i stedet for en hel platform. Men nogle gange koster abonnementet mindre end din tid, og det er et fuldt gyldigt resultat af beregningen. Jeg gennemgik de skjulte omkostninger ved vibe coding mere detaljeret i en separat guide om hvorfor vibe coding koster mere, end det ser ud til.

Risici ved din egen løsning, og hvordan du håndterer dem#

En ærlig gennemgang af ulemperne. At bygge løsningen er halvdelen af arbejdet. Bagefter skal du selv stå for den, og det er her, risici, som begyndere ikke tænker på, gemmer sig.

Der er ingen at spørge: “Hvorfor blev det gjort sådan?” Koden blev ikke skrevet af nogen på dit team. Seks måneder senere går noget i stykker, og den person, der husker logikken, er ikke længere til stede. Det kaldes et ansvarsgab.

Sikkerhed. En AI-agent kan efterlade en sårbarhed, du ikke opdager: et adgangspunkt, der står åbent, eller en nøgle, der er gemt som almindelig tekst. Det er acceptabelt for en intern beregner, men ikke for et register med andre menneskers data.

Datakvalitet under migrering. Hvis du straks lukker den gamle tjeneste ned og flytter flere års kundehistorik, kan nogle data gå tabt eller blive ødelagt. En omhyggelig migrering tager tid.

De, der rent faktisk har prøvet det, romantiserer ikke processen.

Det lyder hårdt, men pointen er fornuftig: Tag ikke din egen løsning i brug på områder, hvor fejl er dyre. Du kan håndtere det med tre regler:

1. Luk ikke en fungerende tjeneste ned med det samme

   Kør din løsning sideløbende med den gamle, indtil du er sikker på, at den kan klare belastningen, og at dataene er på plads.

2. Brug kun din egen løsning til ikke-følsomme data

   Interne værktøjer – ja. Andre menneskers personoplysninger og betalinger – brug betroede tjenester, eller få en ingeniør til at gennemgå løsningen.

3. Få en anden til at gennemgå koden

   Selv hvis du ikke selv kan læse kode, findes der måder at kontrollere resultatet på.

Jeg gennemgik, hvordan du kontrollerer, hvad AI har bygget, hvis du ikke kan læse kode, i guiden om hvordan du kontrollerer AI-genereret kode. Jeg beskrev generel sikkerhedshygiejne i guiden om sikkerhed ved vibe coding.

Hvornår du stadig bør betale for en færdig tjeneste#

For ikke at reducere det hele til “byg det selv” er her de tilfælde, hvor en færdig tjeneste objektivt set er bedre. Det er også ærligt at anerkende dem.

• Der kræves certificeringer og overholdelse af regler. Regulerede data, sikkerhedsrevisioner og drift i overensstemmelse med lovkrav – her skaber din egen løsning risiko i stedet for besparelser.
• Nedetid er uacceptabel. Hvis tjenesten er kritisk for virksomheden lige nu, og der ikke er tid til at bygge og fejlfinde den, fjerner et abonnement det problem.
• Der er ingen til at vedligeholde den. Din egen løsning kræver en ansvarlig. Hvis du ikke er klar til at tage det ansvar, og ingen på dit team kan gøre det, er en færdig tjeneste det mere ærlige valg.
• Du forventer, at virksomheden vokser flere gange. Det, der fungerer for ti brugere, går i stykker ved tusind. Hvis væksten er nært forestående, skal du tage højde for den fra begyndelsen.
• Produktet er kompleks infrastruktur. Modtagelse af betalinger, beskyttelse mod svindel, fakturering efter lovens krav. Her er en andens erfaring pengene værd.

Selv entusiaster for vibe coding lukker ikke uden videre fungerende tjenester ned: AI-byggede værktøjer kontrolleres før lancering, og kritisk software overlades ikke helt til automatiseret byggeri.

Hvor du skal begynde i morgen#

Her er den korte version. “Byg selv i stedet for at købe” fungerer i 2026 som en tilgang med grænser. Slagordet “byg det hele selv” gør kun skade her.

Dine næste skridt i morgen:

1. Vælg én tjeneste

   Den, du forstår bedst, med ikke-kritiske data. Et internt værktøj; lad betalinger være.

2. Beregn med formlen

   Hosting plus modelomkostninger plus din tid sammenlignet med det årlige abonnement. Gå videre, hvis det tydeligt er billigere at bygge selv.

3. Byg en afgrænset prototype

   Kun de funktioner, du faktisk bruger. Prompten i denne artikel kan hjælpe.

4. Kør den sideløbende

   I et par uger sammen med den gamle tjeneste. Opsig abonnementet, når du er sikker.

Når du har bygget dit første værktøj, og det rent faktisk virker, vil du se anderledes på alle dine abonnementer. Gå derefter fra ét værktøj til et helt system. Jeg gennemgik, hvad du kan gøre efter lanceringen af dit første produkt, i guiden om hvad du skal gøre, efter du har bygget et produkt.

Den komplette ramme for organisering af vibe coding er AI-klon + Second Brain + Context Engineering.

Når du er klar, kan du møde Ailoot.