WooCommerce eller Laravel: att välja e-handelsplattform

Plattformen avgörs inte av funktionslistan för dag ett — lager, B2B-priser och flera språk bygger vi på båda. Det som avgör är vem som bestämmer över din nästa ändring, och vad den kostar.

En teknikfråga vars svar inte är en funktionslista

Samtalet börjar nästan alltid likadant: kunden har runt sjuhundra produkter, tre prisnivåer för sina återförsäljare, där var och en bara ser sitt eget pris när han loggar in, och en bokföring i Visma Horizon där saldot är sanningen och butiken bara speglar den. Frågan han ställer handlar om att välja e-handelsplattform — WooCommerce eller Laravel? Svaret han väntar sig är en tabell i två kolumner där något finns på den ena sidan och saknas på den andra, en tabell vi inte har och som ingen har som faktiskt bygger på båda plattformarna.

Lagermodul med synkronisering av saldon i realtid, B2B-prisnivåer, rabattsystem, stöd för flera språk och migrering av innehåll bygger vi på båda plattformarna, och priset i vår prislista beror inte på plattformen: en webbutik kostar 4 500 € i basversion och 9 500 € i Pro-version, lika mycket på WooCommerce som på Laravel. Det är just de fem raderna som skiljer basversionen från Pro, inte det som ligger under; administrationsgränssnittet står namngivet i prislistan redan i basversionen, medan handel i flera valutor inte ingår i någon av de två versionerna och avtalas separat — återigen på vilken som helst av de två plattformarna.

Av det följer något handfast: en plattform som säljs in till dig med en funktionslista för dag ett säljs på något du kan få båda vägarna, och en jämförelse som börjar i en sådan lista är slut innan den har börjat. Den intressanta frågan ligger ett steg längre bort — vem bestämmer vad din butik ska kunna göra nästa år, och hur länge det beslutet står i kö hos någon annan.

Under det första året gör båda plattformarna det du har betalat för, eftersom någon i båda fallen just har byggt det; under det andra året ändras processen — grossistledet tillkommer, ett andra lager, en skyldighet att skicka maskinläsbara fakturor eller helt enkelt en annan rabattordning — och från och med då kostar de två vägarna olika. På en annan tillverkares tillägg är varje senare ändring som en ombyggnad i en hyrd lokal: reglerna för din process bor i någon annans inställningsfönster och flyttar sig i takt med någon annans releaseschema. På egen kod är samma sak ett arbete som har en taxa i prislistan, och det enda som behöver stämmas av är hur det prioriteras mot resten av kölistan.

Det WooCommerce gör bra

WooCommerce sätter vi själva in i kundernas butiker varje gång processen passar, och det är det mest använda e-handelssystemet i W3Techs mätningar: den 6 augusti 2026 låg det på 8,2 % av alla webbplatser och utgjorde 48,5 % av alla e-handelssystem i de mätningarna. Viktigare än siffran i sig är vad den räknas på — en andel av de undersökta systemen, inte av världens butiker och definitivt inte av e-handelns omsättning — och bakom den står WordPress med 41,2 % av alla webbplatser.

Tilläggskatalogen på WordPress.org visade samma dag WooCommerce 11.0.0, uppdaterat den 4 augusti, med uppskattningen ”7+ million active installations”, och att läsa den försiktigt är tillverkarens eget råd: användningsstatistiken är avstängd som standard i den kärna man laddar ner från WordPress.org, så ingen — inte heller Automattic — vet hur många butiker som faktiskt handlar, och talet är en övre gräns för antalet installationer, inte ett antal handlare.

Tillverkarens prissida beskriver WooCommerce som en plattform med öppen källkod, utan plattformsavgift och med 0 % intäktsdelning: du betalar inte för att sälja, och du betalar inte för att omsättningen växer. Katalogen, orderlistan och rabattinställningarna ser dessutom ut precis som resten av WordPress-administrationen, som ditt team med största sannolikhet redan kan använda utan utbildning.

Det starkaste argumentet för WooCommerce försvinner nästan alltid i konkurrenternas jämförelser, och det är den automatiska säkerhetsrättningen: den 2 mars 2026 offentliggjordes en sårbarhet i Store API som berörde versionerna 5.4 till 10.5.2 och lät en förfalskad förfrågan skapa ett administratörskonto; felet hittades av någon annan än butiksägarna; rättningen backportades över 52 berörda versioner; och samma dag från klockan 14.00 UTC började den spridas automatiskt till de butiker som har automatiska uppdateringar påslagna, utan faktura. Just den inställningen är inte självklar, och det är den en människa konfigurerar och håller ögonen på i ett förvaltningsavtal; hur WordPress-webbplatser hackas och vad du gör om det redan har hänt beskriver vi i vår artikel om en hackad WordPress-webbplats.

Rekommendationen har därför inte ändrats, och den står också på vår tjänstesida: för en mycket liten webbutik med standardprocesser — WooCommerce. Hundra produkter med ett pris, ett lager och ett betalsätt får ingenting av en skräddarsydd plattform som är värt mellanskillnaden, och att sälja det dyrare alternativet när det billigare gör samma sak ger en missnöjd kund till och inte en enda rekommendation.

Fungerar WooCommerce för betalningar och frakt i Lettland?

