Nettbutikkplattform: WooCommerce eller Laravel — hvilken du velger og når

Det er ikke funksjonslisten den første dagen som avgjør plattformen — lager, B2B-priser og flere språk bygger vi i begge. Det som avgjør, er hvem som bestemmer neste endring hos deg, og hva den koster.

Et teknologispørsmål der svaret ikke er en funksjonsliste

Samtalen begynner nesten alltid likt. Kunden har rundt sju hundre produkter, tre prisnivåer for forhandlere der hver av dem bare ser sin egen pris i sin egen profil, og et regnskap i Visma Horizon der lagerbeholdningen er sannheten butikken bare speiler. Spørsmålet han stiller, lyder slik: WooCommerce eller Laravel som nettbutikkplattform? Svaret han venter seg, er en liste med to kolonner der noe står på den ene siden og mangler på den andre — en liste vi ikke har, og som ingen har som faktisk bygger begge deler.

Lagermodul med synkronisering av lagerbeholdning i sanntid, B2B-prisnivåer, rabattsystem, støtte for flere språk og migrering av innhold bygger vi på begge plattformene, og prisen i prislisten vår er ikke avhengig av hvilken som ligger under: utvikling av nettbutikk koster 4 500 € i basisversjon og 9 500 € i Pro-versjon, både på WooCommerce og på Laravel. Det er nøyaktig disse fem linjene som skiller basisversjonen fra Pro, ikke det som ligger nederst; administrasjonspanelet er navngitt i prislisten allerede under basisversjonen, mens støtte for flere valutaer ikke ligger i noen av de to versjonene og avtales for seg — igjen på hvilken som helst av de to plattformene.

Av dette følger noe praktisk: en plattform som selges til deg på en funksjonsliste for den første dagen, selges på noe du kan få begge veier, og en sammenligning som starter med en slik liste, er ferdig før den har begynt. Det interessante spørsmålet begynner ett skritt lenger fram — hvem bestemmer hva butikken din skal kunne gjøre neste år, og hvor lenge står den avgjørelsen i kø hos noen andre.

Det første året gjør begge plattformene det du har betalt for, for i begge tilfeller er det noen som nettopp har bygd det; det andre året endrer prosessen seg — det kommer engrossalg, et lager til, en plikt til å utstede maskinlesbare fakturaer eller rett og slett en annen rabattordning — og fra det øyeblikket koster de to veiene ulikt. På en utvidelse fra en annen leverandør er hver senere endring som en ombygging i leide lokaler: reglene for din egen prosess bor i et innstillingsvindu som tilhører noen andre, og de flytter seg etter en utgivelsesplan som tilhører noen andre. På din egen kode er det samme en jobb med en sats i prislisten, og det eneste som skal avklares, er hvilken prioritet den får mot resten av oppgavelisten.

Det WooCommerce gjør godt

WooCommerce legger vi selv inn i kundebutikker hver gang prosessen passer, og det er det mest brukte systemet for netthandel i undersøkelsene til W3Techs: 6. august 2026 kjørte det på 8,2 % av alle nettsteder og utgjorde 48,5 % av alle netthandelssystemer i disse undersøkelsene. Viktigere enn selve tallet er hva det er regnet ut av — en andel av de undersøkte systemene, ikke av verdens butikker og aller minst av omsetningen i netthandelen — og bak det står WordPress med 41,2 % av alle nettsteder.

Utvidelseskatalogen på WordPress.org viste samme dag WooCommerce i versjon 11.0.0, oppdatert 4. august, med anslaget «7+ million active installations», og å lese det forsiktig er det leverandøren selv som anbefaler: bruksstatistikken er slått av som standard i kjernen du laster ned fra WordPress.org, så ingen — heller ikke Automattic — vet hvor mange butikker som faktisk driver handel, og tallet er en øvre grense for installasjoner, ikke et antall handelsdrivende.

Prissiden til leverandøren beskriver WooCommerce som en plattform med åpen kildekode uten plattformavgift og med 0 % andel av inntektene: du betaler ikke for at du selger, og ikke for at omsetningen vokser. Katalogen, ordrelisten og rabattinnstillingene ser dessuten ut som resten av WordPress-administrasjonen, som teamet ditt sannsynligvis allerede kan bruke uten opplæring.

Det sterkeste argumentet for WooCommerce forsvinner nesten alltid i sammenligninger med konkurrentene, og det er den automatiske rettelsen: 2. mars 2026 ble det offentliggjort en sårbarhet i Store API som traff versjonene fra 5.4 til 10.5.2 og lot en forfalsket forespørsel opprette en administratorkonto; feilen ble funnet av noen andre enn butikkeierne; rettelsen ble tilbakeført over 52 berørte versjoner; og samme dag fra klokken 14.00 UTC begynte den å spre seg automatisk til butikker med automatiske oppdateringer slått på, uten faktura. Selve innstillingen er ikke selvsagt, og det er nettopp den et menneske setter opp og holder øye med i en vedlikeholdsavtale; hvordan WordPress-nettsteder blir hacket og hva du gjør når det allerede har skjedd, står i artikkelen vår om hacket WordPress-nettsted.

Anbefalingen har derfor ikke endret seg, og den står også på tjenestesiden vår: for en svært liten nettbutikk med standardprosesser — WooCommerce. For hundre produkter med én pris, ett lager og én betalingsmåte gir en skreddersydd plattform ingenting det er verdt å betale differansen for, og å selge det dyreste alternativet når det billigste gjør det samme, gir én misfornøyd kunde til og ikke én eneste anbefaling.

