Ferdig produkt eller skreddersydd programvare: når velge hva

Du kjøper et CRM fordi salgssjefen ikke lenger klarer seg med notater, og etter tre måneder står det et Excel ved siden av systemet med tre prislister og en mappe med fakturaer som noen kopierer over i regnskapet. Produktet er ikke dårligere enn det det ble solgt som, fordi det kjenner kunden, avtalen og neste samtale, men det kjenner ikke prosessen din, fordi denne prosessen ikke var det produsenten bygget for hundrevis av virksomheter, og dette gapet er hele temaet i denne artikkelen: om du kjøper et verktøy til prosessen din, eller en prosess til verktøyet ditt, og ikke et hull i funksjonslisten som kan fylles med én tilpasning. Hvis hullet er en kobling mellom systemer som allerede gjør jobben sin, er det ikke et argument for å bygge: først kobler vi det som allerede finnes.

Ferdig produkt eller skreddersydd programvare: når velge hva, er ikke et spørsmål om hvilken knapp som ser mer moderne ut, og det er heller ikke et spørsmål om du «er stor nok til å bygge selv». Svaret vårt er det samme som vi har skrevet på tjenestesiden: får prosessen din plass i et ferdig verktøy, ta det ferdige verktøyet, det blir billigere, og et skreddersydd system er berettiget når prosessen er en del av konkurransekraften din, eller når ferdige løsninger krever for mange kompromisser, og denne setningen er ikke et salgstriks for at vi likevel skal selge et bygg etterpå, men en test der vi taper linjer der vi skulle ha skrevet enda et CRM, og beholder dem der prosessen er en del av konkurransekraften eller de ferdige verktøyene krever for mange kompromisser.

Denne artikkelen er ikke en sammenligning av nettbutikkplattformer, fordi den har vi allerede skrevet et annet sted, og den er heller ikke en prisliste for skreddersydd programvare, fordi en slik artikkel har vi ikke og kommer ikke til å skrive, for vi tar ikke priser ut av løse luften, og den er heller ikke et løfte om at et eget system alltid vinner. Vi selger både innføring av et ferdig produkt og bygging fra bunnen av, og en ærlig tekst begynner med at det dyreste vi av og til kan selge deg, er det du ikke trenger, derfor kommer grensen nedenfor, slik at du kan gjøre dette valget før noen selger deg en sprint.

Ferdig produkt eller skreddersydd programvare: når velge hva

Ta det ferdige produktet hvis prosessen får plass i det, og bestill programvare hvis prosessen er konkurransekraften din eller de ferdige verktøyene krever for mange kompromisser: det er hele svaret, og resten av denne artikkelen er hvordan du prøver denne setningen mot et konkret arbeid, ikke mot en presentasjon. En sammenligning som starter med en funksjonstabell, er ferdig før den har begynt, fordi tabellen viser det produsenten har navngitt, ikke hvem som om et år skal bestemme din neste endring.

Følgene fra feil side er ikke symmetriske, fordi det ferdige verktøyet der du har presset prosessen din inn med makt, blir et abonnement pluss Excel pluss et menneske som holder de to sammen, og dette mennesket er etter et år dyrere enn hvilken som helst lisens, mens et skreddersydd system for en prosess som allerede lever i regnskapet, i e-postprogrammet og i et standard-CRM, er et bygg du selv skal vedlikeholde, selv om markedet allerede vedlikeholder det. I det første tilfellet har du kjøpt et produkt og deretter skrevet et annet system ved siden av det, i det andre har du skrevet et system der en lisens hadde holdt, og begge feilene koster lenger enn de ser ut i tilbudet.

Vi navngir denne grensen fordi vi har sett begge endene i samme uke: en virksomhet som ville ha «sitt eget HubSpot», selv om det den trengte var HubSpot, og en virksomhet som i tre år bøyde et ferdig ERP rundt pristabellen sin og til slutt kom med den samme tabellen som et nytt prosjekt, ikke fordi «ERP ikke kan», men fordi kompromissene allerede var flere enn konfigureringen. Ingen av disse tilstandene er et resultat av dårlig vilje, fordi begge starter med setningen «vi trenger et system», som ennå ikke er en test, og testen begynner først når du skriver prosessen på én side uten et verktøynavn og deretter leter etter hvilket verktøy som allerede gjør denne siden.

