Verkkokauppa-alustan valinta: WooCommerce vai Laravel — ja milloin kumpi

Alustaa ei ratkaise ensimmäisen päivän ominaisuuslista — varastomoduulin, B2B-hinnat ja monikielisyyden rakennamme kumpaankin. Ratkaisevaa on se, kuka päättää seuraavasta muutoksestasi ja mitä se maksaa.

Teknologiakysymys, johon ominaisuuslista ei vastaa

Keskustelu alkaa lähes aina samalla tavalla: asiakkaalla on noin seitsemänsataa tuotetta, kolme jälleenmyyjien hintaporrasta, joista jokainen näkee omilla tunnuksillaan vain oman hintansa, ja Visma Horizon -kirjanpito, jossa varastosaldo on totuus ja kauppa vain heijastaa sitä. Kysymys, jonka hän esittää, kuuluu: WooCommerce vai Laravel? Verkkokauppa-alustan valinta näyttäytyy hänelle kahden sarakkeen listana, jossa toisella puolella jokin ominaisuus on ja toisella ei — listana, jota meillä ei ole eikä ole kenelläkään muullakaan, joka oikeasti rakentaa kummallakin.

Varastomoduulin, jossa saldot synkronoituvat reaaliajassa, B2B-hintaportaat, alennusjärjestelmän, monikielisyyden tuen ja sisällön siirron rakennamme kummallekin alustalle, eikä hinta hinnastossamme riipu alustasta: verkkokaupan Basic-versio maksaa 4 500 € ja Pro-versio 9 500 € yhtä lailla WooCommercen kuin Laravelin päällä. Juuri nämä viisi riviä erottavat Basicin Prosta, ei se, mikä on alla; hallintapaneeli on hinnastossa nimetty jo Basic-versiossa, kun taas monivaluuttaisuus ei kuulu kumpaankaan versioon ja siitä sovitaan erikseen — jälleen kummalla alustalla tahansa.

Tästä seuraa jotain hyvin käytännöllistä: alusta, jota sinulle myydään ensimmäisen päivän ominaisuuslistalla, myydään sellaisella, jonka saa kumpaa tietä tahansa, ja vertailu, joka alkaa tuollaisesta listasta, on ohi ennen kuin se alkoi. Kiinnostava kysymys alkaa askelta myöhemmin: kuka päättää, mihin kauppasi pystyy ensi vuonna, ja kuinka kauan se päätös odottaa jonossa jonkun muun luona.

Ensimmäisenä vuonna kumpikin alusta tekee sen, mistä olet maksanut, koska kummassakin tapauksessa joku on juuri rakentanut sen; toisena vuonna prosessi muuttuu — mukaan tulee tukkumyynti, toinen varasto, velvollisuus lähettää koneluettavia laskuja tai yksinkertaisesti toisenlainen alennusten järjestys —, ja siitä hetkestä alkaen nämä kaksi tietä maksavat eri verran. Toisen valmistajan lisäosan päällä jokainen myöhempi muutos on kuin remontti vuokratiloissa: prosessisi säännöt asuvat jonkun toisen asetusikkunassa ja liikkuvat jonkun toisen julkaisuaikataulun mukaan. Omalla koodilla sama asia on työtä, jolla on hinnastossa tuntihinta, ja ainoa sovittava asia on sen kiireellisyys suhteessa muuhun työjonoon.

Mitä WooCommerce tekee hyvin

WooCommercen asennamme itse asiakkaiden kauppoihin aina, kun prosessi siihen sopii, ja se on W3Techsin kartoituksissa laajimmin käytetty verkkokauppajärjestelmä: 6. elokuuta 2026 se pyöri 8,2 %:ssa kaikista sivustoista ja muodosti 48,5 % kaikista verkkokauppajärjestelmistä näissä kartoituksissa. Itse lukua tärkeämpää on se, mistä se on laskettu — osuus kartoitetuista järjestelmistä, ei maailman kaupoista eikä varsinkaan verkkokaupan liikevaihdosta —, ja sen takana seisoo WordPress 41,2 %:lla kaikista sivustoista.

WordPress.orgin lisäosahakemisto näytti samana päivänä WooCommercen version 11.0.0, päivitetty 4. elokuuta, ja arvion ”7+ million active installations” eli yli seitsemän miljoonaa aktiivista asennusta. Varovaista lukutapaa suosittelee valmistaja itse: käytön seuranta on WordPress.orgista ladatussa ytimessä oletuksena pois päältä, joten kukaan — ei myöskään Automattic — ei tiedä, montako kauppaa oikeasti käy kauppaa, ja luku on asennusten yläraja eikä kauppiaiden määrä.

Valmistajan hinnoittelusivu kuvaa WooCommercen avoimen lähdekoodin alustaksi ilman alustamaksua ja 0 %:n liikevaihto-osuudella: et maksa siitä, että myyt, etkä siitä, että myynti kasvaa. Tuoteluettelo, tilauslista ja alennusasetukset näyttävät lisäksi samalta kuin muu WordPressin hallinta, jota tiimisi todennäköisesti osaa jo käyttää ilman koulutusta.

Vahvin WooCommercen puolesta puhuva argumentti katoaa kilpailijavertailuista lähes poikkeuksetta, ja se on automaattinen korjauspäivitys: 2. maaliskuuta 2026 julkistettiin Store API:n haavoittuvuus, joka koski versioita 5.4–10.5.2 ja jonka avulla väärennetyllä pyynnöllä pystyi luomaan pääkäyttäjätilin. Virheen löysi joku muu kuin kauppiaat itse, korjaus vietiin 52 haavoittuvaan versioon, ja samana päivänä kello 14.00 UTC se alkoi levitä automaattisesti kauppoihin, joissa automaattiset päivitykset ovat päällä — ilman laskua. Tuo asetus ei kuitenkaan ole itsestäänselvyys, ja juuri sen konfiguroi ja sitä valvoo ylläpitosopimuksessa ihminen; miten WordPress-sivustoja murretaan ja mitä tehdä, jos se on jo tapahtunut, on kuvattu artikkelissamme hakkeroidusta WordPress-sivustosta.

Suositus ei siis ole muuttunut, ja se lukee myös palvelusivullamme: hyvin pienelle verkkokaupalle, jonka prosessit ovat vakiomuotoisia, WooCommerce. Sadalle tuotteelle yhdellä hinnalla, yhdellä varastolla ja yhdellä maksutavalla räätälöity alusta ei anna mitään sellaista, mistä kannattaisi maksaa erotus, ja kalliimman vaihtoehdon myyminen silloin, kun halvempi tekee saman, tarkoittaa yhtä tyytymätöntä asiakasta enemmän eikä yhtäkään suositusta.

Toimiiko WooCommerce Latvian maksujen ja toimitusten kanssa?