Passer WooCommerce til betalinger og frakt i Latvia?

Ja. Frakt og betaling i Latvia er ikke stedet der en ferdig nettbutikk stopper, og advarsler om det motsatte er som regel grunnløse: Omniva publiserer ferdige moduler for seks plattformer — WooCommerce, Shopify, PrestaShop, OpenCart, Magento og Mozello — og ved siden av dem et dokumentert OMX-grensesnitt som frakter sendingsdata, etiketter, sporingshendelser og lister over pakkeautomater i alle de tre baltiske landene, men forutsetningen for det er en bedriftsavtale og ikke en programmerer. DPD Baltics vedlikeholder selv sin egen WooCommerce-utvidelse i katalogen på WordPress.org — versjon 1.2.91, mer enn 2000 aktive installasjoner — og den dekker pakkeautomater, kurérlevering, etiketter, manifester og oppkrav; samme sted ser du også den offentlige vurderingen 2,7 av 5 og brukeromtaler som klager på konflikter med andre fraktutvidelser.

MakeCommerce, som Maksekeskus AS står bak, gir deg med én avtale banklenker fra Swedbank, SEB, Citadele og Luminor, kort, Apple Pay og Google Pay, og rett ved siden av det frakt med Omniva, DPD, Venipak og Unisend; WooCommerce-utvidelsen deres har mer enn 3000 aktive installasjoner og ble sist oppdatert i juni 2026. Klix by Citadele, som banken selv vedlikeholder, publiserer offisielle utvidelser for seks plattformer, deriblant WooCommerce fra versjon 3.5, så å påstå at en ferdig butikk ikke klarer å ta imot penger i Latvia, ville rett og slett være usant.

Baksiden av det samme er at disse tjenesteleverandørene ikke er utvidelsenes eiendom: MakeCommerce, Omniva og DPD publiserer grensesnitt og ikke bare moduler, og i prislisten vår ligger tilkobling av betalinger — MakeCommerce og Stripe — allerede i basisversjonen til 4 500 €, uansett hvilken plattform som står under. Integrasjoner mot Horizon, Jumis, Latvijas Pasts, Omniva og DPD er en linje i butikktjenesten og ikke et tillegg for Laravel, og med frakt-API-ene til Omniva, Latvijas Pasts, DPD og Venipak jobber vi jevnlig, så det latviske laget for frakt og betaling er verken et argument for eller mot noen av de tre veiene.

Der jobben i Latvia faktisk ligger

Baksystemene blir kompliserte av at Visma Horizon, Jumis og Directo hver publiserer sitt eget REST-grensesnitt — dokumentasjonen til Directo beskriver autentisering med headeren X-Directo-Key og tilgang til varer, ordrer, kunder, fakturaer, lagerbeholdning og prisformler — men et publisert grensesnitt er ennå ingen integrasjon: noen må koble det butikken kaller en vare, til det regnskapet kaller en artikkel, og bestemme hvilket av de to systemene som eier sannheten om beholdningen i det sekundet kjøperen trykker på knappen. To steder der beholdningen ligger, er som to klokker om bord på et skip: så lenge de ikke er stilt likt, vet ingen hva klokken er, og denne jobben er skreddersøm på enhver plattform — med Horizon og Jumis gjør vi den jevnlig.

Over dette står et datert lovfaktum med en felle i: strukturert elektronisk faktura er obligatorisk overfor offentlige virksomheter fra 1. januar 2025, mens den i handel mellom bedrifter blir obligatorisk 1. januar 2028 — etter reglene i den latviske regnskapsloven og i formatet LVS EN 16931-1:2017. Fellen er datoen: opprinnelig var det satt til 2026, og derfor navngir presseartikler fra 2024 fortsatt feil frist, så den skal kontrolleres på siden til det latviske finansdepartementet om strukturert elektronisk faktura og ikke i nyhetene, for en butikk som selger til bedrifter, vil på enhver plattform trenge at noen bygger veien til en maskinlesbar faktura, uansett hvilket år som ender opp med å være det riktige.

Nettbutikkplattform: hvilken av de tre veiene er din?

Sammenligninger som legger dette fram som to knapper, hopper over veien vi selger oftest, for veiene er i virkeligheten tre; de skiller seg fra hverandre etter hvor stor del av prosessen din som bor i kode du selv kan endre, og valget mellom dem er et valg om hvor reglene for pris og ordre skal ligge heretter — i et innstillingsvindu, i ditt eget repositorium eller midt imellom de to.

Den første veien er et ferdig verktøy med ferdige utvidelser — WooCommerce eller OpenCart, som vi også tilbyr eksisterende butikker. I WooCommerce-kjernen ligger det to prisfelt, ordinær pris og kampanjepris, ett beholdningstall per produkt eller variasjon og tre betalingsmåter der ingen tar imot penger på nett, og derfor er pris for en bestemt kundegruppe, kvantumsrabatter, det å gjøre et tilbud om til en ordre, fritak for mva. og beholdning på flere lagre et eget kjøp fra en egen leverandør med et eget årsabonnement. Veien er den raskeste og svært ofte den riktige, og prisen for den er ikke penger, men at reglene for prosessen din heretter bor i innstillingsvinduet til en annen leverandør.