Før innkjøpet skriver du hva systemet skal gjøre den første dagen, hva det ikke får glemme det andre året, og hvem som får lov til å endre det andre året uten en fremmed utgivelse, fordi hvis svarene får plass i et produkt som kan konfigureres, tar du produktet. Hvis spørsmålet er katalog, priser, ordre og levering i en nettbutikk, er det butikktesten, og den skriver vi ikke om; hvis svarene er en prosess konkurrenten ikke får kjøpe som et ferdig verktøy, først da har det mening å snakke om en sprint. Denne artikkelen selger videre denne rekkefølgen, ikke et verktøy.

Hva som er et ferdig produkt, og hva som er skreddersydd programvare

Det ferdige produktet er programvare noen allerede har skrevet for mange, og som du kjøper eller abonnerer på for å bruke uten vesentlig ombygging. Digitaliseringsrundskrivet krever at virksomheten tar stilling til hva den skal utføre selv og hva som skal overlates til eksterne, og at skytjenester vurderes på linje med andre løsninger. COTS tar vi her som ferdig kommersiell programvare uten vesentlig tilpasning, SaaS som en applikasjon tilgjengelig på internett som abonnementstjeneste. Det er definisjoner for planlegging, ikke en plikt for en privat virksomhet, og vi tar dem her som ord som allerede er navngitt, ikke som en lov som pålegger deg en statlig godkjenning.

Skreddersydd programvare er et system som skrives for prosessen din, og i de samme retningslinjene er spesialisert programvare individuelt utviklet programvare for en bestemt etats eller bransjes behov. Vi kaller det også et skreddersydd system, på tjenestesiden et ikke-standard system, og i overskriften skreddersydd programvare, og det er ikke tre produkter, men ett arbeid: kode som starter fra prosessen din, ikke fra produsentens antakelse om hva en kunde, en ordre eller en faktura er, derfor er forskjellen ikke «bedre» mot «dårligere», men hvem som etterpå får lov til å endre denne antakelsen.

Det ferdige produktet er ikke et mislykket skreddersydd bygg, og et skreddersydd bygg er ikke et bedre CRM, fordi WooCommerce er et ferdig e-handelsprodukt, Moodle er en ferdig læringsplattform, WordPress er en ferdig innholdsplattform, og alle tre selger vi som innføring, ikke som et skjult bygg under et annet navn. Laravel er ikke et produkt i denne betydningen: det er et rammeverk vi skriver skreddersydde systemer på siden versjon 4.0 i 2013, og det gir verken katalog, handlekurv eller CRM før noen har skrevet dem, derfor betyr det å blande rammeverk med produkt å innbille seg at «på Laravel» allerede er et svar, selv om det bare er en måte å skrive svaret på.

Den tredje tingen folk vanligvis blander her, er abonnement mot eierskap, fordi SaaS betyr at du betaler for bruken og leverandøren holder dataene, en evigvarende lisens betyr at du har betalt for retten til å bruke en versjon og at oppdateringer ofte er en egen linje, mens skreddersydd kode vi overleverer betyr at kildekoden, dokumentasjonen og infrastrukturoppsettet er dine. Ingen av disse linjene vinner automatisk, det finnes bare klarhet om hva du kjøper, fordi du ellers om et år krangler om «systemet er vårt» når det i virkeligheten er et abonnement som kan sies opp.

Testen vi bruker når vi gjør dette valget

Testen er ikke «om vi liker denne skjermen», men om prosessen du ikke får gi fra deg til en konkurrent, får plass i et verktøy konkurrenten kan kjøpe i den samme butikken: hvis den gjør det, er verktøyet det riktige svaret, fordi det blir billigere og vedlikeholdes av noen hvis eneste jobb er dette verktøyet, men hvis den ikke gjør det, fordi pristabellen, ordrebekreftelsen eller leveringsvilkårene er det du skiller deg med, da blir det ferdige produktet et kompromiss, og kompromiss betyr her at prosessen begynner å leve i Excel ved siden av systemet.

