Vi skulle aldrig göra om samma misstag
Det är kanske inte den mest inspirerande inledningen på en berättelse om att starta eget, men det var ungefär så det gick till.
Vi hade arbetat med ett affärssystem och en e-handelslösning under flera år. Vi kände produkten, kunderna och framför allt alla de kompromisser som hade gjorts längs vägen.
Och kompromisserna var många.
Ett system, väldigt många versioner
Grundidén hade en gång varit ganska enkel: en produkt som kunde säljas till flera kunder.
Problemet var att kunder sällan vill ha exakt samma sak.
En kund behövde en särskild funktion. En annan ville ha ett annorlunda arbetsflöde. En tredje hade krav som inte riktigt gick att förena med vad de två första hade fått.
Lösningen blev ofta att göra en separat anpassning.
Sedan ytterligare en.
Och en till.
Till slut hade vi något som visserligen fortfarande kallades en produkt, men som i praktiken bestod av en växande samling kundspecifika varianter och kodgrenar.
Att rätta en bugg innebar inte längre nödvändigtvis att rätta en bugg. Det kunde innebära att rätta samma bugg på flera ställen, kontrollera vilka kunder som hade vilken version och försöka avgöra om en ändring överhuvudtaget gick att återanvända.
Vi visste hur vi hade hamnat där.
Vi visste också att vi aldrig ville hamna där igen.
När allt annat också gick sönder
Sedan började problemen som inte hade särskilt mycket med programmering att göra.
Företagets ekonomi hade misskötts. Så småningom stod vi utan kontor efter att hyran inte hade betalats på nio månader.
Mitt i allt detta försvann även våra källkodsarkiv.
Vi hade inga egna säkerhetskopior att falla tillbaka på. Det var en minst sagt obehaglig situation för ett företag vars verksamhet byggde på att kunna vidareutveckla och underhålla sin programvara.
Räddningen kom från ett oväntat håll.
En eller två utvecklare hos ett outsourcingföretag hade kvar relativt färska kopior av källkoden och såg till att vi fick dem.
Det var ingen elegant återställning. Vi fick pussla ihop det vi hade och arbeta vidare från den senaste version vi kunde få tag på.
Men det gick.
Företaget var ändå på väg mot sitt slut. Vi hade blivit uppsagda och arbetade av vår återstående tid, medan framtiden såg allt annat än säker ut.
Lunchdiskussionerna
Det var under den perioden som vi började prata.
Inte i något konferensrum med en affärsplan på väggen. Inte på ett strategimöte med presentationer och tillväxtprognoser.
Utan över lunch.
Vi var tre kollegor som hade arbetat med samma typ av system och som hade ganska bestämda uppfattningar om vad vi skulle göra annorlunda om vi fick börja om.
Vi kände till de tekniska begränsningarna. Vi visste vilka delar som hade blivit onödigt komplicerade och vilka kundanpassningar som hade skapat mest problem.
Och framför allt visste vi vad vi inte ville bygga igen.
Diskussionerna fortsatte. Till slut bestämde vi oss gemensamt för att lägga lite tid på att experimentera och se om vi kunde få fram något vettigt.
Vi skulle bygga en prototyp.
Se om idéerna höll.
Och om det fungerade kunde vi kanske göra något mer av det.
Det var ungefär så GearsERP började 2011.
Från noll, men inte utan erfarenhet
Vi skulle bygga en helt ny produkt.
Inte fortsätta utveckla den gamla. Inte ta över dess kodbas eller försöka städa upp bland alla kundspecifika grenar.
Vi började från noll.
Ingen kod återanvändes.
Däremot hade vi med oss åtskilliga års erfarenhet av vad som fungerade, vad som inte fungerade och vilka konstruktionsbeslut som hade orsakat oss mest huvudvärk.
En viktig del var integrationen mot Microsoft Dynamics NAV, eller Navision som många fortfarande kallade det.
Vi ville kunna erbjuda en liknande integration som tidigare, men betydligt mer strömlinjeformad och effektiv.
Och den här gången tänkte vi inte försöka stödja precis allting.
Vi koncentrerade oss på de Navision-versioner vi själva kände bäst. Kunder som fortfarande körde äldre versioner uppmuntrades att uppgradera, snarare än att vi skulle bygga och underhålla ytterligare speciallösningar för gammal teknik.
Det var ett medvetet val.
Vi hade redan upplevt vad som hände när man försökte tillgodose varje tänkbart behov.
Framför allt hade vi en princip som vi var ganska överens om.
En standardprodukt. En gemensam kodbas.
Självklart skulle det finnas möjlighet till variation och anpassningar. Det är svårt att sälja affärssystem utan att ta hänsyn till hur olika företag arbetar.
Men vi skulle inte skapa en ny version av hela produkten varje gång en kund hade en särskild önskan.
Vi hade redan provat det.
Det räckte.
Tre personer, ganska många hattar
Till en början var det en utmärkt idé.
Vi kunde fatta våra egna tekniska beslut, bygga på ett mer genomtänkt sätt och försöka undvika de problem som vi tidigare hade tvingats leva med.
Men att vara tre personer som driver ett produktföretag innebär också att man får göra betydligt mer än att utveckla produkten.
Det ska säljas, planeras, levereras, felsökas, supportas och faktureras. Ibland ungefär samtidigt.
Och kunder har fortfarande krav.
Ibland fullt rimliga sådana. Ibland krav som inte alls passar in i den standardprodukt man så omsorgsfullt försökt bygga.
Till en början försökte vi hålla fast vid vår ursprungliga tanke. Gemensamma lösningar där det gick, variation utan att dela upp produkten i separata kodbaser.
Men med tiden blev det svårare.
Vi behövde arbeta snabbt. Vi hade många roller att fylla och begränsat med tid. Och vissa kunders behov var faktiskt så pass annorlunda att de inte enkelt gick att förena med standardlösningen.
Till slut började resonemanget låta ungefär så här:
Okej. Vi kanske får göra en kundspecifik version i just det här fallet.
Det var förstås precis den sortens resonemang som vi en gång hade bestämt oss för att undvika.
Men det fanns en skillnad mellan att sitta över en lunch och diskutera hur man borde byg