Ja. Frakt och betalningar i Lettland är inte den punkt där en färdig webbutik tar slut, och varningar om motsatsen saknar oftast grund: Omniva publicerar färdiga moduler för sex plattformar — WooCommerce, Shopify, PrestaShop, OpenCart, Magento och Mozello — och bredvid dem ett dokumenterat OMX-gränssnitt som bär försändelsedata, etiketter, spårningshändelser och listor över paketautomater i alla tre baltiska länderna, men förutsättningen för det är ett företagsavtal, inte en programmerare. DPD Baltics underhåller själv sitt WooCommerce-tillägg i katalogen på WordPress.org — version 1.2.91, mer än 2 000 aktiva installationer — och det täcker paketautomater, bud, etiketter, manifest och efterkrav; på samma ställe syns också det offentliga betyget 2,7 av 5 och användarrecensioner som klagar på konflikter med andra frakttillägg.

MakeCommerce, som drivs av Maksekeskus AS, ger med ett enda avtal banklänkar till Swedbank, SEB, Citadele och Luminor, kortbetalningar, Apple Pay och Google Pay, och strax intill frakt med Omniva, DPD, Venipak och Unisend; deras WooCommerce-tillägg har mer än 3 000 aktiva installationer och uppdaterades senast i juni 2026. Klix by Citadele, som banken själv underhåller, publicerar officiella tillägg för sex plattformar, WooCommerce från version 3.5 inräknat, så att påstå att en färdig butik inte kan ta emot pengar i Lettland vore helt enkelt osant.

Baksidan av samma sak är att de här leverantörerna inte är tilläggens egendom: MakeCommerce, Omniva och DPD publicerar gränssnitt och inte bara moduler, och i vår prislista ingår inkoppling av betalningar — MakeCommerce och Stripe — redan i basversionen för 4 500 €, oavsett vilken plattform som ligger under. Integrationer mot Horizon, Jumis, Latvijas Pasts, Omniva och DPD är en rad i butikstjänsten och inget påslag för Laravel, och med frakt-API:erna hos Omniva, Latvijas Pasts, DPD och Venipak arbetar vi regelbundet, så det lettiska frakt- och betalningsskiktet är inget argument vare sig för eller emot någon av de tre vägarna.

Var arbetet i Lettland faktiskt ligger

Komplikationen ligger i baksystemen: Visma Horizon, Jumis och Directo publicerar var och en sitt eget REST-gränssnitt — Directos dokumentation beskriver auktorisering med huvudet X-Directo-Key och åtkomst till produkter, ordrar, kunder, fakturor, saldon och prisformler — men ett publicerat gränssnitt är ännu ingen integration: någon måste para ihop det butiken kallar produkt med det bokföringen kallar artikelnummer och avgöra vilket av de två systemen som håller sanningen om saldot i just den sekund då köparen trycker på knappen. Två ställen där saldot bor är som två klockor ombord på ett fartyg: den som har två vet aldrig vad klockan är förrän någon har ställt dem efter varandra, och det arbetet är skräddarsytt på vilken plattform som helst — med Horizon och Jumis gör vi det regelbundet.

Ovanpå det ligger ett daterat juridiskt faktum med en hake i: en strukturerad elektronisk faktura är obligatorisk till statliga myndigheter sedan den 1 januari 2025, medan den blir obligatorisk i handeln mellan företag den 1 januari 2028 — i den lettiska bokföringslagens ordning och i formatet LVS EN 16931-1:2017. Haken är datumet: ursprungligen var 2026 satt, så pressartiklar från 2024 nämner fortfarande fel tidpunkt, och det bör kontrolleras på finansministeriets sida om den strukturerade elektroniska fakturan snarare än i nyheterna, eftersom en butik som säljer till företag kommer att behöva få vägen för en maskinläsbar faktura byggd på vilken plattform som helst, oavsett vilket år som till slut visar sig vara det rätta.

Välja e-handelsplattform: vilken av de tre vägarna är din?

Jämförelser som lägger fram det här valet som två knappar hoppar över den väg vi säljer allra oftast, för vägarna är i själva verket tre; de skiljer sig åt i hur stor del av din process som bor i kod du själv kan ändra, och valet mellan dem är ett val om var dina pris- och orderregler i fortsättningen ska ligga — i ett inställningsfönster, i ditt eget kodförråd eller mitt emellan.

Den första vägen är ett färdigt verktyg med färdiga tillägg — WooCommerce eller OpenCart, som vi också erbjuder befintliga butiker. I WooCommerces kärna finns två prisfält, ordinarie pris och kampanjpris, ett saldotal per produkt eller variant och tre betalsätt, varav inget tar emot pengar online, och därför är pris för en viss kundgrupp, mängdrabatter, offert som blir order, momsbefrielse och saldon i flera lager ett separat köp från en separat tillverkare med ett separat årsabonnemang. Vägen är den snabbaste och mycket ofta den rätta, och priset för den är inte pengar utan att reglerna för din process i fortsättningen bor i en annan tillverkares inställningsfönster.