Den andre siden av den samme testen blir altfor ofte glemt, fordi behov oftere er felles enn unike, og et e-postprogram bygger man ikke, et regnskap som allerede gjør det loven krever, bygger man ikke, og en vanlig salgsflyt der en avtale er en avtale, bygger man heller ikke. Etater som bruker pengene sine etter skriftlige kriterier, har navngitt den samme formen annerledes: først spør de om tingen allerede finnes i markedet, og de bygger når de tilgjengelige produktene ikke dekker kjernen, eller når de trenger å styre tingen selv, og det er ikke en plikt for en privat virksomhet, og vi gjør det ikke om til en, men det er den samme formen vi bruker når vi sier nei til et bygg som kan kjøpes.

Den tredje feilen er å bygge om produktet til det ikke lenger er et produkt, fordi konfigureringen holder seg innenfor de støttede rammene (felter, roller, flyter produsenten har sett for seg), mens en tilpasning som skriver om kjernen for at prosessen «endelig skal passe», bruker nettopp den fordelen produktet ble kjøpt for: oppdateringer, dokumentasjon, at feilen blir funnet av noen andre. Det har vi sett i Moodle-innføringer, der vi først sjekker om utvidelsen allerede finnes, og først deretter skriver vår egen, og på WordPress-nettsteder, der vi ikke legger inn et ferdig tema, fordi det drar med seg titalls funksjoner du ikke trenger og som blir en sikkerhetsrisiko, derfor er et produkt med en fremmed kjerne ikke et skreddersydd system, men et produkt der du har tatt ut produsentens kjerne.

Vi gjør denne testen i en kartleggingsworkshop, ikke på et lysbilde i tilbudet, for på lysbildet vinner alltid bygget som ser ut som omsorg for deg, mens workshopen gir seieren til prosessen som kan navngis. Hvis det etter to dager viser seg at prosessen får plass i et ferdig verktøy, sier vi det, også når det betyr at ukens handel ikke er vårt ikke-standard system, fordi en artikkel som alltid ender med «vi bygger et eget til deg», ikke er en test, men et tilbud som gjemmer seg bak et spørsmål.

Når det ferdige produktet er det riktige svaret

Det ferdige produktet er det riktige svaret der prosessen allerede er navngitt i bransjen og du ikke er den som oppfant navnet, fordi e-post, et regnskap som skriver ut fakturaen slik loven krever, et standard salgs-CRM, en læringsplattform som registrerer kurs og gjennomføring, og en liten butikk med én pris og ett lager er steder der et bygg ikke gir noe det er verdt å betale differansen mellom lisens og sprint for. Disse linjene selger vi ikke som «en midlertidig løsning til du er klar for det ekte systemet», fordi de er de ekte systemene for disse prosessene.

Disse produktene selger vi også, og det er ikke et skjult løfte om at et bygg kommer om et år: WordPress blir stående som innholdsplattform med et tema vi skriver, ikke med et ferdig tema fra butikken; til en liten butikk med standardprosesser sier vi selv WooCommerce; Moodle blir stående som læringsplattform vi konfigurerer, migrerer og gir et tema, ikke finner opp på nytt. Prisene for disse linjene står på tjenestesidene og ett sted lenger nede i denne artikkelen, der vi trenger å vise at startprisen for skreddersøm ikke automatisk er den dyreste linjen, og her holder det å si at produktet blir produkt.

Følgen hvis du likevel bestiller et bygg her, er ikke «bedre kontroll», men vedlikehold du ikke lenger deler med tusenvis av andre, fordi sikkerhetsrettingen til e-postprogrammet slippes av noen til alle, mens rettingen til ditt eget e-postprogram slipper du, og det høres ut som frihet inntil den andre natten der du må rette det produsenten allerede har rettet i produktet sitt. Denne friheten selger vi der prosessen fortjener den, ikke der en lisens holder, fordi vi ellers selger deg et arbeid du om et år kommer til å hate som en dyr kopi.

Derfor er det ærligste vi kan si før ethvert ikke-standard tilbud, en liste over produkter vi ville anbefalt i stedet: hvis prosessen er opplæring, start med Moodle, hvis prosessen er innhold, start med WordPress, hvis prosessen er en liten butikk, start med WooCommerce, og hvis prosessen er fakturaer og lovpålagt regnskap, start med regnskapet du allerede har, og først da spør om noe av dette må bli et eget system. Denne listen er ikke en partneravtale, den er en test vi bruker mot oss selv.

