Case: udvikling af e-handel til Meeshop, og hvornår en custom-webshop betaler sig

Denne case handler om mit arbejde med webshopudvikling for Meeshop, en dansk platform hvor virksomheder kan bygge og drive deres egen webshop. Kort fortalt: [PLACEHOLDER: én sætning om hvad du byggede eller videreudviklede for Meeshop, og hvad det betød for platformen og butikkerne på den]. Casen viser hvad det kræver at udvikle e-handel som mange butikker er afhængige af på én gang, og hvornår det betaler sig for dig at få bygget noget selv i stedet for at bruge en færdig platform.

[PLACEHOLDER: Bekræft skriftlig tilladelse fra Meeshop til navn, logo, tal og citat, og bekræft beskrivelsen af Meeshop. Uden tilladelse anonymiseres casen, og titel og slug ændres.]

Den korte version

[PLACEHOLDER: 2-3 sætninger i dine egne ord om udgangspunktet, hvad der blev bygget, og hvad det betød for Meeshop.]

Du kan læse mere om produktbeslutninger og prioritering i fra idé til SaaS: valg og prioriteringer.

Opgaven: hvad Meeshop havde brug for

Meeshop sælger en webshopløsning hvor butiksejeren designer sin shop i en editor og kobler den til de tjenester butikken skal bruge. Platformens egen side nævner MobilePay, QuickPay og Stripe til betaling, Shipmondo til fragt og Dinero til regnskab, og oplyser at platformen kan håndtere over 1.000.000 produkter pr. webshop. Butikker der har brug for en særlig integration, kan ifølge siden også få den bygget.

Mit råd er at starte et e-handelsprojekt med pengene og ordrerne, ikke med designet. Hvad sker der fra kunden trykker "Betal", til varen er sendt og bogført, og hvor i den kæde kan det gå galt?

[PLACEHOLDER: Udgangspunktet. Hvad var behovet eller problemet, og hvordan blev det løst før du kom ind i projektet?]

[PLACEHOLDER: Hvordan du kom ind i projektet, hvad du stod for, og hvad første leverance skulle kunne. Prosa i første person.]

Hvad software til e-handel skal kunne holde til

En webshop til én virksomhed er et afgrænset system. En platform hvor mange butikker kører på den samme kode, stiller andre og hårdere krav:

• Butikkerne skal holdes adskilt. Produkter, kunder, ordrer, design og domæne hører til én butik, selvom alt ligger i samme system. Det kaldes multi-tenancy (flere kunder på samme installation), og en fejl her kan vise én butiks data hos en anden.
• Hver butik vælger sine egne integrationer. Én bruger MobilePay og Shipmondo, en anden Stripe og et helt andet fragtfirma, hver med egne nøgler og aftaler.
• Hver udgivelse rammer alle. En ny version af platformen går ud til alle butikker på én gang, også til den der har kampagne samme dag.

Dertil kommer lovkrav som den enkelte butik ikke selv kan løse i koden. EU's tilgængelighedsdirektiv omfatter e-handelstjenester leveret til forbrugere efter 28. juni 2025, mens mikrovirksomheder der leverer tjenester er undtaget efter direktivets artikel 4. På en platform afhænger meget af skabeloner, editor og checkout, som butiksejeren ikke selv kan rette i. Det er min læsning som udvikler, ikke juridisk rådgivning.

[PLACEHOLDER: Hvilke af disse krav fyldte mest i dit arbejde for Meeshop?]

De vigtigste beslutninger i projektet

Fire valg går igen i det meste software til e-handel. Under hvert står hvorfor det betyder noget, og hvad Meeshop valgte.

En ordre må aldrig forsvinde

Selve betalingen sker hos en betalingsudbyder, og webshoppen får besked bagefter via en webhook (en automatisk besked fra udbyderens system til dit). Stripe skriver i sin dokumentation at den samme hændelse indimellem kan blive leveret mere end én gang, at rækkefølgen ikke er garanteret, og at fejlede leveringer i drift bliver forsøgt igen i op til tre dage.

Derfor skal en ordre have klare tilstande som oprettet, betalt, sendt og refunderet, og hver besked skal kunne behandles to gange uden at kunden får to ordrebekræftelser, lageret bliver talt ned to gange, eller der bliver bestilt to fragtlabels. Samme princip går igen i casen om webløsninger til fiber- og teleselskaber, hvor en bestilling heller ikke må gå tabt.

[PLACEHOLDER: Hvordan betaling og ordreflow var løst hos Meeshop, og om en bestemt betalingsudbyder gav særlige udfordringer.]

Integrationer bag et fælles lag

Når en platform taler med flere betalingsudbydere, fragtfirmaer og regnskabsprogrammer, bør resten af koden ikke vide hvilken der er i brug. Jeg anbefaler et fælles lag hvor hver integration er en adapter: platformen beder om "opret betaling" eller "bestil fragt", og adapteren oversætter til den enkelte udbyder. Så kan en ny udbyder komme til, eller en gammel skiftes ud, uden at ordreflowet skal skrives om.

Fejl i én integration må heller ikke vælte resten. Er regnskabsprogrammet nede, skal ordren stadig gå igennem, og bogføringen sættes i kø til senere.

[PLACEHOLDER: Hvilke integrationer du arbejdede med, og hvordan de var bygget.]

Udrulning uden at forstyrre butikkerne