Den andra vägen syns nästan aldrig i jämförelserna, trots att det är den vi säljer oftast: ett färdigt verktyg med vår egen kod ovanpå. WooCommerce är öppen PHP-kod, så en pristabell för återförsäljare, en kreditkontroll eller en saldoreservation kan skrivas bredvid kärnan i stället för att köpas färdig, och licenser finns det inga — det finns timmar — till priset att den koden förblir bunden till WooCommerces uppdateringstakt och till hur den plattformen lagrar ordrar. En betydande del av det som i vår prislista heter Pro-version för 9 500 € består av just det arbetet, och här ligger merparten av våra egna butiker.

Den tredje vägen är vår egen plattform, där katalog, varukorg, kassa och prislogik skrivs från tom yta runt din process; det är den dyraste starten och den enda där ingen annan tillverkare har gjort ett antagande om vad en produkt är och när en order blir en order. Inuti den tredje vägen finns en förgrening: Bagisto och Lunar är MIT-licensierade handelspaket för Laravel — den 6 augusti 2026 hade de 27 943 respektive 3 588 stjärnor på GitHub — som ger katalog och varukorg färdigskrivna, i utbyte mot ännu ett externt beroende vars takt inte ligger i dina händer. Den vägen går vi inte.

Vad kostar årslicenserna för WooCommerce-tillägg?

För en butik med sjuhundra produkter och tre återförsäljarnivåer kostade den första vägen 270 € om året den 6 augusti 2026, för två offentliga priser plus ett okänt tredje. Dynamic Pricing ger mängd- och rollrabatter för 113 € om året; B2B for WooCommerce, utvecklat av Addify, ger rollpriser, stegpriser, offert som blir order, momsbefrielse och betal- och fraktsätt begränsade per roll för 157 € om året; men för saldon i flera lager finns ingenting förberett i kärnan, så till det kommer ett tredje betaltillägg, till exempel Addify Multi Inventory Management, som tillverkaren inte sätter något offentligt årspris på.

De 270 € om året är lite mer än fem utvecklingstimmar, eftersom en utvecklingstimme i vår prislista kostar 50 €, och för funktioner som har en tillverkare, en dokumentation och uppdateringar är det billigt. Ett pris du inte känner till innan samtalet är ändå ingen rad i en kalkyl: lagertillägget lyfter talet, och med hur mycket beror på den offert som når dig när du har uppgett antalet lager och ordervolymen.

En annan butik har andra rader: för den som säljer abonnemang, bokningar och medlemsnivåer kostar WooCommerce Subscriptions 245 € om året till samma marknadsplatspriser, Bookings 218 €, Memberships 175 €, AutomateWoo 140 € och Product Add-Ons 70 € — tillsammans 848 € om året. På fem år, om priserna står stilla, blir det 4 240 €: nästan hela priset för en butik i basversion, som i vår prislista är 4 500 €, och nästan halva Pro-versionen för 9 500 €. Den raden skrivs inte av, för den gäller en webbplats och ett år och betalas om från början varje år.

Samma tal baklänges är nästan 85 utvecklingstimmar till 50 € i timmen, och det är timmar som blir kvar i din kod och i din ägo i stället för att förnyas på nästa års faktura. Den konkreta räkningen på 848 € är dessutom räkningen för en butik med abonnemang, bokningar och medlemskap och ingen norm — någon norm finns inte här, och varje butik får summera raden ur sin egen process. Licensraden kommer också ovanpå bygget och inte i stället för det: i båda fallen har någon först byggt butiken, och bara i det ena fallet kommer det en ny faktura för det byggda i januari därpå.

Vad fakturan gör när den inte betalas

Om abonnemanget inte förnyas säger dokumentationen på WooCommerce.com det rakt ut: ”the extension or theme remains installed on your site but will no longer receive updates” — tillägget blir kvar installerat, butiken fortsätter att fungera, och det enda som försvinner är uppdateringarna. Följden av en licens som inte förnyats är därför inget driftstopp som märks samma dag, utan en olagad kodbit som fortfarande hanterar betalningar; ett abonnemang täcker dessutom en produktionswebbplats och en utvecklingswebbplats, och underdomäner räknas för sig.

En rad beter sig annorlunda och beter sig likadant på båda sidor: en bokföringskoppling är sällan en licens utan ett abonnemang som stiger med antalet ordrar — MyWorks Xero Sync börjar på en gratisnivå på WooCommerces marknadsplats, och därefter sätts priset av volymen, så den raden växer precis när butiken växer. En skräddarsydd plattform tar inte bort den, men ändrar vem som underhåller kopplingen, och i vårt fall är det timmar; raderna ska inte heller blåsas upp: flera språk är inte automatiskt 99 € om året för WPML Multilingual CMS, eftersom Polylang står bredvid WPML, medan den billigare WPML-licensen Multilingual Blog för 39 € inte stöder e-handel, så för en butik finns valet mellan 39 € och 99 € inte.

Varför skillnaden dyker upp under det andra året

Att kostnaden för ändringar är en verklig och inte en teoretisk utgift visar plattformen själv: sedan 2023 har WooCommerce plockat bort två bärande detaljer, dragit tillbaka en betafunktion och ändrat en standardinställning. Det äldre REST-API:et (Legacy REST API) försvann ur kärnan den 11 juni 2024 i och med version 9.0, efter att ha varit utfasat ända sedan version 2.6 år 2016; den inbyggda betalmodulen PayPal Standard togs bort i version 8.9 i maj 2024; betaversionen av produktredigeraren togs bort i version 11.0, som dök upp i katalogen den 4 augusti; medan orderlagring i HPOS blev standard för nya installationer i version 8.2 i oktober 2023 och inte rör befintliga butiker förrän någon migrerar dem.