Når skreddersydd programvare er berettiget

Skreddersydd programvare er berettiget når prosessen er en del av konkurransekraften din, eller når ferdige løsninger krever for mange kompromisser, og prosessen kan bli stående som støtte til varen og likevel være en del av denne testen, fordi testen er antallet kompromisser, ikke om du selger programvare. Hvis det ferdige produktet begynner å kreve at du blir gjennomsnittskunden, og gjennomsnittskunden ikke er konkurransekraften din, er bygget endelig en test prosessen har bestått, ikke et ønske om en egen skjerm.

Integrasjon er her ikke et argument i seg selv, fordi produktene også har grensesnitt, og vi kobler dem på, og argumentet begynner først når grensesnittet ikke strekker til og prosessen krever at sannheten om beholdning, pris eller status lever på ett sted du styrer. Kartportalen til Sadales tīkls, som vi har bygget på Laravel og Leaflet, viser strømbrudd, ledig kapasitet og tilknytningsavgift, og det er ikke «et kart pluss en utvidelse», fordi avgiften og kapasiteten er operatørens prosess, ikke et felt i et kartprodukt; i Elektrum-portalen henger SSO-økten på hver forespørsel før Vue-konfiguratoren tegner, og det er ikke «et energitema i WordPress», fordi økten er en del av tjenesten, ikke dekorasjon.

Farge, logo og menyrekkefølge er ikke denne testen, fordi de kan gjøres i produktet, og vi gjør dem i produktet: et Moodle-tema med paletten din, et WordPress-tema uten det overflødige, en WooCommerce-butikk som ser ut som deg. Hvis det eneste det ferdige verktøyet ikke klarer, er «at det ser ut som oss», har du ikke kommet fram til skreddersydd programvare, men til et tema, og å blande disse to tingene betyr å betale for et bygg der design holder, og deretter undre deg over at vedlikeholdet er dyrt for et system hvis eneste forskjell er fargen.

Vi sier heller ikke at hver bransje automatisk krever sin egen plattform, fordi bransjenavnet ikke er en test, og testen er om denne bransjens prosess i virksomheten din er den samme produsenten allerede har lagt i pakken, eller om det er din måte bransjen jobber på, og denne måten ikke får kjøpes ved siden av. Hvis den kan kjøpes, kjøp; hvis ikke, handler det om skreddersydde forretningssystemer, og først da er det verdt å snakke om en kartleggingsworkshop, ikke om et tema.

Den tredje veien: produktet med koden vår oppå

Mellom det ferdige produktet og et bygg fra bunnen av ligger en tredje vei, som vi også selger og som sammenligninger oftest hopper over: produktet forblir et produkt, og oppå skriver vi det produktet ikke gjør, og det er ikke «litt skreddersydd programvare», men en beslutning om å la kjernen bli der produsenten vedlikeholder den, og bare skrive laget som er ditt. Tjenesteportalen til Sadales tīkls står på October CMS, og kalkulatorer, kalendere og melding om feil er arbeid på produktet, ikke en ny innholdsmotor; i en Moodle-innføring sjekker vi først om en utvidelse for vurdering eller rapport allerede finnes, og først da skriver vi vår egen, fordi vi ellers selger deg en kopi.

Hvis spørsmålet er katalog, priser, ordre og levering, er det butikktesten, og den er allerede skrevet i artikkelen om valget mellom WooCommerce og Laravel, derfor skriver vi den ikke om her og gjør den ikke om til standardvalget for et ikke-standard system. Hvis spørsmålet handler om CRM, ERP, et internt panel eller en bransjeprosess, bli her, fordi butikken er ett tilfelle av den samme testen, ikke hele innholdet i valget.