Toimii. Toimitukset ja maksut Latviassa eivät ole se kohta, johon valmis verkkokauppa pysähtyy, ja päinvastaiset varoitukset ovat yleensä perusteettomia: Omniva julkaisee valmiit moduulit kuudelle alustalle — WooCommerce, Shopify, PrestaShop, OpenCart, Magento ja Mozello — ja niiden rinnalla dokumentoidun OMX-rajapinnan, jota pitkin kulkevat lähetystiedot, osoitekortit, seurantatapahtumat ja pakettiautomaattien listat kaikissa kolmessa Baltian maassa, mutta edellytyksenä on yritysasiakassopimus eikä ohjelmoija. DPD Baltics ylläpitää itse omaa WooCommerce-lisäosaansa WordPress.orgin hakemistossa — versio 1.2.91, yli 2 000 aktiivista asennusta —, ja se kattaa pakettiautomaatit, kuriirin, osoitekortit, luovutuslistat ja postiennakon; samalla sivulla näkyy myös sen julkinen arvosana 2,7/5 ja käyttäjäarvioita, joissa valitetaan ristiriidoista muiden toimituslisäosien kanssa.

MakeCommerce, jonka takana on Maksekeskus AS, antaa yhdellä sopimuksella Swedbankin, SEB:n, Citadelen ja Luminorin verkkopankkimaksut, kortit, Apple Payn ja Google Payn sekä samassa paketissa Omnivan, DPD:n, Venipakin ja Unisendin toimitukset; sen WooCommerce-lisäosalla on yli 3 000 aktiivista asennusta ja viimeisin päivitys kesäkuulta 2026. Klix by Citadele, jota pankki ylläpitää itse, julkaisee viralliset lisäosat kuudelle alustalle, WooCommercelle versiosta 3.5 alkaen, joten väite siitä, ettei valmis kauppa pystyisi Latviassa ottamaan rahaa vastaan, olisi yksinkertaisesti epätosi.

Saman asian toinen puoli on se, etteivät nämä palveluntarjoajat ole lisäosien omaisuutta: MakeCommerce, Omniva ja DPD julkaisevat rajapintoja eivätkä pelkkiä moduuleja, ja hinnastossamme maksujen kytkeminen — MakeCommerce ja Stripe — sisältyy jo 4 500 euron Basic-versioon riippumatta siitä, mikä alusta on alla. Horizonin, Jumisin, Latvijas Pastsin, Omnivan ja DPD:n integraatiot ovat verkkokauppapalvelun rivi eivätkä lisähinta Laravelista, ja Omnivan, Latvijas Pastsin, DPD:n ja Venipakin toimitusrajapintojen kanssa työskentelemme säännöllisesti, joten latvialainen toimitus- ja maksukerros ei puhu minkään kolmesta tiestä puolesta eikä sitä vastaan.

Missä Latviassa on oikeasti työtä

Taustajärjestelmien puolen tekee hankalaksi se, että Visma Horizon, Jumis ja Directo julkaisevat kukin oman REST-rajapintansa — Directon dokumentaatio kuvaa tunnistautumisen X-Directo-Key-otsakkeella ja pääsyn nimikkeisiin, tilauksiin, asiakkaisiin, laskuihin, saldoihin ja hintakaavoihin —, mutta julkaistu rajapinta ei vielä ole integraatio: jonkun on sovitettava yhteen se, mitä kauppa kutsuu tuotteeksi, ja se, mitä kirjanpito kutsuu nimikkeeksi, ja päätettävä, kumpi järjestelmistä pitää hallussaan totuutta saldosta sillä sekunnilla, kun ostaja painaa nappia. Kaksi paikkaa, joissa saldo elää, ovat kuin kaksi kelloa laivassa: ennen kuin ne tahdistetaan, kukaan ei tiedä aikaa, ja tämä työ on yksilöllistä millä alustalla tahansa — Horizonin ja Jumisin kanssa teemme sitä säännöllisesti.

Tämän päällä on päivätty lakitieto, jonka sisällä on ansa: strukturoitu sähköinen lasku on ollut julkishallinnolle pakollinen 1. tammikuuta 2025 alkaen, mutta yritysten välisessä kaupassa se muuttuu pakolliseksi vasta 1. tammikuuta 2028 — Latvian kirjanpitolain mukaisessa järjestyksessä ja LVS EN 16931-1:2017 -muodossa. Ansa on päivämäärä: alun perin kaavailtiin vuotta 2026, joten vuoden 2024 lehtijutut nimeävät yhä väärän määräajan, ja asia kannattaa tarkistaa Latvian valtiovarainministeriön strukturoitua sähköistä laskua käsittelevältä sivulta eikä uutisista, sillä yrityksille myyvässä kaupassa koneluettavan laskun reitti on jonkun rakennettava millä alustalla tahansa riippumatta siitä, mikä vuosi lopulta osoittautuu oikeaksi.

Verkkokauppa-alustan valinta: mikä kolmesta tiestä on sinun?

Vertailut, jotka esittävät tämän valinnan kahtena nappina, jättävät pois sen tien, jota myymme useimmin, sillä teitä on todellisuudessa kolme; ne eroavat siinä, kuinka suuri osa prosessistasi asuu koodissa, jota voit itse muuttaa, ja valinta niiden välillä on valinta siitä, missä hinta- ja tilaussääntösi tästä eteenpäin sijaitsevat — asetusikkunassa, omassa repositoriossasi vai jossain siltä väliltä.

Ensimmäinen tie on valmis työkalu valmiine lisäosineen — WooCommerce tai OpenCart, joita tarjoamme myös olemassa oleville kaupoille. WooCommercen ytimessä on kaksi hintakenttää, normaali hinta ja alennettu hinta, yksi saldoluku tuotetta tai muunnelmaa kohti ja kolme maksutapaa, joista yksikään ei ota rahaa vastaan verkossa, joten tietylle asiakasryhmälle tarkoitettu hinta, määräalennukset, tarjouksen muuttaminen tilaukseksi, arvonlisäverovapaus ja saldot useassa varastossa ovat jokainen erillinen ostos erilliseltä valmistajalta erillisellä vuositilauksella. Tie on nopein ja hyvin usein oikea, eikä sen hinta ole raha vaan se, että prosessisi säännöt asuvat tästä lähtien toisen valmistajan asetusikkunassa.