Mot den bakgrunden finns det 37 inlägg i kategorin Advisories på WooCommerces utvecklarblogg under de tolv månaderna fram till den 5 augusti 2026 — ungefär tre i månaden — och vart och ett av dem måste stämmas av mot varje tillägg som är installerat i butiken, vilket en butik med fyra tillägg klarar utan ansträngning men en butik med tjugo inte längre gör. Högen växer dessutom inte fram på en dag: tilläggen kommer ett i taget, vart och ett för sig är ett fullt förnuftigt beslut, och multiplikationen av kombinationer som ska kontrolleras sker tyst.

Tio tillägg är inte tio detaljer utan tio avtal som vart och ett kan ta slut för sig, och ägaren byts även när det inte är något fel på koden. Den 31 oktober 2025 stängde recensionstjänsten Judge.me av sin WooCommerce-integration tillsammans med Square, Squarespace, BigCommerce, Duda och PrestaShop: data gick att komma åt fram till den 19 november, därefter togs åtkomsten bort för gott, och recensionsvideorna ingick inte i exporten, så en marknadsföringstillgång som byggts upp under år blev delvis kvar på andra sidan dörren. De lugnare fallen är mer övertygande: 2019 köpte Automattic upp Prospress, som låg bakom WooCommerce Subscriptions och AutomateWoo, 2020 köpte GoDaddy upp SkyVerge, vars mer än sextio tillägg användes av över 100 000 handlare, och båda affärerna slutade, så vitt det går att bedöma av det som är offentligt känt, väl för handlarna. Frågan gäller inte skadan, utan att ägaren till delarna i din butik kan bytas ut utan att du är med.

Hur stor den risken faktiskt är

Skalan sätter den i proportion, och siffrorna här är våra egna: i en genomräkning den 6 augusti 2026 gav tilläggs-API:et på WordPress.org 7 764 tillägg med etiketten ”woocommerce”, varav 23,1 % inte har uppdaterats på två år eller mer, men i samma genomräkning sitter 10 809 800 aktiva installationer på tillägg som uppdaterats under det senaste halvåret och bara 208 790 på sådana som ingen rört på mer än tre år. Tillägg med 10 000 installationer eller fler som stått utan uppdatering i två år är i samma genomräkning exakt sex.

Det övergivna tillägget är nästan aldrig det populära som alla känner till: risken sitter i den enda smala modul som just din process kräver — i B2B-prisnivåerna, i lagerkopplingen, i etikettgeneratorn för en bestämd fraktfirma — och ju mer din process skiljer sig från genomsnittet, desto närmare är du den del av katalogen där den senaste uppdateringen är från förrförra året. Den raden går att krympa utan att bygga om något: i ett förvaltningsavtal gör vi det — vi minskar antalet tillägg, konfigurerar uppdateringarna och håller övervakningen igång — och en ombyggnad är svaret först när problemet inte längre är förvaltningen, utan att processen inte finns nedskriven någonstans.

Där WooCommerces dataform börjar klämma

Det andra stället där år två kostar är dataformen, och först den sida av den där argumentet inte längre stämmer: ordrar i nya installationer ligger sedan version 8.2 i fyra egna tabeller, och företagets egen mätning från mars 2023 visar att den nya lagringen snabbar upp orderoperationerna i stället för att bromsa dem. Det som klämmer är produktsidan, och bäst har den beskrivits av WooCommerces egna utvecklare, som den 1 april 2019 förklarade prestandaförbättringarna i version 3.6: produkter och varianter går genom inläggssystemet i WordPress, där post meta är oerhört flexibelt men ”not that efficient when we need to sort or filter by many meta values at once” — inte särskilt effektivt när man samtidigt behöver sortera eller filtrera på många metavärden. Svaret i samma release var wc_product_meta_lookup, en denormaliserad hjälptabell med SKU, pris och lagerstatus bredvid post meta och inte i stället för den, så grundformen förblev som den var.

Motsvarande arbete på produktsidan, woocommerce-product-tables-feature-plugin, har sedan den 16 oktober 2017 bara levt på GitHub och är inte övergivet — de senaste ändringarna är från den 31 juli 2026 — men bedöms fortfarande inte som tillräckligt stabilt för katalogen på WordPress.org. Bredvid står wp_options, vars autoload-fält som standard saknar index, vars autoinlästa data läses vid varje sidladdning, som WooCommerce själv rekommenderar att hålla under ungefär 500 rader och vars tillväxt orsakas just av utökningar, tillägg och teman — samma hög som det var tal om tidigare, bara betraktad från databassidan.

Vad Laravel ger en butik som ett färdigt verktyg inte ger

Laravel är ingen butik och låtsas inte vara det: det ger namngivna, dokumenterade och MIT-licensierade delar som någon bygger en butik av, så frågan som är värd pengar här är inte ”är ramverket bra” utan ”vilka delar av din process blir äntligen dina egna tabeller och dina egna jobb”. I en handlares butik är svaret oftast fyra rader — pristabellen för återförsäljare, kreditgränsen, saldoreservationen och synkroniseringen mot bokföringen — och det är precis dem du i ett färdigt verktyg köper av fyra olika tillverkare och därefter får att fungera ihop.

