Att välja webbyrå är ett leverantörsbeslut som kan påverka företagets marknadsföring, försäljning och teknik i flera år. Den billigaste offerten kan bli dyr om ni blir beroende av leverantören för varje ändring, medan den dyraste byrån inte automatiskt ger bäst affärsresultat.

En bra upphandling börjar därför med mål, ansvar och ägande – inte med designförslag. När flera byråer får samma underlag blir det också möjligt att jämföra dem på verklig leverans i stället för på olika paketnamn.

1. Definiera vad webbplatsen ska åstadkomma

Skriv först ned webbplatsens viktigaste affärsuppgifter. Exempel:

  • skapa kvalificerade leads,
  • sälja produkter eller tjänster,
  • driva bokningar,
  • stötta befintliga kunder,
  • rekrytera,
  • bygga organisk synlighet,
  • minska manuellt administrativt arbete.

Välj några få mätbara mål. En webbplats som ska generera leads behöver andra prioriteringar än ett digitalt magasin eller en självserviceportal.

2. Skilj krav från önskemål

Dela kravspecifikationen i tre nivåer:

  • Måste: funktioner utan vilka projektet inte fungerar.
  • Bör: viktiga funktioner som kan prioriteras efter budget.
  • Kan: förbättringar som kan läggas i fas två.

Det minskar risken att projektet växer under offertfasen och gör leverantörernas priser mer jämförbara.

3. Beskriv omfattningen konkret

Ett bra underlag bör ange:

  • ungefärligt antal sidtyper,
  • språk,
  • formulär och bokningsflöden,
  • e-handel eller betalning,
  • inloggning eller kundportal,
  • integrationer,
  • data- och innehållsmigrering,
  • SEO-migrering,
  • analys och konverteringsmätning,
  • vem som producerar text, bild och video.

Be samtliga byråer prissätta samma basomfattning. Extrafunktioner kan sedan jämföras separat.

4. Välj rätt typ av byrå

Alla webbyråer har inte samma profil. Vanliga modeller är:

  • design- och varumärkesbyrå: stark på identitet, UX och visuellt uttryck,
  • utvecklingsbyrå: stark på komplex funktionalitet och integrationer,
  • fullservicebyrå: kombinerar strategi, design, utveckling och marknadsföring,
  • specialistbyrå: fokuserar på exempelvis e-handel, WordPress, Shopify eller headless,
  • mindre studio/frilansnätverk: kan ge nära samarbete och lägre overhead men större personberoende.

Välj profil efter projektets största risk. Om den svåra delen är integrationsarkitektur ska ni inte välja en leverantör enbart för att deras designportfolio är snygg.

5. Be om relevanta case – inte bara en portfolio

Be om projekt som liknar ert i mål eller komplexitet och fråga:

  1. Vad var kundens ursprungliga problem?
  2. Vilken del gjorde byrån själv?
  3. Vilka integrationer eller migreringar ingick?
  4. Vad förändrades efter lansering?
  5. Vilka delar blev svårare än planerat?
  6. Kan ni prata med kunden som referens?

En bild på en snygg startsida säger lite om hur projektledning, SEO, support eller teknisk kvalitet fungerade.

6. Ta reda på vem som faktiskt gör arbetet

Be om roller och ungefärlig bemanning. Det kan exempelvis vara:

  • projektledare,
  • UX/UI-designer,
  • frontendutvecklare,
  • backendutvecklare,
  • SEO-specialist,
  • analytiker,
  • copywriter eller redaktör.

Fråga vilka delar som görs av anställda, underleverantörer eller frilansare och om teamet ni träffar under säljmötet också är teamet som levererar.

7. Bedöm projektledningen

En bra teknisk leverantör kan ändå ge ett dåligt projekt om kommunikationen är svag. Fråga hur byrån arbetar med:

  • veckostatus,
  • beslut och godkännanden,
  • risklista,
  • förändringsönskemål,
  • test och acceptans,
  • förseningar och beroenden.

Ni bör veta vem som fattar beslut på båda sidor och hur blockerare eskaleras.

8. Kräv en demo av CMS innan avtal

Be byrån visa hur en redaktör faktiskt:

  • ändrar text och bilder,
  • skapar en ny sida,
  • ändrar navigation,
  • uppdaterar metadata,
  • lägger till en tjänst eller produkt,
  • förhandsgranskar och publicerar.

Ett CMS som kräver utvecklare för varje normal ändring skapar löpande kostnad och leverantörsberoende.

9. Ägande ska vara tydligt från början

Avtalet bör uttryckligen beskriva vem som äger eller kontrollerar:

  • domännamn,
  • hostingkonto,
  • CMS-konto,
  • kod och repository,
  • designfiler,
  • text och media,
  • analyskonton,
  • Search Console,
  • annonskonton,
  • integrationernas API-konton,
  • kund- och formulärdata.