Den andre veien dukker nesten ikke opp i sammenligninger, enda det er den vi selger oftest: et ferdig verktøy med vår egen kode oppå. WooCommerce er PHP-kode med åpen kildekode, så en pristabell for forhandlere, en kredittkontroll eller en reservasjon av beholdning kan skrives ved siden av kjernen framfor å kjøpes som en utvidelse, og lisenser finnes det ikke for den — det finnes timer — mot at koden blir bundet til oppdateringsrytmen i WooCommerce og til måten plattformen lagrer ordrer på. En betydelig del av det prislisten vår kaller Pro-versjonen til 9 500 €, er nettopp dette arbeidet, og her ligger de fleste av butikkene vi selv bygger.

Den tredje veien er vår egen plattform, der katalog, handlekurv, kasse og prislogikk er skrevet fra bunnen av rundt prosessen din; det er den dyreste starten og den eneste uten en eneste annen leverandørs antakelse om hva en vare er og når en ordre blir en ordre. Inne i den tredje veien går det en forgrening: Bagisto og Lunar er MIT-lisensierte Laravel-pakker for handel — 6. august 2026 med henholdsvis 27 943 og 3 588 stjerner på GitHub — som gir katalog og handlekurv ferdig skrevet, i bytte mot enda en ekstern avhengighet med en rytme du ikke rår over. Den veien går vi ikke.

Hva koster lisensene til WooCommerce-utvidelser i året?

For en butikk med sju hundre produkter og tre forhandlernivåer kostet den første veien 270 € i året 6. august 2026, for to offentlige priser pluss en ukjent tredje. Dynamic Pricing til 113 € i året gir kvantums- og rollerabatter; B2B for WooCommerce, utviklet av Addify, gir til 157 € i året rollepriser, trappepriser, det å gjøre et tilbud om til en ordre, fritak for mva. og betalings- og fraktmåter begrenset etter rolle; men kjernen har ingenting for beholdning på flere lagre, så en tredje betalt utvidelse kommer i tillegg, for eksempel Addify Multi Inventory Management, som leverandøren ikke oppgir noen offentlig årspris for.

De 270 € i året er litt mer enn fem utviklingstimer, siden en utviklingstime koster 50 € i prislisten vår, og for funksjoner som har en leverandør, dokumentasjon og oppdateringer er det billig. En pris du ikke kjenner før samtalen, er likevel ingen linje i et estimat: lagerutvidelsen løfter dette tallet, og hvor mye den løfter det, avhenger av tilbudet som kommer til deg etter at du har oppgitt antall lagre og ordrevolum.

En annen butikk har andre linjer: for den som selger abonnementer, bookinger og medlemsnivåer, koster WooCommerce Subscriptions 245 € i året til de samme prisene på markedsplassen, Bookings 218 €, Memberships 175 €, AutomateWoo 140 € og Product Add-Ons 70 € — til sammen 848 € i året. Over fem år, dersom prisene ikke stiger, blir det 4 240 €: nesten hele prisen på en butikk i basisversjon, som i prislisten vår er 4 500 €, og nesten halvparten av Pro-versjonen til 9 500 €. Denne linjen avskrives ikke, for den gjelder ett nettsted, ett år, og betales på nytt hvert eneste år.

Det samme tallet snudd andre veien er nesten 85 utviklingstimer til 50 €, og det er timer som blir liggende i koden din og i din eiendom framfor å komme igjen på neste års faktura. Regningen på 848 € er dessuten regningen til en butikk med abonnementer, bookinger og medlemskap, ikke en norm — noen norm finnes ikke her, og hver butikk må summere denne linjen ut fra sin egen prosess. Lisenslinjen kommer dessuten på toppen av byggingen og ikke i stedet for den: i begge tilfeller er det noen som først har bygd butikken, og bare i det ene tilfellet kommer det en ny faktura for det som er bygd, i januar året etter.

Hva regningen gjør når den ikke blir betalt

Fornyer du ikke abonnementet, sier dokumentasjonen på WooCommerce.com det rett ut: «the extension or theme remains installed on your site but will no longer receive updates» — utvidelsen blir stående installert, butikken fortsetter å virke, og det eneste som forsvinner, er oppdateringene. Følgen av en lisens som ikke blir fornyet, er derfor ikke nedetid du oppdager samme dag, men et stykke kode uten rettelser som fortsatt behandler betalinger; ett abonnement dekker dessuten ett produksjonsnettsted og ett utviklingsnettsted, og underdomener teller for seg.

Én linje oppfører seg annerledes, og den oppfører seg likt på begge sider: en regnskapskobling er som regel ingen lisens, men et abonnement som stiger med antallet ordrer — MyWorks Xero Sync starter på markedsplassen til WooCommerce med et gratisnivå, og videre er det volumet som setter prisen, så denne linjen vokser nettopp når butikken vokser. En skreddersydd plattform fjerner den ikke, men endrer hvem som vedlikeholder koblingen, og hos oss er det timer; linjene skal heller ikke blåses opp: flere språk er ikke automatisk 99 € i året for WPML Multilingual CMS, for ved siden av WPML står også Polylang, mens den billigste WPML-lisensen, Multilingual Blog til 39 €, ikke støtter netthandel, så for en butikk finnes ikke valget mellom 39 € og 99 €.

Hvorfor forskjellen dukker opp i det andre året

At prisen på endringer er en reell og ikke en teoretisk utgift, viser plattformen selv: siden 2023 har WooCommerce fjernet to bærende deler, trukket tilbake én betafunksjon og endret ett standardvalg. Det gamle REST-API-et forsvant fra kjernen 11. juni 2024 med versjon 9.0, etter å ha vært regnet som utdatert helt siden versjon 2.6 i 2016; den innebygde betalingsløsningen PayPal Standard ble fjernet i versjon 8.9 i mai 2024; betaversjonen av produktredigeringen ble fjernet i versjon 11.0, som dukket opp i katalogen 4. august; mens HPOS-lagring av ordrer ble standard for nye installasjoner i versjon 8.2 i oktober 2023 og ikke rører eksisterende butikker før noen migrerer dem.