Innan dess är det ärligt att säga vad den här vägen inte ger, för ingen av de fyra raderna ger Laravel heller: ramverkets officiella startpaket ger autentisering och ingenting mer — ingen katalog, ingen varukorg, inget kassasteg, inget lager — och det enda handelspaketet som följer med är Cashier, som sköter abonnemangsfakturor på Stripes eller Paddles sida och förutsätter att produkterna med sina priser redan är beskrivna i betaltjänstens panel. Det Laravel ger är en form där de fyra raderna är billiga att skriva och ännu billigare att ändra senare.

Köer, transaktioner och din egen form på databasen

Den första delen är köerna: ett API över flera motorer — Redis, databas, Amazon SQS, Beanstalkd — som låter orderhanteringen, ERP-synkroniseringen och e-posten lämna själva anropet, så att köparen inte längre står och väntar på att bokföringssystemet ska svara. Dokumentationen namnger också det som avgör en verklig implementation: kedjor och batchar av jobb, unika jobb som kön inte kör två gånger, återförsök och ett lager för misslyckade jobb som går att köra om. En order som körts två gånger är en faktura någon får makulera efteråt, och en kund som märker det före dig.

Horizon visar köernas genomströmning, körtider och fel, låter konfigurationen av workers beskrivas i kod och varnar när en kö väntar för länge, men det kräver Redis och fungerar för närvarande inte med Redis Cluster, alltså är det en egen post på hostingfakturan och inget gratis tillbehör. Transaktionerna i sin tur är vad meningen ”ordern och lagerrörelsen sker båda eller ingen” betyder i praktiken: DB::transaction återställer ändringarna själv vid ett fel och låter dem göras om ifall databasen kör fast i ett dödläge.

Laravels dokumentation kallar migreringarna för versionshantering av databasen, och i praktiken betyder det att du projekterar tabeller, index och främmande nycklar runt din egen pris- och lagerlogik i stället för runt det någon annan en gång bestämde om begreppet produkt. Sökning och abonnemangsfakturor förblir dessutom ett val och ingen obligatorisk månadsrad: Scout indexerar på plats i databasen med fulltextindex i MySQL eller PostgreSQL utan någon extern tjänst, medan Stripe-sidan sköts av Cashier om det över huvud taget finns abonnemang i butiken.

Pristabellen, kreditgränsen och reservationen i kod

Hur det ser ut konkret visar den första av de fyra raderna bäst: en pristabell för återförsäljare är på egen kod en migrering med fyra kolumner — kundgrupp, produkt, mängdtröskel och pris — och ett unikt index över de tre första, så priset för en bestämd köpare hittas med en enda fråga och en enda join i stället för med en sökning bland metavärden, och en ny prisnivå är en ny rad i tabellen i stället för en ny inställning i en annan tillverkares fönster. När det efter ett år kommer en fjärde nivå med en annan avrundningsordning ändras ett ställe och ett test, och båda ligger i ditt kodförråd.

Kreditgränsen och saldoreservationen är samma tanke ett steg längre, för också där hänger allt på en tabell och en transaktion: summan av obetalda fakturor är en kolumn hos kunden, och kontrollen sker i samma transaktion som ordern skapas i, så två ordrar som skickas in samtidigt kan inte båda slinka under gränsen, medan transaktionen gör om sig själv vid ett dödläge. Reservationen är i sin tur en rad med en giltighetstid som uppstår tillsammans med ordern och försvinner med ett schemalagt bakgrundsjobb om ordern inte betalas, så lagersaldot är inte längre ett tal som två köpare kan tömma samtidigt.

Synkroniseringen mot bokföringen är ett köjobb märkt som unikt, så ett återförsök skriver aldrig ut fakturan två gånger, och när Horizon på morgonen visar att det var avbrott i bokföringsänden under natten låter lagret för misslyckade jobb dem köras om i tur och ordning i stället för att skrivas in för hand. Var och en av de fyra raderna går att få även i ett färdigt verktyg, bara som en tillverkares inställningsfönster vars regler du inte ser, som måste kontrolleras på nytt efter varje uppdatering och som inte flyttar med till någon annan plattform.

Två arbeten som redan är i drift

Hur det ser ut i ett projekt i stället för i dokumentationen syns i våra egna Laravel-arbeten. I LIDO:s plattform för matbeställningar avgörs priset inte av produkten utan av adressen: geolokaliseringen bestämmer leveranszon, avstånd och avgift, var och en av de tretton restaurangerna har sitt eget sortiment, och bredvid butiken går ett separat system för processautomatisering dit alla ordrar kommer in och därifrån de fördelas ut på restauranger och kockar — med integrationer mot mer än tio andra system, däribland Wolt, QWQER och RKeeper. I webbutiken för Riga Lashes, byggd på Laravel, finns variantpriser, kundkonton, önskelista och prislistan för studions tjänster, och bakom dem varulagret, integrationerna mot budfirmorna och betalningarna, där processen är automatiserad ända fram till packningen. I båda fallen hade den avgörande delen behövt skrivas även på ett färdigt verktyg, bara inuti en annan tillverkares pris- och orderform, och det är just den skillnaden som blir kvar: på egen kod är det arbetet ett enda kodförråd utan ett separat abonnemang per förmåga, och det behöver inte kontrolleras på nytt efter varje plattformsuppdatering. Laravel har vi skrivit sedan 2013, och på det körs merparten av våra skräddarsydda system, portaler för offentlig sektor och B2B-plattformar.

