Färdig produkt eller skräddarsydd programvara: när du ska välja vad

Du köper ett CRM för att säljchefen inte längre hänger med i anteckningarna, och efter tre månader står det bredvid systemet ett Excel med tre prislistor och en mapp med fakturor som någon kopierar över till bokföringen. Produkten är inte sämre än det den såldes som, för den känner kunden, affären och nästa samtal, men den känner inte din process, för den processen var inte det tillverkaren byggde för hundratals företag, och det glappet är hela den här artikelns ämne: huruvida du köper ett verktyg till din process eller en process till ditt verktyg — inte ett hål i funktionslistan som går att täppa till med en enda anpassning. Om hålet är en koppling mellan system som redan gör sitt jobb är det inget argument för ett bygge: först kopplar vi ihop det som redan finns.

Färdig produkt eller skräddarsydd programvara: när du ska välja vad, är inte en fråga om vilken knapp som ser modernare ut, och inte heller en fråga om du ”är tillräckligt stor för att bygga själv”. Vårt svar är detsamma som vi har skrivit på tjänstesidan: ryms din process i ett färdigt verktyg, ta det färdiga verktyget, det blir billigare, och ett skräddarsytt system är motiverat när processen är en del av din konkurrenskraft eller färdiga lösningar kräver för många kompromisser, och den meningen är inget säljtrick för att sedan ändå sälja ett bygge, utan testet där vi förlorar rader där vi skulle skriva ännu ett CRM och behåller dem där processen är en del av konkurrenskraften eller färdiga verktyg kräver för många kompromisser.

Den här artikeln är inte en jämförelse av e-handelsplattformar, för den har vi redan skrivit någon annanstans, och den är inte heller en prislista för skräddarsydd programvara, för en sådan artikel har vi inte och kommer inte att ha, eftersom vi inte tar priser ur luften, och den är inte heller ett löfte om att det egna systemet alltid vinner. Vi säljer både införandet av en färdig produkt och bygget från grunden, och en ärlig text börjar med att det dyraste vi ibland kan sälja dig är det du inte behöver, därför kommer härnäst gränsen efter vilken det här valet kan göras, innan någon säljer dig en sprint.

Färdig produkt eller skräddarsydd programvara: när du ska välja vad

Ta den färdiga produkten om processen ryms i den, och beställ programvara om processen är din konkurrenskraft eller färdiga verktyg kräver för många kompromisser: det är hela svaret, och resten av den här artikeln är hur den meningen prövas mot ett konkret arbete, inte mot en presentation. En jämförelse som börjar med en funktionstabell tar slut innan den har börjat, för tabellen visar det tillverkaren har namngett, inte den som om ett år ska besluta om din nästa ändring.

Följderna av fel sida är inte symmetriska, för det färdiga verktyget där du har pressat in din process med våld blir ett abonnemang plus Excel plus en människa som håller ihop de två, och den människan är efter ett år dyrare än vilken licens som helst, men ett skräddarsytt system för en process som redan lever i bokföringen, e-postprogrammet och ett vanligt CRM är ett bygge som du får förvalta själv, trots att någon annan redan förvaltar det på marknaden. I det första fallet har du köpt en produkt och sedan skrivit ett andra system bredvid den, i det andra har du skrivit ett system där en licens hade räckt, och båda felen kostar längre än de ser ut i offerten.

Vi namnger den här gränsen för att vi har sett båda ändarna samma vecka: ett företag som ville ha ”ett eget HubSpot” trots att det behövde HubSpot, och ett företag som i tre år böjde ett färdigt ERP kring sin pristabell och till slut kom med samma tabell som ett nytt projekt, inte för att ”ERP kan inte”, utan för att kompromisserna redan var fler än konfigurationen. Inget av de tillstånden är resultatet av dålig vilja, för båda börjar med meningen ”vi behöver ett system”, som ännu inte är ett test, och testet börjar först när du skriver ner processen på en sida utan verktygets namn och sedan letar efter vilket verktyg som redan gör den sidan.