Mot denne bakgrunnen ligger det 37 innlegg i kategorien Advisories på utviklerbloggen til WooCommerce i de tolv månedene fram til 5. august 2026 — omtrent tre i måneden — og hvert av dem må kontrolleres mot hver eneste utvidelse som er installert i butikken, noe en butikk med fire utvidelser tar uten anstrengelse, mens en butikk med tjue ikke gjør det lenger. Haugen samler seg dessuten ikke på én dag: utvidelsene kommer én om gangen, hver av dem er isolert sett en helt fornuftig beslutning, og multipliseringen av kombinasjoner som skal kontrolleres, skjer i stillhet.

Ti utvidelser er ikke ti deler, men ti avtaler som hver kan ta slutt for seg, og eieren skifter også når det ikke er noe galt med koden. 31. oktober 2025 slo omtaletjenesten Judge.me av sin WooCommerce-integrasjon sammen med Square, Squarespace, BigCommerce, Duda og PrestaShop: dataene var tilgjengelige fram til 19. november, deretter ble tilgangen fjernet for godt, og videoene i omtalene fulgte ikke med i eksporten, slik at et markedsføringsaktivum bygd opp gjennom år delvis ble stående på den andre siden av døren. De rolige tilfellene er mer overbevisende: i 2019 kjøpte Automattic opp Prospress, som sto bak WooCommerce Subscriptions og AutomateWoo, i 2020 kjøpte GoDaddy opp SkyVerge, hvis mer enn seksti utvidelser ble brukt av mer enn 100 000 handelsdrivende, og begge oppkjøpene endte, så langt det er offentlig kjent, godt for de handelsdrivende. Spørsmålet handler ikke om skade, men om at eieren av en del av butikken din kan skiftes ut uten at du er med på det.

Hvor stor denne risikoen faktisk er

Målestokken setter den i perspektiv, og tallene her er våre egne: i opptellingen 6. august 2026 ga utvidelses-API-et på WordPress.org 7 764 utvidelser med merkelappen «woocommerce», og av dem er 23,1 % ikke oppdatert på to år eller mer, men i den samme opptellingen sitter 10 809 800 aktive installasjoner på utvidelser som er oppdatert i løpet av de siste seks månedene, og bare 208 790 på slike som ikke er rørt på mer enn tre år. Utvidelser med 10 000 installasjoner eller mer som har stått uten oppdatering i to år, er det i den samme opptellingen nøyaktig seks av.

Den forlatte utvidelsen er nesten aldri den populære alle kjenner: risikoen sitter i den ene smale modulen nettopp din prosess krever — i B2B-prisnivåene, i lagerkoblingen, i etikettgeneratoren til en bestemt kurér — og jo mer prosessen din skiller seg fra gjennomsnittet, jo nærmere er du den delen av katalogen der siste oppdatering er fra forfjor. Denne linjen kan reduseres uten å bygge om noe som helst: i en vedlikeholdsavtale gjør vi det — vi kutter antallet utvidelser, setter opp oppdateringene og holder overvåkingen i gang — og ombygging er svaret bare når problemet ikke lenger er vedlikehold, men at prosessen ikke er skrevet ned noe sted.

Der formen på WooCommerce-dataene begynner å stramme

Det andre stedet det andre året koster, er formen på dataene, og først den siden der dette argumentet ikke lenger holder: ordrer i nye installasjoner ligger siden versjon 8.2 i fire egne tabeller, og selskapets egen måling fra mars 2023 viser at den nye lagringen gjør ordreoperasjonene raskere og ikke tregere. Det som strammer, er produktsiden, og best skrevet er den av WooCommerce-utviklerne selv, da de 1. april 2019 forklarte ytelsesforbedringene i versjon 3.6: varer og variasjoner går gjennom innleggssystemet i WordPress, der post meta er ekstremt fleksibelt, men «not that efficient when we need to sort or filter by many meta values at once» — ikke særlig effektivt når det skal sorteres eller filtreres på mange metaverdier samtidig. Svaret i den samme utgivelsen var wc_product_meta_lookup, en denormalisert hjelpetabell med SKU, pris og lagerstatus ved siden av post meta, ikke i stedet for den, slik at grunnformen ble stående som den var.

Det tilsvarende arbeidet på produktsiden, woocommerce-product-tables-feature-plugin, har siden 16. oktober 2017 bare bodd på GitHub og er ikke forlatt — siste endringer er fra 31. juli 2026 — men det regnes fortsatt ikke som stabilt nok for katalogen på WordPress.org. Ved siden av det står wp_options, som ikke har noen indeks på autoload-feltet som standard, hvis autolastede data leses ved hver eneste sidevisning, som WooCommerce selv anbefaler å holde under rundt 500 rader, og hvis vekst skapes nettopp av utvidelser og temaer — den samme haugen det var snakk om lenger opp, bare sett fra databasesiden.

Det Laravel gir en butikk som et ferdig verktøy ikke gir

Laravel er ingen butikk og later ikke som om det er det: det gir navngitte, dokumenterte og MIT-lisensierte deler som noen setter sammen til en butikk, så spørsmålet som er verdt penger her, er ikke «er rammeverket bra», men «hvilke deler av prosessen din blir endelig dine egne tabeller og dine egne jobber». I butikken til en grossist er svaret som regel fire linjer — pristabellen for forhandlere, kredittgrensen, reservasjon av beholdning og synkronisering mot regnskapet — og det er nettopp dem du i et ferdig verktøy kjøper fra fire ulike leverandører og deretter avstemmer mot hverandre.