Vart pengarna tar vägen när de inte går till licenser är en konkret fråga, och svaret är lika konkret: de nästan 85 timmar som licensraden på 848 € om året kostar på fem år är på egen kod exakt den här pristabellen, den här kreditgränsen, den här reservationen och den här synkroniseringen, skrivna runt din process. De blir kvar i ditt kodförråd även om vi någon gång slutar vara din partner: i ett beställt bygge är koden din från första dagen, och det står också på vår tjänstesida för Laravel.

Filament: administrationsgränssnittet som ingen skriver från noll

Invändningen mot ett egenbyggt system är att allt måste skrivas från noll, och den del av den som gäller administrationsgränssnittet tar Filament bort — ett gränssnittsramverk med öppen källkod för Laravel-applikationer. Resurser genererar CRUD-skärmar för Eloquent-modeller, tabellbyggaren ger filtrering, sortering och sidnumrering, formulärkomponenterna kommer med inbyggd validering, medan Filament läser behörigheterna direkt ur modellpolicyerna i Laravel, så rollkontrollerna behöver inte skrivas en gång till. Relationshanterare, widgetar för instrumentpanelen och notiser ligger i samma paket; stöd för flera klienter (multi-tenancy) likaså, om än med Filaments egen varning om att det är en verktygslåda och ingen garanti och att den som implementerar ansvarar för att hålla klienternas data åtskilda; hela skiktet är MIT-licensierat precis som Laravel självt, så där finns inte en enda licensavgift.

Det viktigaste är ändå inte vad ramverket ritar upp, utan vart de frigjorda pengarna tar vägen: skärmarna för att redigera produkter, ordertabellerna, filtren och behörighetskontrollerna är den del av utvecklingen som köparen aldrig ser och som beställaren ändå betalar full taxa för, och när ett ramverk ger dem går budgeten till pris-, order- och lagerlogiken, som var skälet till att skräddarsydd utveckling valdes från början. Exemplet finns där du läser det här: den här webbplatsen körs på Laravel 13 och Filament 5, och allt redaktionellt arbete på tolv språk sker i ett gränssnitt som vi konfigurerade i stället för att skriva från noll.

Var ramverket slutar och butiken börjar

Filament är ingen butik, och den gränsen är värd att dra tydligt: ramverket ger ett administrationsgränssnitt — skärmar, tabeller, formulär och behörighetskontroller — men vet ingenting om vad som finns i tabellerna eller enligt vilka regler det hamnar där. Produktkatalog med varianter och attribut, varukorg, kassasteg, prisregler med kundnivåer och mängdrabatter, orderns livscykel från skapande till retur och reservation av saldon i lagret — inget av det ingår i paketet Laravel och Filament. Filament är som en färdigt inredd verkstad med hyllor, arbetsbänkar och ljus; vad som ska tillverkas där följer inte med.

Hur bokstavligt det ska tas visar dokumentationen själv, där modellerna Order och Payment bara dyker upp som exempel utvecklaren skriver på egen hand, eftersom några sådana klasser helt enkelt inte finns i ramverket. Det är ingen brist i ramverket utan en arbetsfördelning: Filament lovar ett administrationsgränssnitt och ingenting annat, precis som Laravel lovar ett ramverk och ingen färdig applikation. I praktiken betyder det att Filament kortar av administrationsarbetet men inte kortar av något i den del som var skälet till att skräddarsydd utveckling valdes från början.

Därför kommer butikens basversion för 4 500 € i vår prislista utan lagermodul, stöd för flera språk, B2B-prisnivåer, rabattsystem och migrering av innehåll, medan Pro-versionen för 9 500 € kommer med allt det. Skillnaden är inget påslag för modernare teknik utan priset för det någon måste skriva, och just därför är den lika stor på båda plattformarna. Ett Laravel-system med fast omfattning från 8 000 € är i prislistan redan en annan rad och en annan produkt: det är ingen butik utan ett system där hela processen byggs upp från tom yta.

Det vi inte lovar: där egenbyggt kostar mer

En egenbyggd butik är fri från årslicenser för tillägg, inte från förvaltning, och det är två helt olika saker. Laravel ger varje release 18 månaders felrättningar och två års säkerhetsrättningar, släpper en ny huvudversion en gång om året och har ingen nivå med långtidsstöd, så datumen är konkreta: Laravel 13 kom den 17 mars 2026 med säkerhetsrättningar till den 17 mars 2028, säkerhetsfönstret för Laravel 11 stängdes den 12 mars 2026, och felrättningarna för Laravel 12 tar slut den 13 augusti 2026. En gång om året eller vartannat behöver systemet alltså flyttas till en ny huvudversion, och Laravels dokumentation säger att de strävar efter att göra det möjligt på en dag eller mindre — en strävan, inte ett löfte om hur lång tid det tar i ditt system.