Innan du upphandlar skriver du vad systemet ska göra den första dagen, vad det inte får glömma det andra året, och vem som får ändra det andra året utan någon annans utgåva, för ryms svaren i en produkt som går att konfigurera, ta produkten. Är frågan katalog, priser, order och leverans i en webbutik är det butikstestet, och det skriver vi inte om; är svaren en process som konkurrenten inte får köpa som ett färdigt verktyg, då först är det meningsfullt att tala om en sprint. Den här artikeln säljer sedan den ordningen, inte ett verktyg.

Vad en färdig produkt är och vad skräddarsydd programvara är

En färdig produkt är programvara som någon redan har skrivit för många och som du köper eller abonnerar på för att använda utan väsentlig ombyggnad. Kammarkollegiets ramavtal Programvaror och tjänster skiljer licenser och publika molntjänster (programvara som tjänst) från systemutveckling av kundanpassad programvara. COTS tar vi här som färdig kommersiell programvara utan väsentlig anpassning, SaaS som en applikation på internet som man abonnerar på. Det är definitioner för planering, inte en skyldighet för ett privat företag, och vi tar dem här som ord som redan är namngivna, inte som en lag som lägger ett myndighetsgodkännande på dig.

Skräddarsydd programvara är ett system som skrivs för din process, och i samma riktlinjer är specialiserad programvara individuellt utvecklad programvara för en viss myndighets eller branschs behov. Vi kallar det också för ett skräddarsytt system, på tjänstesidan för ett mer ovanligt system och i rubriken för skräddarsydd programvara, och det är inte tre produkter utan ett arbete: kod som börjar i din process, inte i tillverkarens antagande om vad en kund, en order eller en faktura är, därför är skillnaden inte ”bättre” mot ”sämre”, utan vem som sedan får ändra det antagandet.

Den färdiga produkten är inte ett misslyckat skräddarsytt bygge, och det skräddarsydda bygget är inte ett bättre CRM, för WooCommerce är en färdig e-handelsprodukt, Moodle är en färdig lärplattform, WordPress är en färdig innehållsplattform, och vi säljer alla tre som införande, inte som ett dolt bygge under ett annat namn. Laravel är ingen produkt i den meningen: det är ett ramverk som vi skriver skräddarsydda system på sedan version 4.0 år 2013, och det ger varken katalog, varukorg eller CRM förrän någon har skrivit dem, därför betyder att blanda ihop ramverk med produkt att inbilla sig att ”på Laravel” redan är ett svar, trots att det bara är ett sätt att skriva svaret.

Det tredje som vanligen blandas ihop här är abonnemang mot ägande, för SaaS betyder att du betalar för användningen och att leverantören håller data, en evig licens betyder att du har betalat för rätten att använda en version och att uppdateringar ofta är en separat rad, men skräddarsydd kod som vi överlämnar betyder att källkoden, dokumentationen och konfigurationen av infrastrukturen är din. Ingen av de raderna vinner automatiskt, det finns bara klarhet i vad du köper, för annars bråkar du efter ett år om huruvida ”systemet är vårt” när det i själva verket är ett abonnemang som kan sägas upp.

Testet vi använder för det här valet

Testet är inte ”om vi gillar den här skärmen”, utan om processen som du inte får lämna till en konkurrent ryms i ett verktyg som konkurrenten kan köpa i samma butik: ryms den är verktyget det rätta svaret, för det blir billigare och det förvaltas av någon vars enda arbete är just det verktyget, men ryms den inte, för att pristabellen, ordergodkännandet eller leveransvillkoren är det du skiljer dig med, då blir den färdiga produkten en kompromiss, och kompromiss här betyder att processen börjar leva i Excel bredvid systemet.