Toinen tie ei juuri esiinny vertailuissa, vaikka myymme sitä useimmin: valmis työkalu, jonka päälle tulee omaa koodiamme. WooCommerce on avoimen lähdekoodin PHP-koodia, joten jälleenmyyjien hintataulun, luottotarkistuksen tai saldon varauksen voi kirjoittaa ytimen viereen sen sijaan, että ostaisi lisäosan, eikä siihen tarvita lisenssiä — siihen tarvitaan tunteja — sillä hinnalla, että tämä koodi jää sidoksiin WooCommercen päivitysrytmiin ja siihen, miten tämä alusta säilöö tilaukset. Huomattava osa siitä, mitä hinnastossamme kutsutaan 9 500 euron Pro-versioksi, on juuri tätä työtä, ja täällä on suurin osa omista kaupoistamme.

Kolmas tie on oma alustamme, jossa tuoteluettelo, ostoskori, kassa ja hintalogiikka kirjoitetaan tyhjästä sinun prosessisi ympärille; se on kallein aloitus ja ainoa, jossa ei ole yhdenkään toisen valmistajan oletusta siitä, mikä on tuote ja milloin tilauksesta tulee tilaus. Kolmannen tien sisällä on haara: Bagisto ja Lunar ovat MIT-lisensoituja Laravel-kaupankäyntipaketteja — 6. elokuuta 2026 GitHubissa 27 943 ja 3 588 tähteä —, jotka antavat tuoteluettelon ja ostoskorin valmiiksi kirjoitettuina vastineeksi vielä yhdestä ulkoisesta riippuvuudesta, jonka rytmi ei ole sinun käsissäsi. Sitä tietä me emme kulje.

Paljonko WooCommercen lisäosalisenssit maksavat vuodessa?

Kaupalle, jossa on seitsemänsataa tuotetta ja kolme jälleenmyyjäporrasta, ensimmäinen tie maksoi 6. elokuuta 2026 kahdesta julkisesta hinnasta 270 € vuodessa plus tuntemattoman kolmannen. Dynamic Pricing antaa 113 eurolla vuodessa määrä- ja rooliperustaiset alennukset; Addifyn kehittämä B2B for WooCommerce antaa 157 eurolla vuodessa rooliperustaiset hinnat, porrastetut hinnat, tarjouksen muuttamisen tilaukseksi, arvonlisäverovapauden sekä roolin mukaan rajatut maksu- ja toimitustavat; mutta saldoihin useassa varastossa ei ytimessä ole varauduttu mitenkään, joten mukaan tulee kolmas maksullinen lisäosa, esimerkiksi Addify Multi Inventory Management, jolle valmistaja ei ilmoita julkista vuosihintaa.

Nuo 270 € vuodessa ovat hieman yli viiden kehitystunnin verran, sillä hinnastossamme kehitystunti maksaa 50 €, ja ominaisuuksista, joilla on valmistaja, dokumentaatio ja päivitykset, se on halpa hinta. Hinta, jota ei ennen keskustelua tiedä, ei kuitenkaan ole rivi kustannusarviossa: varastolisäosa nostaa tätä lukua, ja se, kuinka paljon, riippuu tarjouksesta, joka sinulle saapuu sen jälkeen, kun olet kertonut varastojen määrän ja tilausvolyymin.

Toisenlaisella kaupalla rivit ovat toiset: sille, joka myy tilauksia, ajanvarauksia ja jäsenyystasoja, samoilla markkinapaikan hinnoilla WooCommerce Subscriptions maksaa 245 € vuodessa, Bookings 218 €, Memberships 175 €, AutomateWoo 140 € ja Product Add-Ons 70 € — yhteensä 848 € vuodessa. Viidessä vuodessa se on hintojen pysyessä ennallaan 4 240 €: lähes kokonaisen Basic-version kaupan hinta, joka hinnastossamme on 4 500 €, ja lähes puolet 9 500 euron Pro-versiosta. Tämä rivi ei jaksotu, koska se koskee yhtä sivustoa ja yhtä vuotta ja se maksetaan joka vuosi uudelleen.

Sama luku toisin päin on lähes 85 kehitystuntia 50 euron tuntihinnalla, ja ne ovat tunteja, jotka jäävät sinun koodiisi ja sinun omistukseesi eivätkä uusiudu ensi vuoden laskulla. Tuo 848 euron lasku on lisäksi tilauksia, ajanvarauksia ja jäsenyyksiä myyvän kaupan lasku eikä normi — normia ei tässä ole, ja jokaisen kaupan on laskettava tämä rivi kokoon omasta prosessistaan. Lisenssirivi tulee myös rakentamisen päälle eikä sen tilalle: kummassakin tapauksessa joku on ensin rakentanut kaupan, ja vain toisessa niistä rakennetusta tulee ensi tammikuussa taas lasku.

Mitä laskulle tapahtuu, kun sitä ei makseta

Jos tilausta ei uusita, WooCommerce.comin dokumentaatio sanoo sen suoraan: ”the extension or theme remains installed on your site but will no longer receive updates” — lisäosa jää asennetuksi, kauppa jatkaa toimintaansa, ja pois jäävät vain päivitykset. Uusimattoman lisenssin seuraus ei siis ole käyttökatko, joka huomataan samana päivänä, vaan korjaamaton koodinpätkä, joka yhä käsittelee maksuja; yksi tilaus kattaa lisäksi yhden tuotantosivuston ja yhden kehityssivuston, ja aliverkkotunnukset lasketaan erikseen.

Yksi rivi käyttäytyy toisin ja käyttäytyy samoin kummallakin puolella: kirjanpidon liitin ei yleensä ole lisenssi vaan tilaus, joka nousee tilausmäärän mukana — MyWorks Xero Sync alkaa WooCommercen markkinapaikalla maksuttomasta tasosta, ja siitä eteenpäin hinnan määrää volyymi, joten tämä rivi kasvaa juuri silloin, kun kauppa kasvaa. Räätälöity alusta ei poista sitä, mutta muuttaa sen, kuka liitintä ylläpitää, ja meidän tapauksessamme ne ovat tunteja; rivejä ei myöskään pidä paisutella: monikielisyys ei ole automaattisesti 99 € vuodessa WPML Multilingual CMS:stä, koska WPML:n rinnalla on myös Polylang, mutta halvempi WPML-lisenssi Multilingual Blog 39 eurolla ei tue verkkokauppaa, joten kaupalle valintaa 39 ja 99 euron välillä ei ole olemassa.

Miksi ero näkyy vasta toisena vuonna

Sen, että muutoksen hinta on todellinen eikä teoreettinen kuluerä, näyttää alusta itse: vuodesta 2023 alkaen WooCommerce on poistanut kaksi kantavaa osaa, vetänyt takaisin yhden beetaominaisuuden ja vaihtanut yhden oletuksen. Vanha REST API katosi ytimestä 11. kesäkuuta 2024 version 9.0 mukana, vaikka se oli merkitty vanhentuneeksi jo versiossa 2.6 vuonna 2016; sisäänrakennettu PayPal Standard -maksutapa poistettiin versiossa 8.9 toukokuussa 2024; tuote-editorin beeta poistettiin versiossa 11.0, joka ilmestyi hakemistoon 4. elokuuta; mutta tilausten HPOS-tallennuksesta tuli uusien asennusten oletus versiossa 8.2 lokakuussa 2023, eikä se koske olemassa olevia kauppoja ennen kuin joku ne siirtää.