På WordPress-siden ser den tredje veien ut som et avslag, fordi ferdige temaer legger vi ikke inn, de drar med seg funksjoner som blir en sikkerhetsrisiko, og vi bygger et rent tema med bare det som trengs, og det er likevel et produkt: redaktøren skriver i WordPress, ikke i en editor vi har funnet opp, og oppdateringene kommer fra WordPress, ikke fra vår utgivelse alene. Forskjellen mellom dette og et skreddersydd system er at innholdsprosessen får plass i produktet, mens temaprosessen ikke får plass i et ThemeForest-tema, og å blande dem betyr enten å legge inn et fremmed tema og deretter undre seg over utvidelsene, eller å bygge et eget CMS for innhold et CMS allerede finnes for.

Denne grensen er også stedet der vi sier nei til «en liten ombygging» som etter den tredje måneden er kjernen, fordi hvis tilpasningene blir flere enn konfigureringen, hvis hver oppdatering krever koden vår først, hvis produsentens felt ikke lenger er sannheten, er du ikke lenger på den tredje veien. Du er på et bygg som gjemmer seg bak et produktnavn, og da er det ærligere å navngi bygget og regne det som et bygg, fordi du ellers betaler for et produkt som ikke lenger kan oppdateres, og for et system som ennå ikke kan overtas.

Penger og tid er en form, ikke en prisliste

Et skreddersydd system hos oss starter fra 8 000 €, og en full syklus tar vanligvis fra 12 til 32 uker, og det er en startpris, ikke en faktura, og 12 uker er ikke de samme første tre månedene der vi lover et brukbart MVP: starttiden er det korteste bygget, MVP er steget etter hvilket systemet allerede brukes, og 32 uker er den øvre grensen for et større arbeid, som også får plass i det vi i den alminnelige FAQ-en kaller seks til åtte måneder for et stort skreddersydd system. Laravel-siden starter fra de samme 8 000 € og 6–24 uker, og det er ikke billigere skreddersydd programvare: det er en side for den som allerede vet at arbeidet er Laravel, ikke en test på om arbeidet i det hele tatt er et bygg.

Disse tallene får ikke bli setningen «skreddersydd programvare er det dyreste valget», fordi en Moodle-innføring starter fra 15 000 €, Pro-versjonen av butikken koster 9 500 €, og begge ligger over startprisen for skreddersøm, fordi det ene er innføring av et stort produkt, det andre en butikk med lager og B2B-priser. Å sammenligne startprisen på 8 000 € med Moodle-startprisen som «bygg mot produkt» er gal aritmetikk, fordi du bare kan sammenligne to veier for den samme prosessen, og selv da er begge sider startpriser, ikke totalsummer; for større ikke-standard arbeid regner vi etter tid og materialer med et ukentlig tak, fordi fast pris der som regel betyr et risikopåslag eller en krangel om omfanget, og timesatsen er 50 €.

Abonnement mot bygg er heller ikke en formel der den ene siden automatisk vinner etter N år, og den statlige kostnadsplanleggingen navngir det vi også ser i private avtaler: SaaS-avgiften kan stige med antall brukere eller med indeksregulering, integrasjonene blir dine kostnader, og et bytte av leverandør trenger en utgangsplan, fordi dataene ligger hos dem. Det er ikke en prosent av bygget vi ville sitert her, fordi fotnoten bak slike tall peker på leverandørblogger, og slike tall skriver vi ikke, men formen blir stående: et abonnement er en linje hvert år, et bygg er en startpris pluss vedlikehold, og ingen av dem er uten linje.

Dataforordningen, som i Unionen gjelder fra 12. september 2025, hjelper deg å ta ut dataene som kan tas ut av en skytjeneste og forbyr leverandøren å legge hinder i veien for bytte, men funksjonell ekvivalens krever den av en infrastrukturtjeneste, ikke av et CRM du bare «flytter», og forordning 2023/2854 lover ikke at prosessen flytter med filen. Personvernforordningen artikkel 20 flytter personopplysninger den registrerte har gitt, ikke applikasjonen, ikke konfigureringen din, ikke forretningsreglene, derfor er et system du kan flytte til en annen utvikler, kildekoden vi overleverer, ikke en eksport fra et fremmed panel, og dette er også stedet der denne delen slutter, fordi neste setning allerede ville vært en prisliste vi ikke har for dette spørsmålet.

Det vi ikke sier når vi snakker om skreddersydd programvare