Først er det ærlig å si hva denne veien ikke gir, for ingen av de fire linjene kommer fra Laravel heller: de offisielle startpakkene til rammeverket gir autentisering og ingenting mer — verken katalog, handlekurv, kassesteg eller lager — og den eneste handelspakken som følger med, er Cashier, som betjener abonnementsfakturaer på Stripe- eller Paddle-siden og forventer at produkter med priser allerede er beskrevet i panelet hos betalingsleverandøren. Det Laravel gir, er en form der disse fire linjene er billige å skrive og enda billigere å endre senere.

Køer, transaksjoner og din egen databaseform

Den første delen er køene: ett API over flere motorer — Redis, database, Amazon SQS, Beanstalkd — som lar ordrebehandling, ERP-synkronisering og e-post gå ut av forespørselen, slik at kjøperen ikke lenger venter på at regnskapssystemet skal svare. Dokumentasjonen navngir også det som avgjør en reell innføring: kjeder og batcher av jobber, unike jobber som køen ikke kjører to ganger, nye forsøk og et lager for mislykkede jobber som lar dem kjøres om igjen. En ordre som er kjørt to ganger, er en faktura noen må kreditere etterpå, og en kunde som oppdager den før deg.

Horizon viser gjennomstrømningen i køene, kjøretidene og feilene, lar konfigurasjonen av arbeiderprosessene beskrives i kode og varsler når en kø venter for lenge, men det krever Redis og virker foreløpig ikke med Redis Cluster, så det er en egen post på driftsregningen og ikke et gratis tillegg. Transaksjoner er på sin side det setningen «ordren og lagerbevegelsen skjer begge eller ingen» betyr i praksis: DB::transaction ruller endringene tilbake selv når det oppstår en feil, og lar dem prøves på nytt dersom databasen havner i vranglås.

Migreringer kaller Laravel-dokumentasjonen versjonskontroll for databasen, og i praksis betyr det at du utformer tabeller, indekser og fremmednøkler rundt din egen pris- og lagerlogikk, ikke rundt det noen andre en gang bestemte om hva en vare er. Søk og abonnementsfakturaer forblir dessuten et valg, ikke en obligatorisk månedlig linje: Scout indekserer i selve databasen med fulltekstindekser i MySQL eller PostgreSQL uten noen ekstern tjeneste, mens Stripe-siden betjenes av Cashier, dersom butikken i det hele tatt har abonnementer.

Pristabell, kredittgrense og reservasjon i kode

Hvordan det ser ut konkret, viser den første av de fire linjene best: pristabellen for forhandlere er på egen kode én migrering med fire kolonner — kundegruppe, vare, kvantumsterskel og pris — og en unik indeks over de tre første, slik at prisen for en bestemt kjøper finnes med én spørring og én join og ikke med et søk gjennom metaverdier, og et nytt prisnivå er en ny rad i tabellen framfor en ny innstilling i vinduet til en annen leverandør. Når det etter et år kommer et fjerde nivå med en annen avrundingsregel, endres ett sted og én test, og begge ligger i repositoriet ditt.

Kredittgrensen og reservasjonen av beholdning er den samme tanken ett skritt videre, for også der hviler alt på én tabell og én transaksjon: summen av ubetalte fakturaer er en kolonne på kunden, og kontrollen skjer i den samme transaksjonen som ordren blir til i, slik at to ordrer som sendes inn samtidig, ikke begge kan smette under grensen, mens transaksjonen ved vranglås gjentas av seg selv. Reservasjonen er på sin side en rad med utløpstid som oppstår sammen med ordren og forsvinner med en planlagt bakgrunnsjobb dersom ordren ikke blir betalt, slik at lagerbeholdningen ikke lenger er et tall to kjøpere kan tømme samtidig.

Synkroniseringen mot regnskapet er en køjobb merket som unik, slik at et nytt forsøk aldri utsteder en faktura to ganger, og når Horizon om morgenen viser at det var et avbrudd i regnskapsenden i natt, lar lageret for mislykkede jobber dem kjøres om igjen etter tur framfor å skrives inn på nytt for hånd. Hver av disse fire linjene finnes også i et ferdig verktøy, bare som et innstillingsvindu fra en leverandør, med regler du ikke ser, som må kontrolleres på nytt etter hver oppdatering, og som ikke flytter med til en annen plattform.

To arbeider som allerede er i drift

Hvordan det ser ut i et prosjekt framfor i dokumentasjonen, ser du i våre egne Laravel-arbeider. I bestillingsplattformen for mat hos LIDO er det ikke varen som avgjør prisen, men adressen: geolokasjon setter leveringssonen, avstanden og prisen, hver av de tretten restaurantene har sitt eget utvalg av retter, og ved siden av butikken kjører et eget system for prosessautomatisering der alle ordrer havner og derfra fordeles på restauranter og kokker — med integrasjoner mot mer enn ti andre systemer, deriblant Wolt, QWQER og RKeeper. I nettbutikken til Riga Lashes, som står på Laravel, ligger variantpriser, kundekontoer, ønskeliste og prisliste for tjenestene i studioet, og bak dem varelageret, integrasjonene mot budtjenestene og betalingene, der prosessen er automatisert helt fram til pakking. I begge tilfellene måtte den avgjørende delen ha vært skrevet også på et ferdig verktøy, bare inne i prisene og ordreformen til en annen leverandør, og det er nettopp dette som er forskjellen som blir stående: på egen kode er dette arbeidet ett repositorium uten et eget abonnement per evne, og det trenger ikke kontrolleres på nytt etter hver oppdatering av plattformen. Laravel har vi skrevet siden 2013, og på det kjører de fleste av våre skreddersydde systemer, portaler for offentlig sektor og B2B-plattformer.