Tätä taustaa vasten WooCommercen kehittäjäblogin Advisories-osiossa on kahdentoista kuukauden aikana 5. elokuuta 2026 asti 37 merkintää — noin kolme kuukaudessa —, ja jokainen niistä on tarkistettava jokaista kauppaan asennettua laajennusta vasten, minkä neljän lisäosan kauppa ottaa vastaan vaivatta mutta kahdenkymmenen kauppa ei enää. Kasa ei myöskään kerry yhdessä päivässä: lisäosat tulevat yksi kerrallaan, kukin erikseen täysin järkevä päätös, ja tarkistettavien yhdistelmien kertautuminen tapahtuu hiljaa.

Kymmenen lisäosaa ei ole kymmenen osaa vaan kymmenen sopimusta, joista jokainen voi päättyä erikseen, ja omistaja vaihtuu silloinkin, kun koodissa ei ole mitään vikaa. Arvostelupalvelu Judge.me sulki 31. lokakuuta 2025 WooCommerce-integraationsa yhdessä Squaren, Squarespacen, BigCommercen, Dudan ja PrestaShopin kanssa: tietoihin pääsi käsiksi vielä 19. marraskuuta asti, minkä jälkeen pääsy poistettiin peruuttamattomasti, eivätkä arvosteluvideot sisältyneet vientiin, joten vuosien mittaan kerätty markkinointiomaisuus jäi osittain oven taakse. Rauhallisemmat tapaukset ovat vakuuttavampia: Automattic osti vuonna 2019 Prospressin, joka oli WooCommerce Subscriptionsin ja AutomateWoon tekijä, GoDaddy osti vuonna 2020 SkyVergen, jonka yli kuuttakymmentä lisäosaa käytti yli 100 000 kauppiasta, ja kummankin kaupan jälki oli julkisesti tiedetyn perusteella kauppiaille hyvä. Kysymys ei koske vahinkoa vaan sitä, että kauppasi osien omistaja voi vaihtua ilman sinun myötävaikutustasi.

Kuinka suuri riski oikeasti on

Mittakaava suhteuttaa sen, ja luvut ovat tässä omiamme: 6. elokuuta 2026 tehdyssä laskennassa WordPress.orgin lisäosarajapinta palautti 7 764 lisäosaa tunnisteella ”woocommerce”, joista 23,1 % on jäänyt ilman päivitystä kahdeksi vuodeksi tai pidemmäksi aikaa, mutta samassa laskennassa 10 809 800 aktiivista asennusta istuu lisäosilla, jotka on päivitetty viimeisen puolen vuoden aikana, ja vain 208 790 sellaisilla, joihin ei ole koskettu yli kolmeen vuoteen. Lisäosia, joilla on vähintään 10 000 asennusta ja jotka ovat jääneet kahdeksi vuodeksi ilman päivitystä, on samassa laskennassa täsmälleen kuusi.

Hylätty lisäosa ei lähes koskaan ole se suosittu, jonka kaikki tuntevat: riski istuu siinä yhdessä kapeassa moduulissa, jota juuri sinun prosessisi vaatii — B2B-hintaportaissa, varastoliittimessä, tietyn kuriirin osoitekorttigeneraattorissa —, ja mitä enemmän prosessisi poikkeaa keskimääräisestä, sitä lähempänä olet sitä hakemiston osaa, jossa viimeisin päivitys on toissa vuodelta. Tätä riviä voi pienentää rakentamatta mitään uudelleen: ylläpitosopimuksessa teemme sen me — vähennämme lisäosien määrää, konfiguroimme päivitykset ja pidämme yllä valvontaa —, ja uudelleenrakentaminen on vastaus vasta silloin, kun ongelma ei enää ole ylläpito vaan se, ettei prosessia ole kirjattu mihinkään.

Missä WooCommercen tiedon muoto alkaa puristaa

Toinen paikka, jossa toinen vuosi maksaa, on tiedon muoto, ja ensin se puoli, jossa tämä argumentti ei enää pidä paikkaansa: tilaukset makaavat uusissa asennuksissa versiosta 8.2 alkaen neljässä omassa taulussaan, ja yhtiön oma maaliskuun 2023 mittaus osoittaa, että uusi tallennustapa nopeuttaa tilaustoimintoja eikä hidasta niitä. Puristaa tuotepuoli, ja parhaiten sen ovat kirjoittaneet WooCommercen omat kehittäjät selittäessään 1. huhtikuuta 2019 version 3.6 suorituskykyparannuksia: tuotteet ja muunnelmat kulkevat WordPressin artikkelijärjestelmän läpi, jossa post meta on äärimmäisen joustava mutta ”not that efficient when we need to sort or filter by many meta values at once” — ei kovin tehokas silloin, kun on lajiteltava tai suodatettava monen meta-arvon mukaan yhtä aikaa. Vastaus samassa julkaisussa oli wc_product_meta_lookup, denormalisoitu aputaulu, jossa on SKU, hinta ja saldotila post metan rinnalla eikä sen tilalla, joten perusmuoto pysyi sellaisena kuin se oli.

Vastaava työ tuotepuolella, woocommerce-product-tables-feature-plugin, on asunut 16. lokakuuta 2017 lähtien pelkästään GitHubissa, eikä sitä ole hylätty — viimeisimmät muutokset ovat 31. heinäkuuta 2026 —, sitä ei vain edelleenkään pidetä riittävän vakaana WordPress.orgin hakemistoon. Sen vieressä on wp_options, jonka autoload-kentällä ei ole oletuksena indeksiä, jonka automaattisesti ladattavat tiedot luetaan jokaisella sivulatauksella, jonka WooCommerce itse suosittelee pitämään noin 500 rivin alapuolella ja jonka kasvun aiheuttavat nimenomaan laajennukset, lisäosat ja teemat — sama kasa, josta edellä oli puhe, vain tietokannan puolelta katsottuna.

Mitä Laravel antaa kaupalle ja valmis työkalu ei

Laravel ei ole kauppa eikä esitä sellaista: se antaa nimettyjä, dokumentoituja ja MIT-lisensoituja osia, joista joku kokoaa kaupan, joten rahan arvoinen kysymys ei ole ”onko kehys hyvä” vaan ”mitkä prosessisi osat muuttuvat vihdoin sinun omiksi tauluiksesi ja sinun omiksi taustatöiksesi”. Kauppiaan verkkokaupassa vastaus on yleensä neljä riviä — jälleenmyyjien hintataulu, luottoraja, saldon varaus ja kirjanpidon synkronointi —, ja juuri ne ostat valmiissa työkalussa neljältä eri valmistajalta ja sovitat sen jälkeen keskenään yhteen.

