Vad jag lärt mig från att bygga flera små SaaS-produkter med AI
Jag har byggt flera mindre AI-produkter med ganska olika mål: CV-verktyg, jobbmatchning, utbildningsflöden, contentproduktion, analys och automatisering. Det mest användbara jag fått ut av det är inte en favoritmodell eller en perfekt stack.
Jag har byggt flera mindre AI-produkter med ganska olika mål: CV-verktyg, jobbmatchning, utbildningsflöden, contentproduktion, analys och automatisering. Det mest användbara jag fått ut av det är inte en favoritmodell eller en perfekt stack. Det är ett antal beslut som jag numera tar mycket tidigare än förut.
Små SaaS-produkter är bra lärare eftersom de snabbt avslöjar vad som faktiskt måste fungera. Det går inte att gömma sig bakom en roadmap på arton månader. Användaren kommer med en fil, en fråga eller ett jobb som ska lösas och förväntar sig att systemet gör något vettigt nu.
1. En bra demo är inte samma sak som en bra produkt
Det är lätt att bygga ett lyckat happy path-exempel. Jag kan ge modellen ett välskrivet CV, en tydlig annons och få ett imponerande svar. Det verkliga arbetet börjar när CV:t saknar datum, annonsen är dåligt skriven, användaren laddar upp fel fil eller modellen ger ett förslag som låter bra men inte går att belägga.
Jag försöker därför numera samla edge cases nästan direkt. Inte hundratals från början, men tillräckligt för att se produktens verkliga yta.
En prototyp bevisar att något kan fungera. Ett eval-set börjar visa hur ofta och under vilka villkor det fungerar.
2. Modellen är sällan den viktigaste datamodellen
I början är det lockande att behandla allting som text. Efter några projekt blir det tydligt hur dyrt det är.
CV-information bör ha en strukturerad representation. En contentartikel bör ha status, källor, claims och QA-resultat. Ett utbildningssystem bör veta vilka frågor, områden och försök som hör ihop. Ett agentflöde bör ha explicita states.
Det gör två saker. För det första kan jag testa regler utan att be en LLM resonera varje gång. För det andra kan jag byta modell utan att hela produkten tappar minnet om vad den håller på med.
3. "AI-feature" och "AI-produkt" kräver olika disciplin
Att lägga till en sammanfattningsknapp i en befintlig produkt är en sak. Att låta AI vara en central del av värdeleveransen är något annat. Gränsen går vid om produkten fortfarande fungerar utan modellen: en CV-builder som får en "förbättra text"-knapp är fortfarande samma produkt utan AI. Ett system där research, analys, anpassning och feedback kontinuerligt genereras från användarens kontext är det inte — där är AI en central del av både värdet och riskbilden.
Den skillnaden avgör hur mycket jag måste investera. En feature kan ha en enkel fallback när modellen fallerar. En AI-produkt behöver evals, observability, routing, policy och kostnadskontroll som förstaklassproblem, inte som eftertankar.
Om användaren betalar för själva AI-resultatet behöver jag därför tänka på:
- sanningskälla,
- evals,
- felmoder,
- kostnad per lyckad uppgift,
- retries,
- modellbyte,
- latency,
- användargodkännande,
- support när svaret blir fel.
Det är lätt att prata om "AI SaaS" som om API-anropet vore produkten. I praktiken är API-anropet ofta den enklaste delen.
4. Workflow före features sparar mycket ombyggnad
När jag har haft en tydlig kedja från input till resultat har det varit lättare att lägga till funktioner. När jag börjat i featurelistan har logiken oftare läckt mellan UI, prompt och databas.
Jag vill numera kunna beskriva ett kärnflöde ungefär så här:
Sedan kan jag lägga voice, fler modeller, fler exportformat eller automation ovanpå. Om grundkedjan inte är stabil gör varje ny feature systemet svårare att förstå.
5. Betalväggen ska sitta efter värdet blivit begripligt
I små konsumentnära SaaS-produkter är friktion dyr. Samtidigt går det inte att ge bort hela värdet om affären ska fungera.
Jag försöker därför tänka i "proof of value" snarare än bara free vs premium. Användaren bör förstå vad produkten kan göra innan betalningen känns som ett hopp i mörkret.
För en CV-produkt kan det vara en begränsad analys eller ett tydligt exempel på förbättring. För ett utbildningsverktyg kan det vara en viss mängd träning innan full provsimulering eller avancerad uppföljning låses upp.
Det viktiga är att gratisnivån inte bara är en tom teaser. Den måste ge tillräcklig evidens för att användaren ska förstå premiumvärdet.
6. Den dyraste modellen är sällan rätt default
Olika steg har olika krav. Extraktion kan vara enkel. En svår kvalitetsbedömning kan kräva mer resonemang. En slutlig formulering kanske behöver en bättre skrivmodell. En verifiering kan vara deterministisk.
När allt körs på den dyraste modellen blir ekonomin dålig. När allt körs på den billigaste blir kvaliteten ojämn. Därför har jag blivit mer intresserad av routing än av att utse en universell vinnare.
Det här ligger nära den bredare utvecklingen mot system där modellval görs per uppgift och evals används för att avgöra om ett modellbyte faktiskt förbättrar produkten. Anthropic betonar i sin eval-guidance att agentiska system behöver bedömas end-to-end eftersom fel kan uppstå i flera steg, inte bara i ett enskilt svar. Anthropic: Demystifying evals for AI agents
7. Support är en del av modellarkitekturen
Ett fel i en vanlig SaaS-funktion kan ofta reproduceras med samma input. Ett generativt fel kan vara mer svårfångat. Därför behöver supporten veta vilken modell, promptversion, kontext, tool call och output som användes.
Det här har gjort observability mer konkret för mig. Jag vill inte bara veta om API:t svarade 200. Jag vill kunna förstå varför användarens resultat blev dåligt.
8. Jag försöker automatisera först när jag kan beskriva stoppregeln
Det är lätt att automatisera en process som "nästan alltid" fungerar. Det svåra är att definiera vad som händer när den inte gör det.
En contentpipeline blev mycket mer robust när BLOCKED blev ett legitimt state. Samma princip fungerar i andra produkter: hellre "jag saknar underlag" än en smidig hallucination.
Det förändrar också produktens ton. Systemet behöver inte låtsas vara allvetande för att kännas användbart.
9. Små produkter behöver mindre arkitektur – men tydligare gränser
Jag vill inte bygga en enterpriseplattform för varje idé. Men jag vill ändå hålla några gränser rena:
- fakta kontra genererad text,
- användardata kontra modellkontext,
- deterministisk logik kontra bedömning,
- läsbehörighet kontra skrivbehörighet,
- draft kontra publicerat resultat.
Det gör att produkten kan vara liten utan att vara skör.
Det viktigaste jag har ändrat
Tidigare tänkte jag mer i features: "kan vi lägga till AI här?" Nu tänker jag mer i jobb, evidens och felbudget.
Vilket jobb ska bli klart? Vilket underlag får systemet använda? Vilket fel är acceptabelt? Hur upptäcker vi regression? Vad händer när modellen inte vet?
När de frågorna är besvarade blir modellval och gränssnitt mycket enklare. Det är kanske den största lärdomen från att bygga flera små AI-SaaS: AI gör prototyper billigare, men den gör produktdisciplin mer värdefull, inte mindre.