Den andra sidan av samma test glöms för ofta bort, för behoven är oftare gemensamma än unika, och ett e-postprogram bygger man inte, en bokföring som redan gör det lagen kräver bygger man inte, och en vanlig säljtratt där en affär är en affär bygger man inte heller. Myndigheter som spenderar sina pengar efter skriftliga kriterier har namngett samma form på ett annat sätt: först frågar man om saken redan finns på marknaden, och man bygger när de tillgängliga produkterna inte täcker kärnan eller när saken behöver styras av en själv, och det är inte en skyldighet för ett privatföretag, och vi gör det inte till en sådan, men det är samma form som vi använder när vi säger nej till ett bygge som går att köpa.

Det tredje felet är att bygga om produkten tills den inte längre är en produkt, för konfigurationen håller sig inom de ramar som stöds (fält, roller, flöden som tillverkaren har förutsett), men en anpassning som skriver om kärnan så att processen ”äntligen passar” gör slut på just den fördel man köpte produkten för: uppdateringarna, dokumentationen, att felet hittas av någon annan. Vi har sett det i Moodle-införanden, där vi först kontrollerar om tillägget redan finns och först därefter skriver ett eget, och på WordPress-webbplatser, där vi inte lägger in ett färdigt tema, för det tar med sig dussintals funktioner som du inte behöver och som blir en säkerhetsrisk, därför är en produkt med en främmande kärna inte ett skräddarsytt system, utan en produkt där du har tagit bort tillverkarens kärna.

Vi gör det här testet i en förstudieworkshop, inte i en offertpresentation, för i presentationen vinner alltid bygget som ser ut som omsorg om dig, men i workshopen vinner processen som går att namnge. Om det efter två dagar visar sig att processen ryms i ett färdigt verktyg säger vi det, också när det betyder att den här veckans affär inte är vårt mer ovanliga system, för en artikel som alltid slutar med ”vi bygger ett eget åt dig” är inte ett test, utan en offert som gömmer sig bakom en fråga.

När den färdiga produkten är det rätta svaret

Den färdiga produkten är det rätta svaret där processen redan är namngiven i branschen och du inte är den som uppfann namnet, för e-post, bokföring som skriver ut en faktura så som lagen kräver, ett vanligt CRM för sälj, en lärplattform som registrerar kurs och genomförande, och en liten butik med ett pris och ett lager är ställen där ett bygge inte ger något som är värt mellanskillnaden mellan en licens och en sprint. De här raderna säljer vi inte som ”en tillfällig lösning tills du är redo för det riktiga systemet”, för de är de riktiga systemen för de här processerna.

Vi säljer de här produkterna också, och det är inget dolt löfte om att ett bygge kommer om ett år: WordPress förblir en innehållsplattform med ett tema som vi skriver, inte med ett färdigt tema från butiken; för en liten butik med standardprocesser säger vi själva WooCommerce; Moodle förblir en lärplattform som vi konfigurerar, migrerar och formger, inte hittar på från början. Priserna för de här raderna står på tjänstesidorna och på ett ställe längre ned i den här artikeln, där det behövs för att visa att startpriset för skräddarsytt inte automatiskt är den dyraste raden, och här räcker det att säga att produkten förblir en produkt.

Följden av att du ändå beställer ett bygge här är inte ”bättre kontroll”, utan en förvaltning som du inte längre delar med tusentals andra, för säkerhetsrättningen till ett e-postprogram släpper någon till alla, men rättningen till ditt eget e-postprogram släpper du, och det låter som frihet tills den andra natten då du måste laga det tillverkaren redan har lagat i sin produkt. Den friheten säljer vi där processen förtjänar den, inte där en licens räcker, för annars säljer vi dig ett arbete som du om ett år kommer att hata som en dyr dubblett.

Därför är det ärligaste vi kan säga före varje offert på ett mer ovanligt system en lista över produkter som vi skulle föreslå i stället: är processen utbildning, börja med Moodle, är processen innehåll, börja med WordPress, är processen en liten butik, börja med WooCommerce, och är processen fakturor och den lagstadgade redovisningen, börja med den bokföring du redan har, och fråga först därefter om något av det behöver bli ett eget system. Listan är inget partneravtal, den är ett test som vi använder mot oss själva.