Sitä ennen on rehellistä kertoa, mitä tämä tie ei anna, sillä yhtäkään neljästä rivistä ei anna myöskään Laravel itse: kehyksen viralliset aloituspaketit antavat tunnistautumisen eivätkä mitään muuta — ei tuoteluetteloa, ei ostoskoria, ei kassavaihetta, ei varastoa —, ja ainoa mukana tuleva kaupankäyntipaketti on Cashier, joka hoitaa tilauslaskutuksen Stripen tai Paddlen puolella ja olettaa, että tuotteet hintoineen on jo kuvattu maksupalvelun omassa hallinnassa. Se, minkä Laravel antaa, on muoto, jossa nämä neljä riviä on halpa kirjoittaa ja vielä halvempi myöhemmin muuttaa.

Jonot, transaktiot ja oman tietokannan muoto

Ensimmäinen osa on jonot: yksi rajapinta usean moottorin päälle — Redis, tietokanta, Amazon SQS, Beanstalkd —, mikä päästää tilauksen käsittelyn, ERP-synkronoinnin ja sähköpostin ulos pyynnöstä, niin ettei ostaja enää odota kirjanpitojärjestelmän vastausta. Dokumentaatiossa on nimetty myös se, mikä ratkaisee todellisen käyttöönoton: töiden ketjut ja erät, uniikit työt, joita jono ei suorita kahdesti, uudelleenyritykset ja epäonnistuneiden töiden säilö, josta ne voi ajaa uudelleen. Kahdesti suoritettu tilaus on lasku, joka jonkun on jälkeenpäin mitätöitävä, ja asiakas, joka huomaa sen ennen sinua.

Horizon näyttää jonojen läpimenon, suoritusajat ja virheet, sallii worker-prosessien konfiguraation kuvaamisen koodissa ja varoittaa, kun jono odottaa liian kauan, mutta se vaatii Redisin eikä toistaiseksi toimi Redis Clusterin kanssa, joten se on oma rivinsä hosting-laskulla eikä maksuton lisä. Transaktiot puolestaan ovat se, mitä lause ”tilaus ja saldon liike tapahtuvat molemmat tai ei kumpikaan” käytännössä tarkoittaa: DB::transaction peruu muutokset virhetilanteessa itse ja sallii niiden toistamisen, jos tietokanta ajautuu lukkiumaan.

Migraatioita Laravelin dokumentaatio kutsuu tietokannan versionhallinnaksi, ja käytännössä se tarkoittaa, että suunnittelet taulut, indeksit ja viiteavaimet oman hinta- ja saldologiikkasi ympärille etkä sen ympärille, mitä joku toinen aikanaan päätti tuotteen käsitteestä. Haku ja tilauslaskutus pysyvät lisäksi valintoina eivätkä pakollisina kuukausiriveinä: Scout indeksoi samassa tietokannassa MySQL:n tai PostgreSQL:n kokotekstihakemistoilla ilman ulkoista palvelua, kun taas Stripen puolta hoitaa Cashier, jos kaupassa ylipäätään on tilauksia.

Hintataulu, luottoraja ja varaus koodissa

Miltä se konkreettisesti näyttää, näkyy parhaiten ensimmäisestä neljästä rivistä: jälleenmyyjien hintataulu omalla koodilla on yksi migraatio, jossa on neljä saraketta — asiakasryhmä, tuote, määrän kynnys ja hinta — ja uniikki indeksi kolmen ensimmäisen yli, joten tietyn ostajan hinta löytyy yhdellä kyselyllä ja yhdellä liitoksella eikä hakemalla meta-arvojen seasta, ja uusi hintaporras on uusi rivi taulussa eikä uusi asetus toisen valmistajan ikkunassa. Kun vuoden päästä mukaan tulee neljäs porras, jossa pyöristys menee toisin, muuttuu yksi paikka ja yksi testi, ja molemmat ovat sinun repositoriossasi.

Luottoraja ja saldon varaus ovat sama ajatus askelta pidemmälle, sillä myös niissä kaikki lepää yhden taulun ja yhden transaktion varassa: maksamattomien laskujen summa on sarake asiakkaan rivillä, ja tarkistus tapahtuu samassa transaktiossa, jossa tilaus syntyy, joten kaksi yhtä aikaa lähetettyä tilausta eivät voi kumpikin livahtaa rajan alitse, ja lukkiumatilanteessa transaktio toistuu itsestään. Varaus taas on rivi, jolla on voimassaoloaika, joka syntyy tilauksen mukana ja katoaa ajastetulla taustatyöllä, jos tilausta ei makseta, joten varastosaldo ei ole enää luku, jonka kaksi ostajaa voi tyhjentää yhtä aikaa.

Kirjanpidon synkronointi on jonotyö, joka on merkitty uniikiksi, joten uusi yritys ei koskaan kirjoita laskua kahdesti, ja kun Horizon aamulla näyttää, että kirjanpidon päässä oli yöllä katko, epäonnistuneiden töiden säilö sallii niiden ajamisen uudelleen järjestyksessä sen sijaan, että ne kirjoitettaisiin käsin uusiksi. Jokainen näistä neljästä rivistä on saatavilla valmiissa työkalussakin, vain valmistajan asetusikkunana, jonka sääntöjä et näe, joka on jokaisen päivityksen jälkeen tarkistettava uudelleen ja joka ei siirry toiselle alustalle.

Kaksi työtä, jotka ovat jo käytössä

Miltä se näyttää projektissa eikä dokumentaatiossa, näkyy omissa Laravel-töissämme. LIDOn ruoantilausalustalla hintaa ei ratkaise tuote vaan osoite: paikannus määrittää toimitusalueen, etäisyyden ja maksun, kullakin kolmestatoista ravintolasta on oma valikoimansa, ja kaupan rinnalla toimii erillinen prosessiautomaation järjestelmä, johon kaikki tilaukset päätyvät ja josta ne jaetaan ravintoloille ja kokeille — integraatioineen yli kymmeneen muuhun järjestelmään, muun muassa Wolt, QWQER ja RKeeper. Riga Lashesin Laravel-verkkokaupassa on muunnelmakohtaiset hinnat, asiakastilit, toivelista ja studion palveluhinnasto, ja niiden takana tuotevarasto, kuriiripalveluiden integraatiot ja maksut, joissa prosessi on automatisoitu pakkausvaiheeseen asti. Kummassakin tapauksessa ratkaiseva osa olisi jouduttu kirjoittamaan valmiin työkalunkin päälle, vain toisen valmistajan hinta- ja tilausmuodon sisällä, ja juuri tämä on se ero, joka jää: omalla koodilla tämä työ on yksi repositorio ilman erillistä tilausmaksua jokaisesta kyvystä, eikä sitä tarvitse jokaisen alustapäivityksen jälkeen tarkistaa uudelleen. Laravelia olemme kirjoittaneet vuodesta 2013, ja sen päällä toimii suurin osa räätälöidyistä järjestelmistämme, julkishallinnon portaaleistamme ja B2B-alustoistamme.