Företaget bör ha administrativ åtkomst till centrala konton och kunna byta leverantör utan att behöva köpa tillbaka sin egen infrastruktur.

10. Repository och teknisk dokumentation

Om projektet innehåller egen kod bör ni veta var koden lagras och vem som har åtkomst. Be även om dokumentation för:

  • lokal utvecklingsmiljö,
  • deployprocess,
  • miljövariabler och hemligheter,
  • integrationer,
  • backup och återställning,
  • viktiga schemalagda jobb.

Hemligheter ska förstås inte ligga öppet i dokument, men processen för att administrera dem ska vara beskriven.

11. SEO måste planeras före en ombyggnad

Vid redesign eller migrering bör byrån kunna förklara hur befintlig organisk synlighet skyddas. Viktiga delar är:

  • inventering av befintliga URL:er,
  • beslut om vilka sidor som ska behållas, slås ihop eller tas bort,
  • 301-redirects från gamla till nya relevanta URL:er,
  • canonical-signaler,
  • metadata och rubrikstruktur,
  • internlänkar,
  • XML-sitemap,
  • robots och indexering,
  • kontroll i Search Console efter lansering.

Google rekommenderar att företag frågar SEO-leverantörer hur de arbetar, vilka resultat som realistiskt kan förväntas och undviker aktörer som garanterar förstaplats. Se Google Search Central: Do you need an SEO?.

För kostnadsdelen, läs även vad kostar SEO 2026?.

12. Fråga hur AI-sök hanteras utan hype

En modern byrå bör förstå AI Overviews och generativa sökresultat, men bör kunna förklara hur arbetet bygger på teknisk SEO, unikt innehåll och användarnytta snarare än obevisade genvägar.

Se GEO vs SEO 2026 för vad Google faktiskt rekommenderar.

13. Analys och konverteringsmätning

Bestäm före utvecklingen vilka händelser som ska mätas. Exempel:

  • skickade formulär,
  • bokningar,
  • köp,
  • telefonklick,
  • nedladdningar,
  • registreringar.

Be byrån beskriva vem som implementerar mätning, vem som kvalitetssäkrar den och hur samtyckeshantering påverkar datainsamlingen.

14. Integritet och samtycke

Om webbplatsen använder analys, annonsering eller andra tredjepartstjänster behöver ni förstå vilka data som samlas in och vilka system som sätts innan samtycke. Juridiskt ansvar bör bedömas utifrån er verksamhet och aktuella krav, men den tekniska implementeringen ska inte vara en eftertanke.

Be leverantören dokumentera vilka externa tjänster, cookies och scripts som ingår.

15. Tillgänglighet

Tillgänglighet bör byggas in i design och komponenter, inte läggas på precis före lansering. Fråga hur byrån arbetar med:

  • tangentbordsnavigation,
  • kontraster,
  • rubrikstruktur,
  • formulärfel och etiketter,
  • alt-texter och media,
  • testning med relevanta hjälpmedel.

Vilka rättsliga krav som gäller beror på verksamhet och tjänst, men god tillgänglighet förbättrar användbarheten oavsett.

16. Integrationer och API:er

För varje integration bör offerten ange:

  • vilket system som är master för datan,
  • vilka fält som synkroniseras,
  • hur fel hanteras,
  • om synkronisering sker direkt eller i kö,
  • vem som ansvarar om ett externt API ändras,
  • eventuella löpande licenskostnader.

En integration som bara beskrivs som ”koppling mot CRM” är för vag för att prissättas säkert.

17. Innehållsmigrering

Om hundratals sidor ska flyttas behöver ni besluta vad som ska:

  • migreras automatiskt,
  • redigeras manuellt,
  • slås ihop,
  • arkiveras,
  • redirectas.

Flytta inte allt gammalt innehåll bara för att det existerar. En migrering är ett bra tillfälle att minska duplicering och teknisk skuld.

18. Drift, hosting och support

Be om en tydlig ansvarsmatris för:

  • hosting,
  • systemuppdateringar,
  • backup,
  • återställning,
  • övervakning,
  • SSL/certifikat,
  • säkerhetsincidenter,
  • supportärenden,
  • plattformens licenser.

Fråga också vad som händer kvällar och helger om webbplatsen är affärskritisk.

19. SLA och supportmodell

Ett supportavtal bör skilja mellan prioriteringar. Exempelvis är en helt otillgänglig checkout något annat än en kosmetisk layoutbugg.

Be om:

  • supportkanal,
  • supporttider,
  • responsmål per prioritet,
  • vad som räknas som incident respektive vidareutveckling,
  • timpris eller inkluderad kapacitet.

20. Säkerhet och behörigheter

Byrån bör kunna förklara hur administratörskonton, flerfaktorsautentisering, uppdateringar, backup och principen om minsta behörighet hanteras.

För känsliga eller affärskritiska system kan ni behöva separat säkerhetsgranskning och krav utifrån verksamhetens risknivå.

21. Projektpris, löpande eller time-and-material?