När skräddarsydd programvara är motiverad

Skräddarsydd programvara är motiverad när processen är en del av din konkurrenskraft eller färdiga lösningar kräver för många kompromisser, och processen kan förbli ett stöd till varan och ändå vara en del av det här testet, för testet är antalet kompromisser, inte om du säljer programvara. Om den färdiga produkten börjar kräva att du blir genomsnittskunden, och genomsnittskunden inte är din konkurrenskraft, har bygget äntligen blivit ett test som processen har klarat, inte en önskan om en egen skärm.

Integration är här inget argument i sig, för produkterna har också gränssnitt, och vi kopplar in dem, och argumentet börjar först när gränssnittet inte räcker och processen kräver att sanningen om saldo, pris eller status bor på ett ställe som du styr. Kartportalen för Sadales tīkls, som vi har byggt på Laravel och Leaflet, visar avbrott, ledig kapacitet och anslutningsavgift, och det är inte ”en karta plus ett tillägg”, för avgiften och kapaciteten är operatörens process, inte ett fält i en kartprodukt; i Elektrum-portalen kopplas en SSO-session på varje anrop innan Vue-konfiguratorn ritar, och det är inte ”ett energitema i WordPress”, för sessionen är en del av tjänsten, inte dekoration.

Färg, logotyp och menyns ordning är inte det här testet, för de går att göra i produkten, och vi gör dem i produkten: ett Moodle-tema med din palett, ett WordPress-tema utan det överflödiga, en WooCommerce-butik som ser ut som du. Om det enda som inte går att göra i det färdiga verktyget är ”så att det ser ut som vi”, har du inte nått fram till skräddarsydd programvara, utan till ett tema, och att blanda ihop de två sakerna betyder att betala för ett bygge där design räcker, och sedan undra varför förvaltningen är dyr för ett system vars enda skillnad är färgen.

Vi säger inte heller att varje bransch automatiskt kräver en egen plattform, för branschens namn är inte ett test, och testet är om den här branschens process i ditt företag är detsamma som tillverkaren redan har lagt i paketet, eller om det är ditt sätt för branschen att arbeta, och det sättet inte får köpas bredvid. Går det att köpa, köp; går det inte, då handlar det om ett skräddarsytt affärssystem, och först då är det värt att tala om en förstudieworkshop, inte om ett tema.

Den tredje vägen: en produkt med vår kod ovanpå

Mellan den färdiga produkten och bygget från grunden finns en tredje väg, som vi också säljer och som jämförelser oftast hoppar över: produkten förblir en produkt, och ovanpå skriver vi det produkten inte gör, och det är inte ”lite skräddarsydd programvara”, utan ett beslut att lämna kärnan där tillverkaren förvaltar den och bara skriva det skikt som är ditt. Sadales tīkls tjänsteportal står på October CMS, och kalkylatorer, kalendrar och felanmälan är arbete på produkten, inte en ny innehållsmotor; i ett Moodle-införande kontrollerar vi först om tillägget för bedömning eller rapport redan finns, och först därefter skriver vi ett eget, för annars säljer vi dig en dubblett.

Är frågan katalog, priser, order och leverans är det butikstestet, och det är redan skrivet i artikeln om valet mellan WooCommerce och Laravel, därför skriver vi inte om det här och gör det inte till standardvalet för ett mer ovanligt system. Är frågan ett CRM, ett ERP, en intern panel eller en branschprocess, stanna här, för butiken är ett fall av samma test, inte hela valet.

På WordPress-sidan ser den tredje vägen ut som ett avslag, för färdiga teman lägger vi inte in, de tar med sig funktioner som blir en säkerhetsrisk, och vi bygger ett rent tema med bara det som behövs, och det är fortfarande en produkt: redaktören skriver i WordPress, inte i en redigerare vi har hittat på, och uppdateringarna kommer från WordPress, inte från en enda utgåva från oss. Skillnaden mellan det och ett skräddarsytt system är att innehållsprocessen ryms i produkten, men temaprocessen ryms inte i ett ThemeForest-tema, och att blanda ihop dem betyder antingen att lägga in ett främmande tema och sedan undra över tilläggen, eller att bygga ett eget CMS för ett innehåll som redan har ett CMS.