Hvor pengene som ikke går til lisenser, tar veien, er et konkret spørsmål, og svaret er like konkret: de nesten 85 timene som lisenslinjen på 848 € i året koster over fem år, er på egen kode nøyaktig denne pristabellen, denne kredittgrensen, denne reservasjonen og denne synkroniseringen, skrevet rundt din prosess. De blir liggende i repositoriet ditt også dersom vi en gang slutter å være partneren din: i et bestilt byggeoppdrag er koden din fra første dag, og det står også på Laravel-tjenestesiden vår.

Filament: administrasjonspanelet ingen skriver fra bunnen av

Den delen av innvendingen om at alt må skrives fra bunnen av i et selvbygd system, som handler om administrasjonspanelet, fjernes av Filament — et grensesnittrammeverk med åpen kildekode for Laravel-applikasjoner. Ressurser genererer CRUD-skjermer for Eloquent-modeller, tabellbyggeren gir filtrering, sortering og paginering, skjemakomponentene kommer med innebygd validering, mens Filament leser tilgangsrettighetene rett ut av modellpolicyene i Laravel, slik at rollekontrollene ikke trenger å skrives en gang til. Relasjonsbehandlere, widgeter til dashbordet og varslinger ligger i den samme pakken; det gjør støtten for flere leietakere også, riktignok med Filaments egen advarsel om at dette er et sett med verktøy og ingen garanti, og at det er den som innfører det, som svarer for skillet mellom leietakernes data; hele laget er MIT-lisensiert, akkurat som Laravel selv, så noen lisensavgift finnes det ikke der.

Det viktigste er likevel ikke hva rammeverket tegner, men hvor de frigjorte pengene tar veien: redigeringsskjermer for varer, ordretabeller, filtre og rettighetskontroller er den delen av utviklingen kjøperen aldri ser og bestilleren likevel betaler full sats for, og når rammeverket gir dem, går budsjettet til logikken for pris, ordre og lager som skreddersøm i det hele tatt ble valgt for. Eksempelet ligger der du leser dette: dette nettstedet kjører på Laravel 13 og Filament 5, og alt redaksjonelt arbeid på tolv språk skjer i et panel vi konfigurerte framfor å skrive fra bunnen av.

Der rammeverket slutter og butikken begynner

Filament er ingen butikk, og den grensen er verdt å trekke tydelig: rammeverket gir et administrasjonspanel — skjermer, tabeller, skjemaer og rettighetskontroller — men vet ingenting om hva som ligger i disse tabellene og etter hvilke regler det havner der. Varekatalog med variasjoner og attributter, handlekurv, kassesteg, prisregler med kundenivåer og kvantumsrabatter, ordrens livsløp fra opprettelse til retur og reservasjon av beholdning på lageret — ingenting av det ligger i pakken med Laravel og Filament. Filament er som et ferdig innredet verksted med hyller, arbeidsbenker og lys; hva du skal produsere der, følger ikke med.

Hvor bokstavelig det skal forstås, viser dokumentasjonen selv, der modellene Order og Payment bare dukker opp som eksempler utvikleren skriver selv, for slike klasser finnes rett og slett ikke i rammeverket. Det er ingen mangel ved rammeverket, men en arbeidsdeling: Filament lover et administrasjonsgrensesnitt og ingenting annet, akkurat som Laravel lover et rammeverk og ikke en ferdig applikasjon. I praksis betyr det at Filament forkorter administrasjonsarbeidet, men ikke forkorter noe i den delen som skreddersøm i det hele tatt ble valgt for.

Derfor kommer basisversjonen av butikken til 4 500 € i prislisten vår uten lagermodul, støtte for flere språk, B2B-prisnivåer, rabattsystem og migrering av innhold, mens Pro-versjonen til 9 500 € har dem alle sammen. Forskjellen er ikke et påslag for mer moderne teknologi, men prisen for det noen må skrive, og nettopp derfor er den lik på begge plattformene. Et Laravel-system med fast omfang fra 8 000 € er allerede en annen linje og en annen vare i prislisten: det er ingen butikk, men et system der hele prosessen blir til fra bunnen av.

Det vi ikke lover: der egenbygd koster mer

En egenbygd butikk er fri for årslisenser på utvidelser, ikke for vedlikehold, og det er to helt forskjellige ting. Laravel gir hver utgivelse 18 måneder med feilrettinger og to år med sikkerhetsrettinger, slipper en ny hovedversjon én gang i året og har ikke noe nivå med langtidsstøtte, så datoene er konkrete: Laravel 13 kom 17. mars 2026 med sikkerhetsrettinger til 17. mars 2028, sikkerhetsvinduet for Laravel 11 lukket seg 12. mars 2026, mens feilrettingene for Laravel 12 slutter 13. august 2026. Én gang i året eller annethvert år må systemet altså flyttes til en ny hovedversjon, og Laravel-dokumentasjonen sier at de bestreber seg på å gjøre det mulig på en dag eller mindre — en bestrebelse, ikke et løfte om hvor lang tid det tar i ditt system.

