Hur mycket ska en startup lägga på första mjukvaran?
Av CodexierPublicerad 5 min läsning
Grundare kommer oftast fram till en mjukvarubudget genom att lista funktioner och prissätta dem. Det ger en siffra företaget inte har råd med och en produkt som inte besvarar någon fråga. Den bättre ordningen är omvänd: utgå från hur länge pengarna måste räcka, bestäm vad första versionen måste bevisa och dimensionera bygget efter det. Den här guiden går igenom den räkningen för en svensk startup och listar tecknen på att budgeten glidit iväg.
Budget utifrån kassan, inte önskemålen
Kassan mäts i månader av överlevnad vid nuvarande utgifter. Bygget måste lämna tillräckligt av den för att lansera, hitta användare, lära och ändra produkten. En användbar regel: om bygget och de första månaderna av drift och vidareutveckling tillsammans skulle ta mer än en tredjedel av kassan är omfattningen för stor för pengarna, hur bra funktionerna än ser ut. Minska omfattningen, inte kassan. Grundare som tar in lite och lägger det mesta på första bygget står vid lansering med en produkt och ingen förmåga att sälja eller rätta den. Vår genomgång av att finansiera en MVP i Sverige tar upp var själva kassan kan komma ifrån.
Vad första versionen måste bevisa
En första version finns för att besvara en fråga, och frågan avgör storleken. Skriv den i en mening, och pröva sedan varje funktion mot den.
| Frågan version ett besvarar | Vad som måste byggas | Vad som kan vänta |
|---|---|---|
| Kommer folk att betala för det här? | Kärnuppgiften, ett sätt att betala, ett sätt att prata med användarna | Adminpaneler, integrationer, flera roller |
| Kan vi leverera det här billigare än det manuella sättet? | Arbetsflödet för en kundtyp, mätt | Självbetjäning vid onboarding, rapporter |
| Kommer användarna tillbaka utan att bli tillfrågade? | Kärnloopen och grundläggande notiser | Allt annat |
| Kan det här fungera för en stor kund? | Grundläggande säkerhet, en integration de behöver, en pilot | Skala, polering, marknadssajt |
Innehåller er mening ordet och har ni två versioner. Bygg den första.
Kostnad för bygge, drift och vidareutveckling
Bygget är den synliga kostnaden och den varje offert täcker. De två som följer är mindre per månad och större över året, och det är de en första budget oftast utelämnar.
Bygge
Planering och arkitektur, sedan utveckling och driftsättning av version ett. En fastprisplan som vår MVP-planering följd av MVP-utveckling gör den här raden förutsägbar. Beloppen finns på prissidan.
Drift
Hosting, databas, e-postutskick, felspårning, domän, betalda API:er, plus verktygen teamet använder. Litet i början, men månatligt och för alltid, och det växer med användarna.
Vidareutveckling
Ändringar efter lansering: rättningar, funktionen användarna faktiskt behövde, borttagning av den de inte behövde. Budgetera ett månatligt belopp utvecklartid från lansering, inte från när problemen dyker upp.
Allt runtomkring
En landningssida, juridiska texter, uppsättning av betalleverantör, bokföring för prenumerationer och tiden grundarna lägger på försäljning. Inte mjukvara, men del av samma budget.
Spara pengar till version två
Version ett kommer att vara fel på ett sätt ni inte kan förutse, eftersom poängen med att bygga den är att ta reda på det. Budgeten behöver därför en uttrycklig reserv för version två, ungefär lika stor som raden för vidareutveckling under de första månaderna, orörd tills lanseringen gett underlag. Grundare som lägger den reserven på extra funktioner före lansering har köpt säkerhet om fel saker.
- Skriv in reserven för version två i budgeten som en rad med ett datum från vilket den får användas.
- Bestäm i förväg vilket underlag som låser upp den: betalande kunder, återkommande användning, en signerad pilot.
- Kommer underlaget inte finansierar reserven en omställning eller ett ordnat stopp, och båda är bättre än en större version av fel produkt.
- Välj ett byggsätt som gör version två billig: en tenancy-modell och en datastruktur som överlever tillväxt, vilket är vad vår guide till multi-tenant-arkitektur handlar om.
Tecken på att du lägger för mycket
Budgeten har glidit när funktionslistan växer efter att frågan sattes, när bygget är planerat att ta längre tid än ni kan vänta innan ni säljer, när offerten innehåller ett adminsystem, en mobilapp och en marknadssajt för en produkt som ännu inte använts av en främling, när driftkostnaderna aldrig uppskattades, eller när grundarna inte kan säga vilket underlag som skulle få dem att sluta. Vart och ett går att rätta genom att gå tillbaka till enmeningsfrågan och skära tills omfattningen ryms i en tredjedel av kassan.
När ni inte behöver något eget bygge alls: kan frågan besvaras med ett kalkylark, ett no-code-verktyg, en landningssida och en manuell process bakom, gör det först och lägg inget på mjukvara förrän den manuella versionen knakar. Det säger vi till grundare på samtal och menar det. Vår översikt över SaaS och MVP beskriver när ett riktigt bygge blir rätt steg. Har ni enmeningsfrågan och en siffra på kassan, boka ett kostnadsfritt 15-minuterssamtal så dimensionerar vi version ett mot den tillsammans.
Vanliga frågor
Finns det en typisk budget för ett första bygge i en svensk startup?
Ingen användbar. Det beror helt på frågan produkten måste besvara och kassan som finns. En MVP-plan och ett bygge till fast pris ger en känd siffra att pröva mot kassan, vilket är mer användbart än ett branschsnitt.
Ska vi anställa en utvecklare i stället för att köpa ett bygge?
En anställning är rimlig när produkten är företaget och det finns mer än ett års arbete framför er. För en första version som måste bevisa något inom månader är ett fastprisbygge med tydlig omfattning oftast billigare och snabbare, och lämnar anställningsbeslutet till efter underlaget.
Hur uppskattar vi driftkostnaderna före lansering?
Lista varje tjänst produkten är beroende av och dess prisnivå vid lanseringsvolym: hosting, databas, e-post, felspårning, betalda API:er, domäner och teamverktyg. Lägg till marginal för tillväxt. Det är oftast en måttlig månadssiffra i början, men den är permanent.
Vad gör vi om investerare förväntar sig en större produkt?
Investerare finansierar underlag, inte antal funktioner. En liten version som visar betalande kunder eller återkommande användning tar in pengar lättare än en stor som inte visar något. Förklara frågan version ett besvarar och hur reserven finansierar version två.
Har ni en siffra på kassan och en produktidé?
Ta med båda, plus den enda mening version ett måste bevisa. På femton minuter dimensionerar vi första bygget mot er kassa och säger vad som ska bort.
Boka ett kostnadsfritt 15-minuterssamtal