Mihin katoaa se raha, joka ei mene lisensseihin, on konkreettinen kysymys, ja vastaus on yhtä konkreettinen: ne lähes 85 tuntia, jotka 848 euron vuosilisenssirivi viidessä vuodessa maksaa, ovat omalla koodilla juuri tämä hintataulu, tämä luottoraja, tämä varaus ja tämä synkronointi, kirjoitettuina sinun prosessisi ympärille. Ne jäävät repositorioosi silloinkin, jos me joskus lakkaamme olemasta kumppanisi: tilaustyönä tehdyssä rakennuksessa koodi on sinun ensimmäisestä päivästä alkaen, ja tämäkin lukee Laravel-palvelumme sivulla.

Filament: hallintapaneeli, jota kukaan ei kirjoita tyhjästä

Sen osan vastaväitteestä, että itse rakennetussa järjestelmässä kaikki on kirjoitettava tyhjästä, poistaa Filament — avoimen lähdekoodin käyttöliittymäkehys Laravel-sovelluksille. Resurssit generoivat CRUD-näytöt Eloquent-malleille, taulukkorakentaja antaa suodatuksen, lajittelun ja sivutuksen, lomakekomponentit tulevat sisäänrakennetulla validoinnilla, ja käyttöoikeudet Filament lukee suoraan Laravelin mallikohtaisista policy-luokista, joten rooliehtoja ei tarvitse kirjoittaa toiseen kertaan. Suhteiden hallinnat, kojelaudan vimpaimet ja ilmoitukset ovat samassa paketissa; samoin multi-tenancy-tuki (usean asiakasorganisaation eriyttäminen), tosin Filamentin oman varoituksen kanssa siitä, että kyseessä on työkalupakki eikä takuu ja että asiakasorganisaatioiden välisestä tietojen erottelusta vastaa toteuttaja; koko kerros on MIT-lisensoitu kuten Laravel itsekin, joten lisenssimaksuja siinä ei ole yhtäkään.

Tärkeintä ei kuitenkaan ole se, mitä kehys piirtää, vaan se, mihin vapautunut raha menee: tuotteiden muokkausnäytöt, tilaustaulukot, suodattimet ja oikeustarkistukset ovat sitä kehitystyön osaa, jota ostaja ei koskaan näe ja josta tilaaja silti maksaa täyden hinnan, ja kun ne tulevat kehyksestä, budjetti menee hinta-, tilaus- ja varastologiikkaan, jonka takia räätälöityyn toteutukseen ylipäätään päädyttiin. Esimerkki on samassa paikassa, jossa luet tätä: tämä sivusto toimii Laravel 13:n ja Filament 5:n päällä, ja koko toimituksellinen työ kahdellatoista kielellä tehdään paneelissa, jonka konfiguroimme emmekä kirjoittaneet tyhjästä.

Mihin kehys loppuu ja kauppa alkaa

Filament ei ole kauppa, ja tämä raja kannattaa vetää selvästi: kehys antaa hallintapaneelin — näytöt, taulukot, lomakkeet ja oikeustarkistukset —, mutta se ei tiedä mitään siitä, mitä näissä taulukoissa on ja millä säännöillä se sinne päätyy. Tuoteluettelo muunnelmineen ja ominaisuuksineen, ostoskori, kassavaihe, hintasäännöt asiakastasoineen ja määräalennuksineen, tilauksen elinkaari luonnista palautukseen ja saldon varaaminen varastossa — mitään näistä ei Laravelin ja Filamentin paketissa ole. Filament on kuin valmiiksi rakennettu verstas hyllyineen, työpöytineen ja valoineen; se, mitä siellä valmistetaan, ei tule mukana.

Kuinka kirjaimellisesti se on tarkoitettu, näkyy dokumentaatiosta itsestään: Order- ja Payment-mallit esiintyvät siinä ainoastaan esimerkkeinä, jotka kehittäjä kirjoittaa itse, sillä kehyksessä ei tuollaisia luokkia yksinkertaisesti ole. Se ei ole kehyksen puute vaan työnjako: Filament lupaa hallintakäyttöliittymän eikä mitään muuta, aivan kuten Laravel lupaa kehyksen eikä valmista sovellusta. Käytännössä se tarkoittaa, että Filament lyhentää hallinnan rakentamista mutta ei lyhennä lainkaan sitä osaa, jonka takia räätälöityyn toteutukseen ylipäätään päädyttiin.

Siksi hinnastossamme verkkokaupan Basic-versio 4 500 eurolla tulee ilman varastomoduulia, monikielisyyden tukea, B2B-hintaportaita, alennusjärjestelmää ja sisällön siirtoa, kun taas Pro-versio 9 500 eurolla tulee ne kaikki mukanaan. Erotus ei ole lisähinta modernimmasta teknologiasta vaan hinta sille, mitä jonkun on kirjoitettava, ja juuri siksi se on kummallakin alustalla sama. Kiinteän laajuuden Laravel-järjestelmä alkaen 8 000 eurosta on hinnastossa jo toinen rivi ja toinen tuote: se ei ole kauppa vaan järjestelmä, jossa koko prosessi syntyy tyhjästä.

Mitä emme lupaa: missä itse rakennettu maksaa enemmän

Itse rakennettu kauppa on vapaa lisäosien vuosilisensseistä muttei ylläpidosta, ja nämä ovat kaksi täysin eri asiaa. Laravel antaa jokaiselle julkaisulle 18 kuukautta virhekorjauksia ja kaksi vuotta tietoturvakorjauksia, julkaisee uuden pääversion kerran vuodessa eikä pidä erillistä pitkän tuen tasoa, joten päivämäärät ovat konkreettisia: Laravel 13 ilmestyi 17. maaliskuuta 2026 ja saa tietoturvakorjauksia 17. maaliskuuta 2028 asti, Laravel 11:n tietoturvaikkuna sulkeutui 12. maaliskuuta 2026, ja Laravel 12:n virhekorjaukset päättyvät 13. elokuuta 2026. Kerran vuodessa tai parissa järjestelmä on siis siirrettävä uuteen pääversioon, ja Laravelin dokumentaatio sanoo heidän pyrkivän siihen, että se onnistuu päivässä tai nopeammin — pyrkimys, ei lupaus siitä, kuinka kauan se sinun järjestelmässäsi kestää.