PHP-løpebanen er dessuten den samme for begge sider: hver versjon får to år med aktiv støtte og to år med bare sikkerhetsrettinger, så i et femårsvindu ligger minst én og, avhengig av hvor i syklusen du starter, opptil to påtvungne PHP-overganger, uansett hva som ligger under. Verken en WooCommerce-butikk eller en Laravel-butikk slipper unna denne linjen, og i begge tilfeller planlegges den av den samme personen som planlegger resten av vedlikeholdet — forskjellen er bare at på egen kode kan overgangen gjøres når det passer deg, framfor når en utvidelse slutter å støtte den gamle versjonen.

Tre linjer der det ferdige verktøyet vinner

Dyrere enn vedlikeholdet er tre andre linjer, og den første av dem er økosystemet: her vinner det ferdige verktøyet uten diskusjon. Enda en markedsføringsautomatisering i en WooCommerce-butikk er en oppføring på markedsplassen — AutomateWoo koster for eksempel 140 € i året — og etter vår erfaring en dags arbeid, mens den i et egenbygd system er en spesifikasjon, timer og en test, og til 50 € i timen er den den første funksjonen du kommer til å spørre om virkelig er nødvendig; et varefelt eller et nytt filter i administrasjonen står ikke på den listen, for det gir rammeverket. Mangelen på et økosystem er ingen engangskostnad, men en varig høyere terskel for alt du senere får lyst til å prøve, og for en butikk som eksperimenterer mye, kan den veie tyngre enn lisensregningen — og det er nettopp derfor vi ikke kaller lisensregningen hovedargumentet.

Den andre er avhengigheten av ett team, og på den svarer strukturen framfor en påstand: i et bestilt byggeoppdrag er koden din fra første dag, vi skriver den i standard Laravel-struktur uten eksotiske grep, kritisk logikk har tester, og det følger med en dokumentert README og CI, slik at systemet kan overtas av noen andre. Laravel-utviklere er lette å finne i Latvia, og derfor ender vårt eget svar på spørsmålet om hvorfor Laravel med setningen om at du ikke blir avhengig av ett team, heller ikke av oss — det opphever ikke risikoen, men gjør den flyttbar.

Den tredje er PCI DSS, og den taler mot oss. Utgaven av SAQ A som ble publisert i januar 2025 og trådte i kraft 31. mars 2025, fjernet kravene 6.4.3 og 11.6.1 — inventar over skriptene, begrunnelsen for dem og overvåkingen av endringer — og kravet 12.3.1 om målrettet risikoanalyse, for brukersteder hvis betalingsside leveres i sin helhet og direkte av en tjenesteleverandør som oppfyller PCI DSS, og som selv har bekreftet at nettstedet ikke er utsatt for skriptbaserte angrep, samtidig som den påpeker at selve PCI DSS-kravene ikke bortfaller med dette. Denne lettelsen beskriver en liten WooCommerce-butikk med en betalingsside fra banken langt mer presist enn et kassesteg vi tegner i vår egen kode, og ved siden av den står et annet like ubehagelig faktum: marssårbarheten ble funnet og rettet av noen andre, mens den i et system vi selv har skrevet, rettes av vårt eget team, så vedlikehold er der en linje i avtalen og ingen antakelse.

Våre avhengigheter er ikke en annen art

Filament er nøyaktig den samme tredjepartsavhengigheten som utvidelsene det nettopp var snakk om, og forskjellen mellom dem er en forskjell i grad og plassering, ikke i prinsipp. Det er én MIT-lisensiert avhengighet i utviklingslaget, koden ligger i repositoriet vårt og lar seg forgrene, og den sitter ikke i veien kjøperen går til kassen, for den tegner et administrasjonspanel framfor å ta imot en betaling.

Stanset prosjektet i morgen, ville butikken fortsatt ta imot ordrer, og det som ble utdatert, ville være den delen dine egne ansatte ser, ikke den som tar imot penger fra kjøperen. Filament publiserer dessuten en tabell over versjonsstøtte med konkrete datoer: tredje versjon kom i august 2023 og får sikkerhetsrettinger til 1. januar 2028, som er et lengre vindu enn Laravel gir sine egne versjoner.

Filament er likevel ingen førstepartspakke fra Laravel, for Laravel nevner den ikke i sin egen pakkeliste, og bak prosjektet står ikke et selskap med et regnskap, men et team rundt én vedlikeholder: i hans navn ligger det rundt 17 000 endringer i repositoriet, mot rundt 2 400 for den neste bidragsyteren, og finansieringen kommer fra sponsorer på GitHub og betalt rådgivning. Utgivelsestakten er heller ikke mild: fjerde versjon kom i august 2025, femte allerede i januar 2026, to dager etter Livewire 4, som er enda en tredjepartsavhengighet under den. Og setningen «om nødvendig forgrener vi den» er billig å skrive og dyr å gjennomføre.

Vi tilbyr ingen butikk uten avhengigheter til tredjeparter, for en slik finnes verken hos oss eller hos noen andre; vi tilbyr færre av dem, en lisens som lar deg beholde og vedlikeholde koden selv, og en tydelig grense mellom det som stanser pengestrømmen når det svikter, og det som ødelegger arbeidsdagen til en ansatt. Synes du ikke den forskjellen er stor nok, er det en fullt ut berettiget innvending — og da bygger vi det ferdige verktøyet for deg, for det er den samme basisversjonen eller den samme Pro-versjonen til den samme prisen. Ingen av de to svarene gjør oss til feil partner.