PHP-löpbandet är dessutom detsamma för båda sidor: varje version har två års aktivt stöd och två år med enbart säkerhetsrättningar, så i ett femårsfönster ryms minst en och, beroende på var i cykeln du börjar, upp till två påtvingade PHP-övergångar oavsett vad som ligger under. Varken en WooCommerce-butik eller en Laravel-butik slipper undan den raden, och i båda fallen planeras den av samma person som planerar resten av förvaltningen — skillnaden är bara att på egen kod kan övergången göras när det passar dig, inte när ett tillägg slutar stödja den gamla versionen.

Tre rader där det färdiga verktyget vinner

Dyrare än förvaltningen är tre andra rader, och den första av dem är ekosystemet: här vinner det färdiga verktyget utan diskussion. Ännu en marknadsföringsautomatisering i en WooCommerce-butik är en post på marknadsplatsen — AutomateWoo kostar till exempel 140 € om året — och i vår erfarenhet en dags arbete, medan det i ett egenbyggt system är en specifikation, timmar och ett test, och vid 50 € i timmen är det den första funktion du kommer att fråga om den verkligen behövs; ett produktfält eller ett nytt filter i administrationen står inte på den listan, eftersom det är ramverket som ger det. Bristen på ekosystem är ingen engångskostnad utan en varaktigt högre tröskel för allt du senare får lust att prova, och för en butik som experimenterar mycket kan den väga tyngre än licensfakturan — det är just därför vi inte kallar licensfakturan för huvudargumentet.

Den andra är beroendet av ett enda team, och på det svarar strukturen snarare än ett påstående: koden i ett beställt bygge är din från första dagen, vi skriver den i standardstruktur för Laravel utan exotiska inslag, den kritiska logiken har tester, och med följer en dokumenterad README och CI, så att systemet går att ta över av någon annan. Laravel-utvecklare är lätta att hitta i Lettland, och därför slutar vårt eget svar på frågan varför Laravel med meningen att du inte blir beroende av ett enda team, oss inräknade, vilket inte upphäver risken men gör den flyttbar.

Den tredje är PCI DSS, och den talar emot oss. För handlare vars betalsida i sin helhet och direkt levereras av en tjänsteleverantör som uppfyller PCI DSS-kraven, och som själva har intygat att webbplatsen inte är utsatt för skriptbaserade angrepp, tog den utgåva av SAQ A som publicerades i januari 2025 och trädde i kraft den 31 mars 2025 bort kraven 6.4.3 och 11.6.1 — inventering av skript, motiveringen till dem och övervakningen av ändringar — och kravet 12.3.1 om riktad riskanalys, samtidigt som den påpekar att själva PCI DSS-kraven inte upphävs av det. Den lättnaden beskriver en liten WooCommerce-butik med bankens betalsida betydligt bättre än ett kassasteg vi ritar i vår egen kod, och bredvid den står ett andra lika obekvämt faktum: sårbarheten i mars hittades och lagades av någon annan, medan det i ett system vi har skrivit är vårt team som gör det, och därför är förvaltningen där en avtalsrad och inget antagande.

Våra beroenden är inte av ett annat slag

Filament är precis ett sådant tredjepartsberoende som de tillägg som nyss var på tal, och skillnaden mellan dem är en skillnad i grad och placering, inte i princip. Det är ett enda MIT-licensierat beroende i utvecklingsskiktet, dess kod ligger i vårt kodförråd och går att förgrena, och det sitter inte i köparens väg till kassan, eftersom det ritar ett administrationsgränssnitt och inte tar emot en betalning.

Om projektet stannade i morgon skulle butiken fortsätta ta emot ordrar, och det som föråldrades vore den del dina anställda ser, inte den som tar pengar av köparen. Filament publicerar dessutom en tabell över versionsstöd med konkreta datum: den tredje versionen kom i augusti 2023 och får säkerhetsrättningar till den 1 januari 2028, vilket är ett längre fönster än Laravel självt ger sina versioner.

Filament är ändå inget förstapartspaket i Laravel, eftersom Laravel inte nämner det i sin egen paketlista, och bakom projektet står inget företag med en balansräkning utan ett team runt en enda underhållare: i hans namn ligger omkring 17 000 ändringar i kodförrådet, nästa medarbetare har omkring 2 400, och finansieringen kommer från sponsorer på GitHub och betalda konsultuppdrag. Releasetakten är inte heller mild: den fjärde versionen kom i augusti 2025, den femte redan i januari 2026, två dagar efter Livewire 4, som är ytterligare ett tredjepartsberoende under den. Och meningen ”vid behov förgrenar vi det” är billig att skriva och dyr att infria.

Vi erbjuder ingen butik utan tredjepartsberoenden, för någon sådan har varken vi eller någon annan; vi erbjuder ett mindre antal av dem, en licens som låter oss behålla och underhålla koden själva, och en tydlig gräns mellan det som stoppar pengaflödet om det fallerar och det som förstör en anställds arbetsdag. Om den skillnaden inte känns tillräckligt stor för dig är det en fullt rimlig invändning — och då bygger vi det färdiga verktyget åt dig, för det är samma basversion eller Pro-version till samma pris. Inget av de två svaren gör oss till fel partner.

Hur vi gör det här valet i praktiken