PHP:n juoksumatto on lisäksi kummallekin puolelle sama: jokaisella versiolla on kaksi vuotta aktiivista tukea ja kaksi vuotta pelkkiä tietoturvakorjauksia, joten viiden vuoden ikkunaan mahtuu vähintään yksi ja aloitushetkestä riippuen jopa kaksi pakotettua PHP-siirtymää riippumatta siitä, mikä on alla. Sen rivin ohi ei pääse WooCommerce- eikä Laravel-kauppa, ja kummassakin tapauksessa sen suunnittelee sama ihminen, joka suunnittelee muunkin ylläpidon — ero on vain siinä, että omalla koodilla siirtymän voi tehdä silloin, kun se sinulle sopii, eikä silloin, kun jokin laajennus lakkaa tukemasta vanhaa versiota.

Kolme riviä, joilla valmis työkalu voittaa

Ylläpitoa kalliimpia ovat kolme muuta riviä, ja ensimmäinen niistä on ekosysteemi: tässä valmis työkalu voittaa ilman keskustelua. Vielä yksi markkinoinnin automaatio WooCommerce-kaupassa on markkinapaikan tuotesivu — AutomateWoo esimerkiksi maksaa 140 € vuodessa — ja kokemuksemme mukaan päivän työ, kun taas itse rakennetussa järjestelmässä se on määrittely, tunteja ja testi, ja 50 euron tuntihinnalla se on ensimmäinen ominaisuus, jonka kohdalla kysyt, tarvitaanko sitä oikeasti; tuotteen kenttä tai uusi suodatin hallinnassa ei tähän listaan kuulu, koska ne antaa kehys. Ekosysteemin puute ei ole kertakustannus vaan pysyvästi korkeampi kynnys kaikelle, mitä myöhemmin tekisi mieli kokeilla, ja paljon kokeilevalle kaupalle se voi painaa lisenssilaskua enemmän — juuri siksi emme kutsu lisenssilaskua pääargumentiksi.

Toinen on riippuvuus yhdestä tiimistä, ja siihen vastaa rakenne eikä väite: tilaustyönä tehdyssä rakennuksessa koodi on sinun ensimmäisestä päivästä alkaen, kirjoitamme sen tavanomaisella Laravel-rakenteella ilman eksotiikkaa, kriittisellä logiikalla on testit, ja mukana tulee dokumentoitu README ja CI, jotta järjestelmän voi ottaa haltuun joku muu. Laravel-kehittäjiä on Latviassa helppo löytää, ja siksi oma vastauksemme kysymykseen, miksi Laravel, päättyy lauseeseen, ettet jää riippuvaiseksi yhdestä tiimistä, et myöskään meistä — riskiä se ei poista, mutta tekee siitä siirrettävän.

Kolmas on PCI DSS, ja se on meitä vastaan. Tammikuussa 2025 julkaistu SAQ A -versio, joka tuli voimaan 31. maaliskuuta 2025, poisti kauppiailta, joiden maksusivun toimittaa kokonaan ja suoraan PCI DSS -vaatimukset täyttävä palveluntarjoaja ja jotka ovat itse vahvistaneet, ettei sivusto ole alttiina skriptipohjaisille hyökkäyksille, vaatimukset 6.4.3 ja 11.6.1 — skriptien inventoinnin, niiden perustelun ja muutosten valvonnan — sekä vaatimuksen 12.3.1 kohdennetusta riskianalyysistä, ja totesi samalla, ettei tämä poista itse PCI DSS -vaatimuksia. Tämä helpotus kuvaa pientä WooCommerce-kauppaa pankin maksusivun kanssa paljon tarkemmin kuin kassavaihetta, jonka piirrämme omaan koodiimme, ja sen rinnalla seisoo toinen yhtä epämukava tosiasia: maaliskuun haavoittuvuuden löysi ja korjasi joku muu, mutta järjestelmässä, jonka olemme kirjoittaneet me, sen tekee meidän tiimimme, joten ylläpito on siellä sopimusrivi eikä oletus.

Meidän riippuvuutemme eivät ole eri lajia

Filament on täsmälleen samanlainen kolmannen osapuolen riippuvuus kuin ne lisäosat, joista juuri oli puhe, ja ero niiden välillä on asteen ja sijainnin ero, ei periaatteen. Se on yksi MIT-lisensoitu riippuvuus kehityskerroksessa, sen koodi on repositoriossamme ja haaroitettavissa, eikä se istu ostajan maksupolulla, koska se piirtää hallintapaneelin eikä ota maksua vastaan.

Jos projekti pysähtyisi huomenna, kauppa jatkaisi tilausten vastaanottamista, ja vanhenemaan jäisi se osa, jonka näkevät sinun työntekijäsi, ei se, joka ottaa rahaa ostajalta. Filament julkaisee myös versioiden tukitaulukon konkreettisine päivämäärineen: kolmas versio ilmestyi elokuussa 2023 ja saa tietoturvakorjauksia 1. tammikuuta 2028 asti, mikä on pidempi ikkuna kuin Laravel antaa omille versioilleen.

Filament ei silti ole Laravelin ensimmäisen osapuolen paketti, sillä Laravel ei mainitse sitä omassa pakettilistassaan, eikä projektin takana ole tasetta omaava yritys vaan tiimi yhden ylläpitäjän ympärillä: hänen nimissään on repositoriossa noin 17 000 muutosta, seuraavalla osallistujalla noin 2 400, ja rahoitus tulee GitHub-sponsoreilta ja maksullisista konsultoinneista. Julkaisutahtikaan ei ole lempeä: neljäs versio ilmestyi elokuussa 2025, viides jo tammikuussa 2026, kaksi päivää Livewire 4:n jälkeen, joka on vielä yksi kolmannen osapuolen riippuvuus sen alla. Ja lause ”haaroitamme sen tarvittaessa” on halpa kirjoittaa ja kallis toteuttaa.

Emme tarjoa kauppaa ilman kolmannen osapuolen riippuvuuksia, koska sellaista ei ole meillä eikä kenelläkään muullakaan; tarjoamme niitä pienemmän määrän, lisenssin, joka sallii koodin pitämisen ja ylläpitämisen itse, ja selvän rajan sen välillä, mikä vikatilanteessa pysäyttää rahavirran ja mikä pilaa työntekijän työpäivän. Jos tämä ero ei sinusta ole riittävän suuri, se on täysin perusteltu vastaväite — ja silloin rakennamme sinulle valmiin työkalun, koska se on sama Basic- tai Pro-versio samaan hintaan. Kumpikaan vastaus ei tee meistä väärää kumppania.

Miten teemme tämän valinnan käytännössä

