Spring til indhold

Viden · Plugin-fælden vs. custom udvikling

Plugin vs. custom udvikling

Plugin-fælden.

Hvert plugin på en e-handelsplatform præsenterer sig som et lille, harmløst værktøj. Tilsammen udgør de en arkitektur, bare ikke en, nogen har tegnet. Det er den arkitektur, der bestemmer din loadtid, din sikkerhed og din fleksibilitet.

Regnestykket

20+ abonnementer er ikke et setup. Det er en fast, voksende udgift.

Det begynder med tre plugins. Et til fragt, et til faktura, et til anmeldelser. Et år senere er der atten, og to år senere er der treogtyve, fordi hvert problem har fået sit eget abonnement i stedet for en løsning. Regningen er ikke de enkelte beløb, den er summen, og den vokser i samme takt som forretningen, fordi flere apps lægger flere funktioner ovenpå.

Dertil kommer den usynlige del: den månedlige udgift er kun licensen. Den faktiske pris inkluderer tiden brugt på fejlfinding mellem integrationer, de opdateringer der skal testes, de konverteringer der forsvinder i den ekstra vægt, og den fleksibilitet, man betaler for ved ikke at kunne ændre noget uden at spørge en leverandør.


Bloat

Hvordan platformen bliver tung: assets på hver side.

Et plugin leverer ikke kun den funktion, du købte. Det leverer sit stylesheet, sit script, sine ikoner, sine API-kald og ofte sin egen version af et bibliotek, der allerede findes på siden. En stor del af den kode bliver indlæst globalt, på forsiden, i kategorierne, i kassen, uanset om funktionen kun bruges ét sted.

Sådan ser det ud i praksis

  • En anmeldelses-app, der indlæser 90 kB JavaScript på alle sider for at vise stjerner på produktkort.
  • Et loyalitets-plugin, der kalder sin egen server på hvert sidevis, selv når kunden ikke er logget ind.
  • To apps, der hver især indlæser deres egen version af samme graf-bibliotek.
  • En chat-widget, der starter tre netværkskald, før siden er interaktiv.

Regnestykket er til at måle. Tag en produktside, der i dag bruger 1,8 sekunder på mobil. Slå de tredjeparts-assets fra, der ikke bruges på netop den side, og mål igen. Det er ikke usædvanligt at finde 300-500 millisekunder og en betydelig del af DOM’en, der aldrig havde et ærinde der. Gang det med hver sidevisning i en måned, og det er den tid, dine kunder har stået i kø, i gennemsnit.

Ingen af dem er en fejl. De er bare ikke tænkt som en samlet side. Resultatet er en platform, hvor hver ny funktion gør hver side lidt langsommere, også de sider, kunden faktisk skal købe fra.


Konflikter

Kode-konflikter: når to plugins rører ved det samme.

Plugins mødes ikke i et design, de mødes i kode. De samme hooks, de samme felter i kassen, de samme beregninger af moms og fragt. Når to leverandører uafhængigt af hinanden ændrer på samme funktion, er resultatet ikke en fejl, nogen har skrevet, det er en fejl, der opstår mellem dem.

Det klassiske forløb: en plugin-opdatering ændrer rækkefølgen, et felt tilføjes i kassen, og en anden integration læser feltet forkert. Ingen af de to leverandører kan genskabe fejlen, fordi den kun findes i kombinationen. Imens står forretningen med en kasse, der afviser bestemte ordrer på bestemte tidspunkter, den sværeste slags fejl at finde, fordi den sjældent kan fremkaldes med vilje.


Sikkerhed

Angrebsfladen vokser med hver integration.

Hvert tredjeparts script kører på dit domæne, i din kundes browser, med adgang til det, der ligger på siden. Nogle af dem får også API-nøgler eller læseadgang til ordredata. Det gør ikke leverandørerne til modstandere, men det gør dem til en del af din angrebsflade, og den del bliver sjældent revideret, fordi den ikke står i nogen oversigt over “vores systemer”.

Dertil kommer livscyklussen: apps, der holder op med at blive vedligeholdt, ændrer ejerskab eller lukker. En integration, der var sikker for to år siden, er ikke nødvendigvis sikker i dag, og spørgsmålet “hvem har adgang til hvad, og hvorfor?” kan sjældent besvares uden at gennemgå tyve dashboards.


Kodebasen

Hvad et rent, skræddersyet system betaler tilbage.

Et system, hvor funktionerne er bygget til forretningen i stedet for købt, har færre bevægelige dele. Der er én kodebase at forstå, én leverandørrelation, nemlig ingen, og ingen tredjepart, der kan ændre din checkout natten over. Koden ligger på din platform, er dokumenteret, og kan ændres i morgen uden at vente på en roadmap eller betale for en ny plan.

Det betyder ikke, at alt skal bygges selv. Betalingsgatewayen, fragtleverandøren og regnskabssystemet er og bliver eksterne. Pointen er, hvor grænsen går: det, der gør din forretning speciel, købsflowet, priserne, loyalitetslogikken, dataflowet, bør du eje. Friheden er ikke at kunne bygge alt selv. Friheden er at vide præcis, hvad der kører i maskinrummet, og kunne ændre det uden at spørge nogen om lov.

Hvor meget koster dine integrationer egentlig?

Send os din URL. Vi gennemgår dine apps og scripts, beregner den reelle udgift og viser, hvad der kan erstattes af kode, du selv ejer.

Gratis analyse