Mobilemeny

Blogg | 24 mars 2026

Färdig modul eller egen lösning? Så väljer du rätt

I den här bloggen delar Oskar Åkerlund, Tech Lead på Consid, sina insikter kring ett vanligt vägval i många organisationer – ska du använda en färdig lösning eller bygga något eget? Med konkreta perspektiv som hjälper dig fatta mer genomtänkta beslut.

I Sitevision finns det ofta en färdig lösning när behovet dyker upp. Men ibland lockar tanken på att bygga något helt eget. Så hur vet vi vad som är rätt väg? Svaret är sällan svart eller vitt, men det finns några avgörande frågor som hjälper oss att välja rätt.

En av de stora fördelarna med Sitevision som plattform är det breda bibliotek med färdiga moduler som ingår – standardmoduler som täcker de flesta behov för ett intranät eller externwebb, byggda som perfekta bitar i det pussel som utgör plattformens ekosystem. Utöver dessa dyker ständigt nya tillägg upp i Marketplace. Att använda en färdig modul för sitt behov är lockande eftersom ansvaret på förvaltning av modulen överlåts till dess leverantör, till skillnad från en egenbyggd lösning som behöver underhållas på egen hand. Samtidigt kan en egen lösning ge större frihet i detaljerna. Som utvecklare knackar jag gärna kod och kan då leverera precis vad som önskas, men vet samtidigt att det innebär ett ansvar att modulen måste fortsätta fungera på lång sikt.

Att bygga eller inte bygga – det är (nästan) alltid frågan

Ta ett klassiskt 50/50-block: bild till vänster, text till höger. Det går utmärkt att bygga med standardmodulerna Text och Bild, styrda av en omslutande dekorationsmall. Fördelarna är många: stöd för bildtext, storlekar, formatmallar och möjligheten att lägga till en call to action.

Men om blocket kopieras ut på hundra sidor och man senare vill ändra dess layout eller funktion? Då kan en WebApp vara enklare att justera centralt, i stället för att manuellt uppdatera varje instans eller lappa med CSS.

Det är tekniskt möjligt att modifiera en färdig modul utifrån utan att ha tillgång till källkoden. Med CSS och Javascript kan vi möblera om knappar i en dialogruta efter att modulen renderats. Men ju fler sådana modifikationer vi gör, desto mer utvecklas lösningen till Frankensteins monster över tid och våra ändringar riskerar att falla sönder när modulen väl uppdateras inifrån. Är vi villiga att ta den risken, eller kan vi acceptera standardmodulen som den är?

En enkel beslutsmodell

  1. Kartlägg behovet ordentligt. Vad är det vi faktiskt vill uppnå?
  2. Finns en standardmodul som möter behovet?
  3. Kan vi acceptera mindre avvikelser? Ibland är det klokt att välja det som är nära nog. Här kan man som konsult behöva stå på sig och förklara fördelarna.
  4. Är lösningen långsiktigt förvaltningsbar? Särskilt om flera moduler byggs ihop till ett gemensamt block.
  5. Går behovet att lyfta till Sitevision? Min erfarenhet är att förbättringsförslag som gör verklig skillnad ofta tas på allvar.
  6. Utveckla egen lösning – men gör det på ett ansvarsfullt och hållbart sätt.

När egen utveckling är rätt väg

Sitevision är byggt för att vara utvecklarvänligt. Ett tydligt internt API och SDK, bra stöd för datalagring och goda integrationsmöjligheter gör det möjligt att skapa robusta lösningar. Det kan handla om att synkronisera extern data för att göra den sökbar eller använda den som underlag till en AI-assistent. Att utnyttja dessa möjligheter är också en form av ”standard” i avseende att vi arbetar inom Sitevision och slipper bygga motsvarande lösning vid sidan av.

Men med frihet kommer ansvar. När vi bestämmer oss för att utveckla en egen modul behöver vi maximera förvaltningsbarheten. Hur gör vi det? Som konsult ska jag jobba för kundens bästa, vilket även innebär att inte använda personliga utvecklarmönster och därmed låsa in kunden i en lösning som är svår att ta över. Därför bör vi hålla oss till standarden och följa best practice!

Hållbar utveckling i Sitevision

  • Gör som Sitevision själva: använd React och TypeScript.
  • Minimera tredjepartsberoenden och otillgänglig/låst kod via npm.
  • Dokumentera mera: använd din apps README-fil för att beskriva appens syfte och motivera de val du gjort. Lägg arkitektuell och kodnära dokumentation i markdown som en del av kodbasen. Det blir tillgängligt för både utvecklare och AI-assistenter.

Att följa best practice i teknikvalen gör koden enhetlig och förutsägbar. Detta tillsammans med bra dokumentation kommer även underlätta förvaltningen, oavsett om det är en människa eller AI-assistent som utvecklar koden vidare. Helst ska det inte behövas mer utveckling, utan lösningen bör vara så flexibel att den går att anpassa med konfiguration.

Maximera friheten

  • Använd Envision för det visuella och styr färg och form via temainställningarna.
  • Hårdkoda mindre. Lägg parametrar såsom antal objekt per sida, storlek, API-nycklar i konfigurationen.
  • Ta inspiration av inställningsmöjligheterna från standardmodulerna.

Sammanfattning

Det finns ingen universallösning när du väljer mellan färdig modul och egen lösning, de är båda bra val i olika situationer. Börja med att leta efter färdiga alternativ, det sparar ofta både tid och energi. Men tveka inte att bygga eget när det verkligen skapar värde – gör det bara på ett sätt som håller över tid. För det är inte den mest intrikata lösningen som vinner i längden utan den som fortfarande fungerar om tre år.

Oskar Åkerlund, teknisk leder hos Consid og Sitevision MVP. 

Se hur din digitala upplevelse kan se ut

I en kostnadsfri demo visar vi hur Sitevision hjälper dig att skapa precis den digitala upplevelse du behöver med rätt byggstenar redan på plats. Utforska plattformen, prova själv och upptäck hur enkelt det kan vara att skapa något kraftfullt.

Prenumerera på vårt nyhetsbrev

Du får information om nya funktioner i Sitevision, vad som händer hos oss och en hel massa tips. Syftet? Att göra ditt arbete smartare, smidigare och roligare.

Följ oss på

LinkedIn

Facebook

Instagram

Instagram

Youtube

YouTube

Certifikat ISO/IEC 27001:2022

Certifikat ISO/IEC 27001:2022