Tillsammans med plattformen köper du svaret på en enda fråga — vem som får ändra dina pris- och orderregler, och enligt vilken tidsplan — och på egen kod är svaret ”du, nästa sprint”, medan det på en annan tillverkares tillägg är ”när tillverkaren tar med det i sin release, om den gör det”. Därför frågar vi inte efter omsättningen i förstudiesamtalet utan efter hur många prisnivåer du faktiskt har och om en kund någon gång ser ett annat pris än en annan — det är gränsen mellan de två prisfält WooCommerce ger av sig självt och en pristabell som någon måste underhålla.

Sedan frågar vi om saldot bor på mer än ett ställe, eftersom lagret plus butikshyllan redan är två ställen, och två ställen betyder att någon måste avgöra vilket av dem som räknas som sanningen. De två följande frågorna avgör oftast allt: blir en order en order på en gång, eller behöver den först ett godkännande — från kundens inköpsavdelning, från din säljchef eller från en kreditgräns — och skulle processen hålla även om katalogen växte till det dubbla?

Om svaret om godkännande är ”ja” står du på den punkt där marknaden för färdiga tillägg är som svagast: bevakning av kreditgränser och blockering av ordrar över gränsen finns varken i kärnan eller i de mest spridda B2B-paketen, och det utlovas bara av ett fåtal specialiserade poster, till exempel QuarkCode B2B Commerce Suite. Hur mycket av processen du är beredd att bygga om efter verktyget är den fråga som blir kvar, och otydliga krav är det dyraste misstaget i hela beställningen, vilket vi har skrivit om för sig.

Om svaren ryms i det färdiga verktyget, ta det färdiga verktyget, för det blir billigare, och bygga det åt dig gör vi. Om en eller två inte ryms är du med största sannolikhet på mellanvägen, och i prislistan motsvaras den av samma Pro-version för 9 500 € på WooCommerce — samma pris som på Laravel, eftersom det är arbetet som kostar och inte plattformen. Om tre eller fler inte ryms, och särskilt om godkännandesteget eller kreditgränsen är bland dem, handlar samtalet inte längre om plattformen utan om hur stor del av processen som ska bo i kod vi kan ändra utan att stämma av med en annan tillverkare.

Tre starter och vad var och en kostar

I praktiken säljer vi tre starter, och var och en har ett pris som går att räkna ut: den första är att börja med katalog, betalningar och frakt, lansera, och lägga till B2B-priser, rabattlogik och lagerintegrationer när de första verkliga ordrarna syns — i våra egna svar kallar vi det för det oftast riktiga valet. Den andra är att flytta en befintlig butik, och det är ett projekt och ingen strömbrytare: URL-strukturen behåller vi, men datamodellerna stämmer inte ett till ett, och varje tillägg som har lagrat egna fält måste bedömas för sig. I Pro-versionen och i abonnemanget ingår migreringen; i basversionen ingår den inte, och den offererar vi separat efter omfattning, eftersom priset avgörs av datamängden och antalet fält.

Den tredje är abonnemang: en Laravel-butik tillsammans med vår hosting från 130 € i månaden plus en engångsavgift på 600 € för konfigurationen, och i prislistan är innehållet detsamma som i Pro-versionen — lagermodul, stöd för flera språk, B2B-prisnivåer, rabattsystem och migrering av innehåll — bara med hosting, uppdateringar och förvaltning ovanpå; den finns bara med Laravel, eftersom en WooCommerce-butik inte går att abonnera på hos oss. Plattformsvalet i sig avgör några konkreta saker som arbetet inte jämnar ut: den här abonnemangsraden, de kostnadsfria automatiska rättningarna i kärnan, ekosystemets tröskel och vem som måste säga ja innan din nästa ändring når produktion. Allt annat är arbete.

Abonnemanget börjar på 130 € i månaden, vilket på fem år är från 7 800 €, plus 600 € för konfigurationen — från 8 400 € — och i det ingår hosting, uppdateringar och förvaltning. Pro-versionen kostar 9 500 € en gång, och hostingen kommer separat till den: vår managed hosting börjar på 45 € i månaden, alltså från 2 700 € på fem år, tillsammans från 12 200 €, och uppdateringar av applikationen ingår ännu inte där. Båda talen är golv och inga slutsummor, och jämförbara är de därför att innehållet i de två funktionerna är ett och detsamma i prislistan. I ett abonnemang betalar du för användningen tillsammans med hostingen, i ett bygge betalar du för systemet på en gång, och jämför man de två golven börjar abonnemanget lägre i ett femårsfönster. Var de båda golven slutar avgörs av volymen, och därför offererar vi båda per projekt i stället för att läsa dem ur prislistan.

Därefter går arbetet i tvåveckorssprintar med demo efter varje; betalningar, fraktbolag och bokföring kopplar vi in och testar före lansering; produkter, kunder och orderhistorik flyttar vi över med URL-strukturen bevarad. För större arbeten utanför standardomfattningen arbetar vi på löpande räkning med ett tak per vecka, eftersom ett fast pris där oftast betyder antingen ett påslag för risken eller en tvist om omfattningen, och timtaxan i prislistan är 50 €. Hela vägen tar 8–32 veckor. Få en projektbedömning och en teknikrekommendation — svara på samma frågor åt oss, så säger vi vilken av de tre vägarna som kostar minst i ditt fall.