Den här gränsen är också stället där vi säger nej till ”en liten ombyggnad” som efter den tredje månaden är kärnan, för blir anpassningarna fler än konfigurationen, kräver varje uppdatering vår kod först, är tillverkarens fält inte längre sanningen, då är du inte längre på den tredje vägen. Du är på ett bygge som gömmer sig bakom produktens namn, och då är det ärligare att namnge bygget och räkna det som ett bygge, för annars betalar du för en produkt som inte längre går att uppdatera, och för ett system som ännu inte går att ta över.

Pengar och tid är en form, inte en prislista

Ett skräddarsytt system hos oss kostar från 8 000 €, och en full cykel tar vanligtvis från 12 till 32 veckor, och det är ett startpris, inte en räkning, och 12 veckor är inte samma sak som de första tre månaderna där vi lovar ett användbart MVP: starttiden är det kortaste bygget, MVP är steget efter vilket systemet redan används, och 32 veckor är den övre gränsen för ett större arbete, som också ryms i det vi i den allmänna FAQ:n kallar sex till åtta månader för ett stort skräddarsytt system. Laravel-sidan börjar från samma 8 000 € och 6–24 veckor, och det är inte billigare skräddarsydd programvara: det är en sida för den som redan vet att arbetet är Laravel, inte testet om arbetet över huvud taget är ett bygge.

De här talen får inte bli meningen ”skräddarsydd programvara är det dyraste valet”, för ett Moodle-införande börjar från 15 000 €, butikens Pro-version kostar 9 500 €, och båda ligger över startpriset för skräddarsytt, för det ena är införandet av en stor produkt, det andra är en butik med lager och B2B-priser. Att jämföra startpriset på 8 000 € med Moodle-startpriset som ”bygge mot produkt” är fel aritmetik, för jämföra kan man bara två vägar för samma process, och även då är båda sidor startpriser, inte slutsummor; för större, mer ovanliga arbeten räknar vi på löpande räkning med ett veckotak, för ett fast pris där betyder vanligtvis ett risktillägg eller en tvist om omfattningen, och timtaxan är 50 €.

Abonnemang mot bygge är inte heller en formel där den ena sidan efter N år automatiskt vinner, och den statliga kostnadsplaneringen namnger det vi också ser i privata avtal: SaaS-avgiften kan stiga med antalet användare eller med indexering, integrationerna förblir din kostnad, och ett leverantörsbyte kräver en utgångsplan, för data står hos dem. Det är inte en procentsats av bygget som vi skulle citera här, för fotnoten bakom sådana tal leder till leverantörsbloggar, och sådana tal skriver vi inte, men formen blir kvar: abonnemanget är en rad varje år, bygget är ett startpris plus förvaltning, och ingen av dem är utan rad.

Dataförordningen, som är tillämplig i unionen från och med den 12 september 2025, hjälper till att föra ut exporterbara data från en molntjänst och förbjuder leverantören att lägga hinder i vägen för ett byte, men funktionell likvärdighet kräver den bara av en infrastrukturtjänst (IaaS), inte av ett CRM som du bara ”flyttar”, och förordning 2023/2854 lovar inte att processen följer med filen. Artikel 20 i dataskyddsförordningen flyttar personuppgifter som den registrerade har tillhandahållit, inte applikationen, inte din konfiguration, inte affärsreglerna, därför, om du vill ha ett system som går att flytta till en annan utvecklare, är det källkoden som vi överlämnar, inte en export från någon annans panel, och det är också här det här avsnittet slutar, för nästa mening skulle redan vara en prislista som vi inte har för den här frågan.

Vad vi inte säger när vi talar om skräddarsydd programvara