På en platform kan du ikke bare sætte en ny version i drift og se hvad der sker. Det kræver et testmiljø der ligner drift, automatiske tests af checkout og ordreflow, og nye funktioner der kan slås til for nogle få butikker før alle. Store ændringer hører ikke hjemme i ugen op til Black Friday.

Vil du se samme problem i et andet produkt med daglige brugere, så læs casen om nye funktioner til en medarbejderplatform i vækst.

[PLACEHOLDER: Hvordan test og udrulning foregik hos Meeshop.]

Hastighed når kataloget vokser

Langsomme produktsider viser sig først når en butik har mange varer. Import, billedbehandling og lageropdatering bør køre i baggrunden i en kø, så kunden aldrig venter på dem, og søgning i store kataloger kræver typisk et søgeindeks frem for almindelige databaseopslag.

[PLACEHOLDER: Om hastighed eller store kataloger var en del af opgaven, og hvad der blev gjort.]

Resultatet og hvad jeg ville gøre anderledes

Jeg måler en e-handelsløsning på to ting: at ordrerne går igennem hver gang, og at butiksejerne kan klare sig uden at kontakte support.

[PLACEHOLDER: Hvad blev leveret, og hvornår kom det i drift?]

[PLACEHOLDER: Målbare resultater som Meeshop har godkendt, fx butikker, ordrer, hastighed eller færre supporthenvendelser.]

[PLACEHOLDER: Evt. citat fra Meeshop med navn og titel, kun med skriftlig tilladelse.]

[PLACEHOLDER: Én eller to ting du ville gøre anderledes i dag, og hvorfor. Prosa, gerne med det der gik galt.]

Hvornår custom e-handel betaler sig

Meeshop er i sig selv et godt argument for ikke at bygge din egen webshop fra bunden. Færdige platforme har allerede løst kurv, betaling, moms, fragt, rabatkoder og ordremails, og de bliver vedligeholdt løbende. For de fleste butikker er det rigtige svar at vælge en af dem og bruge pengene på varer og markedsføring.

Min tommelfingerregel har tre trin:

1. Sælger du almindelige varer til forbrugere, så brug en færdig platform.
2. Skal butikken tale med dit økonomisystem, lager eller ERP-system, eller have et særligt bestillingsflow, så byg en integration eller en app oven på platformen.
3. Er e-handlen selve produktet, fx en webshopplatform, en bestillingsportal til erhvervskunder med egne aftaler, eller salg der hænger tæt sammen med booking, abonnementer eller en kundeportal, så kan custom-udvikling betale sig.

Priser og gebyrer for de tre veje finder du i guiden Shopify, WooCommerce eller custom-webshop.

Hvornår du ikke skal hyre en udvikler som mig

Skal du bare have en butik i luften med et pænt tema og standardbetaling, er en udvikler til custom-løsninger det forkerte valg. Det bliver dyrere og langsommere end at gøre det selv eller hyre en partner der kender netop den platform. Ved du endnu ikke om dine varer sælger, så test markedet på en færdig løsning, og byg først noget eget når du kender dine tal og flaskehalse.

Næste skridt

Overvejer du en e-handelsløsning der skal kunne mere end en standardplatform, så start med at beskrive hvordan du sælger, og hvilke systemer en ordre skal igennem. Du behøver ikke en kravspecifikation. Større projekter starter hos mig med et betalt forprojekt til fast pris, hvor opgaven bliver afgrænset og prissat, og du ejer koden fra første dag.

Du kan læse hvordan et projekt med mig forløber fra første opkald til lancering, eller se hvad jeg tilbyder inden for udvikling af webapps og platforme.

Ofte stillede spørgsmål

Hvad koster det at få udviklet en custom-webshop?+

Det afhænger af omfanget, og et seriøst bud kræver at opgaven er afgrænset først. De største prisdrivere er antallet af integrationer, prisregler for erhvervskunder og hvor meget data der skal flyttes fra den gamle løsning. En integration til en eksisterende platform koster typisk en brøkdel af en fuld custom-webshop. Derfor starter jeg større projekter med et betalt forprojekt til fast pris.

Kan jeg starte på en standardplatform og skifte til custom senere?+

Ja, og det er ofte den klogeste rækkefølge. Sørg fra start for at du kan eksportere produkter, kunder og ordrehistorik, og at domæne og betalingsaftale står i dit navn. Når du skifter, skal gamle produkt-URL'er viderestilles til de nye, ellers risikerer du at miste placeringer i Google. Planlæg skiftet uden for din travleste sæson.

Hvor lang tid tager det at udvikle en custom-webshop?+

Regn med måneder, ikke uger. En første version med katalog, kurv, betaling, ordrehåndtering og én integration tager tid at bygge og især at teste, fordi fejl i betaling og ordrer er dyre. Integrationer til eksisterende systemer og flytning af data er de dele der oftest trækker ud. Et forprojekt giver dig en realistisk tidsplan før du forpligter dig til hele opgaven.

Hvem ejer koden og kundedata i en custom-webshop?+

Det gør du. Hos mig ejer kunden koden fra første dag, og den bør ligge i et repository (kodearkiv) som din virksomhed har adgang til. Kundedata og ordrer er dine, og som butiksejer er du som udgangspunkt dataansvarlig efter GDPR. Konti hos betalingsudbyder, fragtfirma og hosting bør også stå i virksomhedens navn, så du kan skifte udvikler uden at starte forfra.