Vi sier ikke at et eget system alltid er klokere, at det ferdige produktet er for dem som «ennå ikke har vokst», eller at bygget etter tre år helt sikkert har betalt seg, fordi en slik kurve uten prosessen din er oppdiktet. En artikkel som etter en ærlig start likevel lander på at du må kjøpe et bygg, har gått for langt, og det har vi sett ofte nok til å stoppe her, fordi ærlighet er en begrensning og en kort test er målet.

Vi sier heller ikke at Laravel er svaret på spørsmålet om det ferdige produktet, fordi Laravel er måten vi skriver på når testen allerede har gitt et bygg, og å selge et rammeverk til et menneske som trenger Moodle, er å selge en hammer til et menneske som trenger en hylle. Laravel-siden vår starter fra 8 000 € og snakker om API-er, køer og tester, men denne artikkelen snakker om hvorvidt du i det hele tatt trenger den siden, og å blande dem betyr at du velger verktøyet før du har valgt arbeidet.

Vi sier heller ikke at kartleggingsworkshopen er en skjult måte å lede deg inn i et bygg på, fordi resultatet av workshopen er en plan som blir stående nyttig også om du velger å ikke bruke oss, og av og til sier planen: ta produktet du allerede har navngitt, så innfører vi det, eller så innfører noen andre det. Hvis denne setningen høres ut som en tapt handel for deg, er det fordi den er en tapt handel, og vi taper heller et bygg der vi skulle ha skrevet enda et CRM, enn å vinne en kunde som om et år spør hvorfor han vedlikeholder et system han kunne ha abonnert på.

For et offentlig innkjøp virker ikke denne testen på samme måte som for en privat bedrift, og den kan ikke overføres dit uten tilpasning, fordi Digitaliseringsrundskrivet krever at virksomheten tar stilling til hva den skal utføre selv og hva som skal overlates til eksterne, og det hører til innkjøpet, ikke til denne setningen, mens det på den private siden er prosessen din og prislisten vår som hører til. Begge sider kan komme fram til det samme svaret, og de kommer ikke fram til det fordi den ene skulle være den andres lov.

Slik tar vi denne beslutningen hos oss

Arbeidet starter med en kartleggingsworkshop på to til tre dager, der vi sammen med teamet ditt går gjennom prosesser, brukerroller, risikoer og MVP-omfanget, og det er ikke en formiddag med lysbilder, men et arbeid der vi etterpå kan si om prosessen får plass i et ferdig verktøy, om den krever den tredje veien, eller om den er et bygg. Hvis svaret er et produkt, har workshopen betalt seg med denne setningen; hvis svaret er et bygg, er neste steg ikke kode.

Før produksjonskode lager vi på to til tre uker en klikkbar prototype, fordi det er billigere å ombestemme seg der enn i et ferdig system, og prototypen er ikke «for å ha noe å vise styret», men stedet der du ser at pristabellen du navnga i går, i virkeligheten er en annen tabell, og der denne oppdagelsen koster dager, ikke måneder. Først deretter starter utviklingen: i de første tre månedene bygger vi et MVP som kan brukes på ekte, og videre utvider vi trinnvis, i sprinter på to uker med demonstrasjon etter hver.

Til slutt får du kildekoden, dokumentasjonen og infrastrukturoppsettet og kan flytte det til en annen utvikler, og det er ikke et løfte om at flyttingen blir hyggelig, men et løfte om at du ikke er bundet til kontoen vår. I de større prosjektene blir vi på tid og materialer med et ukentlig tak, og grensen for MVP-et setter vi likevel, fordi «agile» ellers blir et ord omfanget forsvinner bak, og hvis du etter workshopen går en annen vei, blir planen din, slik vi har skrevet på tjenestesiden, og denne artikkelen endrer ikke på det.

Før du skriver til oss, skriv prosessen på én side uten et verktøynavn og merk hvilke linjer du ikke får gi fra deg til en fremmed utgivelse: hvis siden er tom eller bare har «for å ha et eget system», trenger du et produkt, og det sier vi også, men hvis siden har en prosess en konkurrent ikke kan kjøpe som et ferdig verktøy, da er det verdt å snakke om et bygg. Skriv til oss hvis du vil at vi leser denne siden sammen med deg og sier hvilken side som er din, også når svaret er å ta produktet du allerede har navngitt.