Slik gjør vi dette valget i praksis

Sammen med plattformen kjøper du svaret på ett spørsmål — hvem som får endre reglene dine for pris og ordre, og etter hvilken plan — og på egen kode er svaret «du, i neste sprint», mens det på en utvidelse fra en annen leverandør er «når leverandøren tar det med i en utgivelse, hvis han tar det med». Derfor spør vi ikke om omsetning i kartleggingssamtalen, men om hvor mange prisnivåer du faktisk har, og om én kunde noen gang ser en annen pris enn en annen — der går grensen mellom de to prisfeltene WooCommerce gir selv, og en pristabell noen må vedlikeholde.

Så spør vi om beholdningen bor på mer enn ett sted, for lager pluss butikkhylle er allerede to steder, og to steder betyr at noen må bestemme hvilket av dem som gjelder som sannheten. De to neste spørsmålene avgjør som regel alt: blir en ordre til en ordre med én gang, eller trenger den først en godkjenning — fra innkjøpsavdelingen hos kunden, fra salgssjefen din eller fra en kredittgrense — og ville prosessen holdt også om katalogen ble dobbelt så stor?

Er svaret om godkjenning «ja», står du der markedet for ferdige utvidelser er svakest: overvåking av kredittgrenser og blokkering av ordrer over grensen ligger verken i kjernen eller i de mest utbredte B2B-pakkene, og det loves bare av noen få spesialiserte oppføringer, for eksempel QuarkCode B2B Commerce Suite. Hvor mye av prosessen du er villig til å legge om etter verktøyet — det er spørsmålet som blir stående, og uklare krav er den dyreste feilen i hele bestillingen, noe vi har skrevet om i en egen artikkel.

Passer svarene inn i et ferdig verktøy, ta det ferdige verktøyet, for det blir billigere, og bygge det for deg gjør vi. Passer én eller to av dem ikke inn, er du sannsynligvis på den midterste veien, og i prislisten svarer den samme Pro-versjonen til 9 500 € på WooCommerce til den — den samme prisen som på Laravel, for det er arbeidet som koster og ikke plattformen. Passer tre eller flere ikke inn, og særlig om godkjenningssteget eller kredittgrensen er blant dem, handler samtalen ikke lenger om plattform, men om hvor stor del av prosessen som bor i kode vi kan endre uten å avklare det med en annen leverandør.

Tre startpunkter og hva hvert av dem koster

I praksis selger vi tre startpunkter, og hvert av dem har en pris som lar seg regne ut: det første er å starte med katalog, betalinger og frakt, gå i drift, og legge til B2B-priser, rabattlogikk og lagerintegrasjoner når de første virkelige ordrene er synlige — i svarene våre kaller vi det det valget som vanligvis er riktig. Det andre er å flytte en eksisterende butikk, og det er et prosjekt og ingen bryter: URL-strukturen beholder vi, men datamodellene faller ikke sammen én til én, og hver utvidelse som har lagret sine egne felter, må vurderes for seg. I Pro-versjonen og i leie er migreringen inkludert; i basisversjonen finnes den ikke, og da estimerer vi den for seg etter omfang, for det er datamengden og antallet felter som avgjør prisen.

Det tredje er leie: en Laravel-butikk sammen med drift hos oss fra 130 € i måneden pluss en engangsbetaling på 600 € for oppsettet, og i prislisten er innholdet det samme som i Pro-versjonen — lagermodul, støtte for flere språk, B2B-prisnivåer, rabattsystem og migrering av innhold — bare med drift, oppdateringer og vedlikehold i tillegg; tilgjengelig er den bare med Laravel, for en WooCommerce-butikk kan du ikke leie hos oss. Plattformvalget avgjør i seg selv noen få konkrete ting som arbeidet ikke jevner ut: denne leielinjen, de gratis automatiske rettelsene til kjernen, terskelen i økosystemet og hvem som må si ja før neste endring hos deg går i produksjon. Alt det andre er arbeid.

Leien starter fra 130 € i måneden, som over fem år er fra 7 800 €, pluss 600 € for oppsettet — fra 8 400 € — og i den ligger drift, oppdateringer og vedlikehold. Pro-versjonen koster 9 500 € én gang, og driften kommer i tillegg til den: administrert serverdrift hos oss starter fra 45 € i måneden, altså fra 2 700 € over fem år, til sammen fra 12 200 €, og oppdateringer av selve applikasjonen ligger ennå ikke inne der. Begge tallene er startpriser, ikke sluttsummer, og sammenlignbare er de fordi innholdet i de to i prislisten er ett og det samme. I leie betaler du for bruken sammen med driften, i et byggeoppdrag betaler du for systemet med én gang, og sammenligner du de to startprisene, starter leien lavere i et femårsvindu. Hvor hver av dem ender, avgjøres av omfanget, så begge estimerer vi for prosjektet framfor å lese dem av prislisten.

Videre går arbeidet i sprinter på to uker med en demo etter hver av dem; betalinger, budtjenester og regnskap kobler vi til og kontrollerer før lansering; produkter, kunder og ordrehistorikk flytter vi over og beholder URL-strukturen. For større og mer spesielle oppgaver jobber vi etter tid og materialer med et ukentlig tak, for fast pris betyr der som regel enten et påslag for risiko eller en krangel om omfanget, og timesatsen i prislisten er 50 €. Hele veien tar 8–32 uker. Få et prosjektestimat og en anbefaling om teknologi — svar på de samme spørsmålene til oss, så sier vi hvilken av de tre veiene som koster minst i ditt tilfelle.