En skreddersydd nettbutikk er aktuell når måten dere selger og leverer på krever funksjoner som er vanskelige å få til i dagens oppsett. Det kan være sammensatte produkter, egne prisregler eller bestillinger som må innom flere personer før levering. Da bør vi undersøke hvor egen kode gir verdi, og hvilke deler vi kan beholde eller gjenbruke.
Hos Færder Marketing vurderer vi Astro og React for sidene kunden møter, sammen med en backend som håndterer butikkens regler og data. Det kan gi stor frihet. Den praktiske verdien ligger i at kunden får gjort oppgaven sin og at de ansatte kan behandle bestillingen riktig.
Begynn med det som er vanskelig å få til i dag
Skriv ned konkrete situasjoner: Må kunden ringe for å få riktig pris? Må ansatte registrere samme ordre flere steder? Kan et produkt selges på nett selv om en nødvendig del er utsolgt? Slike spørsmål gir et bedre beslutningsgrunnlag enn et generelt ønske om en mer moderne plattform.
Hvis dagens Shopify- eller WooCommerce-butikk løser handelen godt, kan en forbedret produktside eller én ny integrasjon være tilstrekkelig. Et nytt design krever heller ikke nødvendigvis et nytt handelssystem. Ombygging bør begrunnes i oppgaver som betyr noe for kunder, ansatte og økonomi.
Tre valg som ofte blandes sammen
Et tema bestemmer mye av presentasjonen. Handelsplattformen håndterer blant annet produkter og ordre. Utviklingsverktøyet er det vi bruker til å lage løsningen. Derfor er ikke Astro, Shopify og Lovable tre like alternativer som kan sammenlignes direkte.
- Tilpasset butikk på en etablert plattform: Vi bruker plattformens funksjoner og utvider der behovet tilsier det.
- Egen frontend med en etablert handelsplattform: Vi bygger kundesidene selv og kobler dem til plattformen. Dette kalles ofte headless.
- Egen frontend og egen handelslogikk: Vi bestemmer også produktmodellen, reglene og arbeidsflyten bak handelen, med gjenbruk av egnede biblioteker og tjenester.
En egen frontend gir frihet i presentasjonen, mens handelsplattformens datamodell og API fortsatt setter rammer. Shopify beskriver for eksempel egne API-er for produkter, handlekurv og kundekontoer i sin headless-dokumentasjon. Vi må undersøke begge delene før vi lover en bestemt funksjon.
Hvorfor vi ville vurdert Astro til en ny nettbutikk
Mange nettbutikker kombinerer lesbare produktsider, kategorier og guider med noen mer interaktive oppgaver. Astro passer godt inn i denne oppbygningen. Vi kan lage sidene med HTML og bruke React til for eksempel filtrering, sammenligning, produktvalg og handlekurv. Astro dokumenterer hvordan slike interaktive komponenter kan lastes uavhengig av resten av siden.
Astro kan også lage sider på serveren når de besøkes. Vi trenger dermed ikke bygge hele nettstedet på nytt hver gang en pris endres. Hvordan pris, lager og hurtiglagrede sider holdes oppdatert, må likevel planlegges. Se Astros dokumentasjon for serverrendering.
Astro er et mulig fundament for nettsidene. Produktadministrasjon, ordrebehandling og innlogging må også inngå i løsningen. Andre rammeverk kan gi tilsvarende frihet, og for en løsning dominert av innloggede arbeidsflater kan vi vurdere en annen oppbygning. Eierskap til koden og en gjennomtenkt datamodell betyr mer for kontrollen enn rammeverkets navn.
Et tenkt eksempel: Kunden setter sammen en seng
Tenk deg en sengeforhandler der kunden kan velge størrelse, stoff, ben, gavl og ulik fasthet på hver side. Dette er et fiktivt eksempel på en mulig løsning, ikke en beskrivelse av en lansert kundeleveranse.
En konfigurator kan vise hvilke valg som passer sammen, oppdatere bildet og forklare leveringstiden. Kunden kan lagre oppsettet, dele det med en partner og ta det med til den fysiske butikken. En ansatt kan åpne samme oppsett og hjelpe kunden videre.
Bak dette trenger vi en modell for komponenter, tillatte kombinasjoner, varenummer og tilgjengelighet. En gavl med egen lagerbeholdning er noe annet enn et tekstfelt med kundens ønske. Leverandøren må få en bestilling som kan produseres, og kundeservice må kunne se nøyaktig hva som ble avtalt.
Når ordren opprettes, lagrer vi pris og spesifikasjon slik de var ved kjøpet. Senere produktendringer skal ikke endre den historiske bestillingen. Dette er en viktig del av friheten ved egenutvikling: Vi kan forme dataene rundt den faktiske handelen.
Databasen: PostgreSQL og valget av drift
PostgreSQL er et naturlig utgangspunkt når vi skal knytte sammen produkter, komponenter, kunder, ordre og lager. Databasen støtter transaksjoner: Flere endringer i databasen kan gjennomføres samlet eller avbrytes samlet. Vi kan bruke dette til å lagre en ordre og en lagerreservasjon som én operasjon. Det krever riktig implementering og gjør ikke betalingen hos en ekstern leverandør til del av samme transaksjon. PostgreSQL forklarer prinsippet her.
Supabase er en mulig tjeneste rundt PostgreSQL, med blant annet innlogging og fillagring. Hvert prosjekt får en PostgreSQL-database. Det kan redusere arbeidet med infrastrukturen, mens vi fortsatt må definere data, tilgangsregler og butikkens funksjoner. Supabase beskriver databaseoppsettet her.
Vi kan også drifte PostgreSQL selv. Det gir mer ansvar for oppdateringer, kapasitet, overvåking og gjenoppretting. Begge alternativene lar oss lage vår egen produktmodell. Data i PostgreSQL kan flyttes, men bruk av en tjenestes egne funksjoner for innlogging, filer og integrasjoner kan gjøre en senere flytting mer omfattende.
Administrasjonen er en del av produktet
En butikk trenger arbeidsflater for å redigere produkter, bilder, kampanjer og innhold, i tillegg til å behandle ordre. Ansatte bør kunne gjøre vanlige endringer uten kodearbeid. Et ferdig redaktørverktøy kan dekke noe av behovet, mens særegne oppgaver kan få et eget grensesnitt.
Vi må også bestemme hvilket system som bestemmer pris, lager og ordrestatus. Hvis kassesystemet er kilden til lagerbeholdningen, må nettbutikken forholde seg til det. Koblinger må tåle avbrudd og vise ansatte hva som må følges opp. Da kan en feil i regnskapsintegrasjonen håndteres uten at bestillingen forsvinner.
Boxx viser hvorfor arbeidsflyten betyr noe
I arbeidet med Boxx har vi utviklet en digital opplevelse for å finne, sammenligne og bestille containere. Produkt- og depotoversikt, kjøpsveiledning og arbeidsflater for oppfølging av leverandører og transport inngår i løsningen. Slike behov gjør sammenhengen mellom kundesider og drift tydelig. Se Boxx-casen.
Boxx er utviklet med Lovable og egen kode. Det er ikke et eksempel på en Astro-butikk. Kjetil er også involvert i strategi og forretningsutvikling gjennom K28. Eksemplet viser oppbygging og funksjoner; det brukes ikke som dokumentasjon på salgsresultater eller effekten av et bestemt rammeverk.
Det som må fungere etter at kunden trykker kjøp
Betaling, lagerreservasjon, levering, kansellering og refusjon må ha tydelige tilstander og ansvar. En gjentatt betalingsmelding skal ikke opprette en ekstra ordre. Vi må kontrollere pris og produktvalg på serveren, og teste hva som skjer når to kunder forsøker å kjøpe siste vare samtidig.
Sikkerhet omfatter også hva kunder og ansatte kan se og endre, hvordan personopplysninger håndteres, og hvem som følger opp feil. Les spørsmålene dere bør stille om sikkerhet. AI kan hjelpe i utviklingsarbeidet, men erstatter ikke disse kontrollene.
Backup må dekke både database og filer, og gjenoppretting må prøves. Supabase opplyser for eksempel at databasebackup ikke inkluderer selve filene i Storage. Hvor stort datatap og hvor mye nedetid virksomheten kan tåle, må styre oppsettet. Se dokumentasjonen om sikkerhetskopier.
Frihet må vurderes sammen med kostnad og overtakelse
Egenutvikling innebærer arbeid med funksjoner en ferdig plattform allerede kan ha. Sammenlign derfor både utvikling og flere års drift: tjenesteabonnementer, vedlikehold, integrasjoner, redigering og bedriftens egen tid. Avklar kode og bruksrett, tilgang til kontoer, dataeksport og hvordan en annen utvikler kan ta over. Å ha kode i Git er bare én del av dette.
Planlegg også overgangen fra dagens butikk. Produkter, bilder, kundeinformasjon og ordrehistorikk må vurderes hver for seg. Bevar nyttige adresser eller gi dem relevante omdirigeringer. Produktinformasjon til søk og annonser, kjøpsmåling og integrasjoner må kontrolleres i den nye løsningen. Astro alene gir ingen garanti for bedre synlighet eller flere salg.
Start med én krevende bestilling
Før vi bygger hele butikken, ville vi valgt ett produkt med de vanskeligste valgene og fulgt det gjennom en fungerende prøve: produktvalg, pris, levering, testbetaling og behandling i administrasjonen. Ta også med en endring, en utsolgt del og en refusjon. Det gir et konkret grunnlag for å vurdere løsning og omfang.
Samle tre ting før første samtale: et eksempel på en vanskelig bestilling, oversikt over systemene dere bruker, og oppgavene ansatte bruker mest tid på. Bruk kundereiseartikkelen til å kartlegge helheten. Vi kan deretter vurdere hva som bør forbedres, kobles sammen eller bygges nytt som del av arbeidet med nettbutikken.