Alustan mukana ostat vastauksen yhteen kysymykseen — kuka saa muuttaa hinta- ja tilaussääntöjäsi ja millä aikataululla —, ja omalla koodilla tämä vastaus on ”sinä, seuraavassa sprintissä”, kun taas toisen valmistajan lisäosan päällä se on ”kun valmistaja ottaa sen julkaisuunsa, jos ottaa”. Siksi kartoituskeskustelussa emme kysy liikevaihtoa vaan sitä, montako hintaporrasta sinulla todellisuudessa on ja näkeekö yksi asiakas joskus eri hinnan kuin toinen — siinä kulkee raja kahden hintakentän, jotka WooCommerce antaa itse, ja hintataulun välillä, jota jonkun on ylläpidettävä.

Sitten kysymme, elääkö saldo useammassa kuin yhdessä paikassa, sillä varasto ja kaupan hylly ovat jo kaksi paikkaa, ja kaksi paikkaa tarkoittaa, että jonkun on päätettävä, kumpi niistä on totuus. Seuraavat kaksi kysymystä ratkaisevat yleensä kaiken: tuleeko tilauksesta tilaus heti vai tarvitseeko se ensin hyväksynnän — asiakkaan hankintaosastolta, sinun myyntipäälliköltäsi tai luottorajalta — ja toimisiko prosessi myös silloin, jos tuoteluettelo kaksinkertaistuisi.

Jos vastaus hyväksynnästä on ”kyllä”, olet siinä kohdassa, jossa valmiiden lisäosien markkina on heikoimmillaan: luottorajojen valvonta ja rajan ylittävien tilausten estäminen ei ole ytimessä eikä yleisimmissä B2B-paketeissa, ja sitä lupaavat vain muutamat erikoistuneet tuotesivut, esimerkiksi QuarkCode B2B Commerce Suite. Kuinka paljon prosessista olet valmis muokkaamaan työkalun mukaan — se on kysymys, joka jää jäljelle, ja epäselvät vaatimukset ovat koko hankinnan kallein virhe, josta olemme kirjoittaneet erikseen.

Jos vastaukset mahtuvat valmiiseen työkaluun, ota valmis työkalu, koska se tulee halvemmaksi, ja rakennamme sen sinulle me. Jos yksi tai kaksi ei mahdu, olet todennäköisesti keskimmäisellä tiellä, ja hinnastossa sitä vastaa sama 9 500 euron Pro-versio WooCommercen päällä — sama hinta kuin Laravelilla, koska maksaa työ eikä alusta. Jos kolme tai useampi ei mahdu, ja aivan erityisesti jos joukossa on hyväksyntävaihe tai luottoraja, keskustelu ei enää koske alustaa vaan sitä, kuinka suuri osa prosessista asuu koodissa, jota voimme muuttaa sopimatta siitä toisen valmistajan kanssa.

Kolme aloitustapaa ja mitä kukin maksaa

Käytännössä myymme kolmea aloitustapaa, ja jokaisella on hinta, jonka voi laskea: ensimmäinen on aloittaa tuoteluettelosta, maksuista ja toimituksesta, mennä tuotantoon ja lisätä B2B-hinnat, alennuslogiikka ja varastointegraatiot vasta sitten, kun ensimmäiset todelliset tilaukset ovat näkyvissä — omissa vastauksissamme kutsumme tätä yleensä oikeaksi valinnaksi. Toinen on siirtää olemassa oleva kauppa, ja se on projekti eikä kytkin: URL-rakenteen säilytämme, mutta tietomallit eivät osu yksi yhteen, ja jokainen lisäosa, joka on säilönyt omia kenttiään, on arvioitava erikseen. Pro-versiossa ja vuokrassa siirto sisältyy hintaan; Basic-versiossa sitä ei ole, ja sen arvioimme erikseen laajuuden mukaan, koska hinnan ratkaisevat tietomäärä ja kenttien lukumäärä.

Kolmas on vuokra: Laravel-kauppa yhdessä hostingimme kanssa alkaen 130 € kuukaudessa plus 600 euron kertaluonteinen käyttöönottomaksu, ja hinnastossa sen sisältö on sama kuin Pro-versiossa — varastomoduuli, monikielisyyden tuki, B2B-hintaportaat, alennusjärjestelmä ja sisällön siirto —, vain hosting, päivitykset ja ylläpito päälle laskettuina; saatavilla se on ainoastaan Laravelilla, sillä WooCommerce-kauppaa ei meiltä voi vuokrata. Alustan valinta itsessään ratkaisee muutaman konkreettisen asian, joita työ ei tasoita: tämän vuokrarivin, maksuttomat automaattiset ytimen korjauspäivitykset, ekosysteemin kynnyksen ja sen, kenen on suostuttava, ennen kuin seuraava muutoksesi menee tuotantoon. Kaikki muu on työtä.

Vuokra alkaa 130 eurosta kuukaudessa, mikä on viidessä vuodessa alkaen 7 800 €, plus 600 euron käyttöönotto — alkaen 8 400 € —, ja siihen sisältyvät hosting, päivitykset ja ylläpito. Pro-versio maksaa 9 500 € kertaluonteisesti, ja hosting tulee sen rinnalle erikseen: infrastruktuurin vuokramme alkaa 45 eurosta kuukaudessa eli 2 700 eurosta viidessä vuodessa, yhteensä alkaen 12 200 €, eivätkä sovelluksen päivitykset ole vielä siinä mukana. Molemmat luvut ovat lattioita eivätkä loppusummia, ja vertailukelpoisia ne ovat siksi, että hinnastossa kummankin sisältö on sama. Vuokrassa maksat käytöstä yhdessä hostingin kanssa, rakentamisessa maksat järjestelmästä kerralla, ja lattioita vertaillessa vuokra alkaa viiden vuoden ikkunassa matalammalta. Sen, mihin kumpikin päättyy, ratkaisee laajuus, joten kummankin arvioimme projektille emmekä lue hinnastosta.

Siitä eteenpäin työ etenee kahden viikon sprinteissä, joista jokaisen päätteeksi on demo; maksut, toimituspalvelut ja kirjanpidon kytkemme ja testaamme ennen julkaisua; tuotteet, asiakkaat ja tilaushistorian siirrämme URL-rakenteen säilyttäen. Vakiosta poikkeavat suuremmat työt teemme aika- ja materiaaliperusteisesti viikkokatolla, koska kiinteä hinta tarkoittaa siellä yleensä joko riskilisää tai riitaa laajuudesta, ja tuntihinta on hinnastossa 50 €. Koko matka kestää 8–32 viikkoa. Pyydä projektiarvio ja teknologiasuositus — vastaa samoihin kysymyksiin meille, niin kerromme, mikä kolmesta tiestä tulee sinun tapauksessasi halvimmaksi.