Fast pris fungerar bäst när scope är tydligt. Time-and-material ger mer flexibilitet när lösningen ska utvecklas iterativt. En hybrid kan ha fast pris för en definierad bas och löpande budget för förändringar.

Oavsett modell måste ni veta hur ändringar godkänns och prissätts.

22. Räkna total ägandekostnad

Jämför inte bara projektpriset. Räkna även tre års möjliga kostnader för:

  • hosting,
  • licenser,
  • support,
  • säkerhets- och systemuppdateringar,
  • löpande utveckling,
  • SEO och innehåll,
  • integrationstjänster,
  • eventuella transaktionsavgifter.

Ett billigare projekt kan bli dyrare om plattformen kräver stora löpande avgifter eller all redigering måste köpas från byrån.

23. Förändringsönskemål och scope creep

Projektet bör ha en enkel process för change requests:

  1. önskemålet dokumenteras,
  2. påverkan på tid och kostnad uppskattas,
  3. kunden godkänner eller avstår,
  4. ändringen läggs in i planeringen.

Det skyddar både kund och byrå från att muntliga småändringar gradvis förvandlar projektet.

24. Test och acceptanskriterier

Definiera vad som måste fungera innan lansering. Exempel:

  • kritiska formulär,
  • betalning,
  • integrationer,
  • mobilvisning,
  • redirects,
  • indexeringsinställningar,
  • analys,
  • backup och återställningskontroll.

En tydlig acceptanslista minskar diskussionen om när projektet faktiskt är klart.

25. Handover om ni byter leverantör

Avtalet bör beskriva vad som lämnas över vid avslut:

  • administratörskonton,
  • kod/repository,
  • designfiler,
  • dokumentation,
  • backup,
  • domän- och DNS-information,
  • lista över integrationer och licenser.

Undvik en modell där ett leverantörsbyte i praktiken kräver att webbplatsen byggs om från grunden.

26. Röda flaggor

  • garanterade förstaplatser i Google,
  • oklart vem som gör arbetet,
  • ingen tillgång till egna konton,
  • domänen registreras i byråns namn,
  • ingen plan för redirects vid migrering,
  • helt proprietär lösning utan export eller handover,
  • ingen backup- eller supportmodell,
  • offerten saknar tydlig scope,
  • mycket låg offert där centrala delar listas som ”tillkommer”.

27. 18 frågor att ställa innan avtal

  1. Vilka liknande projekt har ni genomfört?
  2. Vilket team arbetar med vårt projekt?
  3. Vilka delar läggs på underleverantörer?
  4. Vilket CMS rekommenderar ni och varför?
  5. Kan vi själva redigera alla normala sidor?
  6. Vem äger kod, design och innehåll?
  7. Får vi full administrativ åtkomst?
  8. Var ligger kodrepository?
  9. Hur hanteras SEO vid migrering?
  10. Vem ansvarar för redirects?
  11. Hur implementeras analys och konverteringar?
  12. Hur hanteras backup och återställning?
  13. Vilken support ingår efter lansering?
  14. Vilka löpande licenser tillkommer?
  15. Hur prissätts förändringar?
  16. Hur testas webbplatsen före lansering?
  17. Vad händer om vi vill byta leverantör?
  18. Vilka delar ingår uttryckligen inte i offerten?

28. Enkel poängmodell för att jämföra byråer

OmrådeVikt
Förståelse för affärsmål20%
Relevant teknisk kompetens20%
CMS, ägande och handover15%
Projektledning och kommunikation15%
SEO, data och migrering10%
Drift och support10%
Total ägandekostnad10%

Sätt 1–5 poäng per område och multiplicera med vikten. Modellen gör inte beslutet automatiskt, men tvingar er att jämföra samma saker.

29. En 30-dagars inköpsprocess

  1. Vecka 1: definiera mål, scope, budgetram och ansvar internt.
  2. Vecka 2: skicka samma underlag till 3–5 relevanta leverantörer och genomför möten.
  3. Vecka 3: granska case, team, CMS-demo, teknik och referenser.
  4. Vecka 4: jämför total kostnad, avtal, handover och gör slutlig riskbedömning.

För större upphandlingar kan processen förstås behöva vara längre, men ordningen är användbar även då.

30. Webbyrå och annonsering

Om byrån även erbjuder Google Ads bör ni kunna skilja mediabudget från byråarvode och förstå hur annonsdata används för att förbättra landningssidor och SEO.

Se SEO eller Google Ads 2026.

Sammanfattning

Välj webbyrå efter affärsmål, genomförandeförmåga, ägande och långsiktig kostnad – inte bara portfolio och projektpris. Kräv samma offertunderlag, be att få se CMS och teamet som faktiskt ska arbeta, planera SEO och mätning före migrering och säkra full tillgång till domän, konton, kod och data. Den bästa leverantören bygger en lösning ni kan utveckla vidare även om samarbetet en dag tar slut.