Vi säger inte att det egna systemet alltid är klokare, att den färdiga produkten är för dem som ”ännu inte har vuxit ur den”, eller att bygget efter tre år säkert har betalat sig, för en sådan kurva utan din process är ett påhitt. En artikel som efter en ärlig start ändå landar i att man ska köpa ett bygge har gått för långt, och det har vi sett tillräckligt ofta för att stanna här, för ärlighet är en begränsning och ett kort test är målet.

Vi säger inte heller att Laravel är svaret på frågan om den färdiga produkten, för Laravel är sättet vi skriver på när testet redan har gett ett bygge, och att sälja ett ramverk till den som behöver Moodle är att sälja en hammare till den som behöver en hylla. Vår Laravel-sida börjar från 8 000 € och talar om API:er, köer och tester, men den här artikeln talar om huruvida du över huvud taget behöver den sidan, och att blanda ihop dem betyder att du väljer verktyget innan du har valt arbetet.

Vi säger inte heller att förstudieworkshopen är ett dolt sätt att leda in dig i ett bygge, för workshopens resultat är en plan som förblir användbar också om du beslutar att inte anlita oss, och ibland säger planen: ta produkten du redan har namngett, så inför vi den, eller så inför någon annan den. Om den meningen låter som en förlorad affär för dig, så är det för att den är en förlorad affär, och vi förlorar hellre ett bygge där vi skulle skriva ännu ett CRM än vinner en kund som efter ett år frågar varför hen förvaltar ett system som gick att abonnera på.

För en offentlig upphandling fungerar det här testet inte likadant som för ett privat företag, och det går inte att flytta över utan anpassning, för i den statliga planeringen skiljer ramavtalet Programvaror och tjänster licenser från kundanpassad programvara, och det hör till upphandlingen, inte till den här meningen, men på den privata sidan hör din process och vår prislista till saken. Båda sidorna kan komma fram till samma svar, och de kommer inte dit för att den ena skulle vara den andras lag.

Hur det här beslutet fattas hos oss

Arbetet börjar med en förstudieworkshop på två till tre dagar där vi tillsammans med ditt team går igenom processer, användarroller, risker och MVP:ns omfattning, och det är ingen morgon med bildspel, utan ett arbete efter vilket vi kan säga om processen ryms i ett färdigt verktyg, om den kräver den tredje vägen, eller om den är ett bygge. Är svaret en produkt har workshopen betalat sig med den meningen; är svaret ett bygge är nästa steg inte kod.

Innan produktionskod tar vi på två till tre veckor fram en klickbar prototyp, för där är det billigare att ändra sig än i ett färdigt system, och prototypen är inte ”för att ha något att visa styrelsen”, utan stället där du ser att pristabellen du namngav i går i själva verket är en annan tabell, och där den insikten kostar dagar, inte månader. Först därefter börjar utvecklingen: under de första tre månaderna bygger vi ett MVP som går att använda på riktigt, och sedan bygger vi ut det stegvis, i tvåveckorssprintar med demo efter varje.

Till slut får du källkoden, dokumentationen och konfigurationen av infrastrukturen och kan flytta dem till en annan utvecklare, och det är inget löfte om att flytten blir trevlig, men ett löfte om att du inte är bunden till vårt konto. I större projekt stannar vi vid löpande räkning med ett veckotak, och MVP-gränsen drar vi ändå, för annars blir ”agile” ett ord bakom vilket omfattningen försvinner, och går du en annan väg efter workshopen blir planen kvar hos dig, som vi har skrivit på tjänstesidan, och den här artikeln ändrar inte på det.

Innan du skriver till oss skriver du processen på en sida utan verktygets namn och markerar vilka rader du inte får lämna till någon annans utgåva: är sidan tom eller står det bara ”för att ha ett eget system”, behöver du en produkt, och det säger vi också, men finns det på sidan en process som konkurrenten inte kan köpa som ett färdigt verktyg, då är det värt att tala om ett bygge. Skriv till oss om du vill att vi läser den sidan tillsammans med dig och säger vilken sida som är din, också när svaret är att ta produkten du redan har namngett.