Ett webbprojekt försenas sällan av kodningen ensam. Här får ni en realistisk tidsplan och ser vilka interna beslut och leveranser som avgör lanseringsdatumet.
Har webbyrån verkligen rätt när den lovar en ny företagswebb på åtta veckor? Det raka svaret är att en normal SME-webb 2026 oftast behöver 10–16 kalenderveckor, även när själva designen och utvecklingen ryms inom åtta produktionsveckor. AI, komponentbibliotek och moderna utvecklingsverktyg har gjort vissa moment snabbare, men de skriver inte färdiga produkttexter, skapar inte CRM-behörigheter och samlar inte motstridiga synpunkter från ledningsgruppen. En webbplats kan därför kräva åtta veckors aktiv produktion men ta fjorton veckor att lansera när innehållet anländer efter designstart, integrationspartnern saknar testkonto och varje sida väntar fem arbetsdagar på internt godkännande.
En normal SME-webb 2026 tar cirka 10–16 veckor – men bara om besluten har tydliga deadlines
En realistisk basplan avsätter omkring två veckor för målbild, krav och struktur, tre veckor för UX och visuell design, fyra till sex veckor för utveckling och integrationer samt två veckor för testning, innehållskontroll och publicering. Faserna behöver inte ligga helt efter varandra: utvecklarna kan bygga godkända komponenter medan redaktörerna färdigställer återstående sidor, men överlappningen fungerar bara om sidkarta, prioriterade budskap och tekniska förutsättningar redan är beslutade. Skillnaden mellan produktionstid och kalendertid syns tydligt när en designrevision tar fyra timmar för byrån men blockerar projektet i en vecka eftersom återkopplingen saknar deadline eller kommer från flera håll. Därför ska tidsplanen visa kundens leveransdatum för sidlista, texter, bilder, domänåtkomst, CMS-behörigheter och samlad feedback med samma precision som byråns datum för design och kod. Kräv dessutom minst en separat vecka mellan tekniskt färdig webb och publik lansering, eftersom DNS, redirects, formulärtest, cookieinställningar, analysmätning och redaktionell slutkontroll annars pressas in i lanseringsdagen.
Innehållet är ofta den kritiska linjen – inte utvecklingen
Design med platshållartext ser effektiv ut i början men skapar sena omtag när de verkliga rubrikerna blir dubbelt så långa, jämförelsetabeller saknas i komponentbiblioteket eller produktbeskrivningarna kräver en struktur som ingen har ritat. En webb med 35 URL:er är inte automatiskt ett projekt med 35 likvärdiga texter; fem sidmallar kan vara enkla att bygga samtidigt som 20 unika tjänstesidor och kundcase kräver intervjuer, faktagranskning, bildurval och godkännande från olika ämnesexperter. Börja därför med en sidinventering som skiljer mellan sidor som kan migreras, sidor som måste skrivas om, material som ska slås ihop och innehåll som bör tas bort, så att arbetsmängden blir mätbar före offert och designstart. Lås sidkarta, huvudbudskap, prioriterade CTA:er och ansvarig skribent före den visuella designen, medan metadata, internlänkar och mindre språkjusteringar kan färdigställas när sidorna redan ligger i CMS. Följ arbetet i en innehållsmatris med en rad per URL och separata kolumner för ägare, utkast, faktagranskning, juridisk kontroll, bild, SEO-fält och slutgodkännande; använd tydliga statusar som klar eller blockerad i stället för svårtolkade bedömningar som 80 procent färdig.
Integrationens svåraste fråga är vem som äger systemet på andra sidan
CRM, affärssystem, rekryteringsplattformar, betalningar och automatiserade formulärflöden bör behandlas som egna delprojekt, eftersom deras tidsplan styrs av fler parter än webbyrån. Boka ett tekniskt integrationsmöte redan under projektets första vecka med byråns utvecklare, kundens namngivna systemägare och den externa systemleverantören, och verifiera vem som kan skapa testkonton, utfärda API-nycklar, öppna brandväggar och tolka felkoder. Ett API-dokument bevisar bara att en teknisk koppling är möjlig; det säger inget om rätt behörighetsnivå finns, om testmiljön motsvarar produktion eller om personuppgifter får skickas mellan systemen på det planerade sättet. Ett formulär som lämnar leads till CRM kräver exempelvis beslut om obligatoriska fält, dubbletthantering, samtyckestext, ansvarig säljare, kvittens till besökaren och vad som händer när CRM-systemet inte svarar. Definiera samtidigt ett manuellt reservflöde, exempelvis en säker e-postkö eller kontrollerad CSV-export, så att webbplatsen kan lanseras och leads tas om hand även om en extern integration tillfälligt fallerar.
Ett samlat godkännande per fas kan kapa veckor av passiv väntetid
När vd, sälj, marknad, HR och juridik lämnar kommentarer vid olika tidpunkter blir återkopplingen fem separata arbetsköer, och en sen synpunkt kan återöppna beslut som redan har omsatts i design och kod. Låt därför en utsedd beslutsägare samla alla kommentarer i samma verktyg, reda ut interna motsägelser och lämna en prioriterad lista som byrån kan agera på utan att tolka organisationens maktordning. En praktisk modell är två arbetsdagars intern granskning följt av ett bokat beslutsmöte på 45 minuter, där fasen godkänns eller skickas tillbaka med en gemensam och avgränsad ändringslista. Om svar uteblir ska konsekvensen vara bestämd i förväg, exempelvis att lanseringsdatumet flyttas lika många dagar eller att byrån arbetar vidare från senast visad version. Dra också en tydlig lanseringsgräns: juridiska fel, trasiga flöden och blockerande tillgänglighetsproblem måste lösas före publicering, medan mindre bildbyten, enstaka formuleringar och nya önskemål läggs i en prioriterad förbättringslista efter lanseringen.
Tre sätt att synliggöra webbprojektets verkliga flaskhalsar
Verktyget bör väljas efter var väntetiden uppstår: hos beställaren, i innehållsarbetet eller mellan tekniska team. För en normal SME-webb ger följande alternativ tydligt olika styrkor.
Asana Timeline
Asana Timeline gör projektplanen begriplig för både byrå, redaktörer och beslutsfattare, vilket ökar chansen att även kundens leveranser faktiskt uppdateras där arbetet följs.
- Fungerar bra för tvärfunktionella team eftersom redaktörer och beslutsfattare kan hantera uppgifter utan att behöva förstå ett utvecklingsverktyg.
- Deadlines för underlag och samlade fasgodkännanden kan läggas som beroenden, vilket visar när kundens väntetid påverkar lanseringen.
- Beroenden flyttar inte automatiskt hela tidsplanen lika robust som i mer renodlade planeringsverktyg, så förseningar kräver aktiv uppdatering.
- Tekniska integrationer blir lätt förenklade till en enda uppgift om systemägare, testmiljö, åtkomst och acceptanskriterier inte anges uttryckligen.
Passar: SME-projekt där innehåll, design, kundbeslut och utveckling behöver samordnas i ett verktyg som även ovana beställare faktiskt använder.
Jira Advanced Roadmaps
Jira Advanced Roadmaps ger en betydligt mer teknisk vy och lämpar sig när integrationsrisker måste kunna följas från övergripande milstolpe till enskilt ärende, ansvarig och sprint.
- Ger stark spårbarhet från blockerad API-åtkomst eller en integrationsrisk ned till konkreta ärenden, ansvariga personer och planerade sprintar.
- Passar när flera utvecklingsteam eller externa systemägare påverkar den kritiska linjen och tekniska beroenden behöver följas detaljerat.
- Är ofta för tungt för innehållsägare och ledningsgrupper, vilket kan leda till att godkännanden ändå sker i mejl och förblir osynliga i planen.
- Kräver disciplin kring ärendetyper, beroenden och statusar; annars ser roadmappen exakt ut utan att spegla den verkliga beslutsprocessen.
Passar: integrationsintensiva webbprojekt där utvecklingen redan drivs i Jira och flera tekniska team eller systemleverantörer måste samordnas.
TeamGantt
TeamGantt prioriterar den visuella tidslinjen och gör det lätt för en styrgrupp att se hur sent innehåll eller ett uteblivet godkännande flyttar efterföljande aktiviteter.
- Gör den kritiska linjen pedagogisk för styrgrupp och beställare, särskilt när sent innehåll eller uteblivna godkännanden påverkar lanseringsdatumet.
- Går snabbt att sätta upp som en 10–16-veckorsplan med milstolpar för innehållslåsning, integrationsbeslut, acceptanstest och lanseringsgodkännande.
- Har svagare stöd än Jira för detaljerad felhantering, teknisk dokumentation och utvecklingsarbete som förändras från sprint till sprint.
- Planen kan ge falsk trygghet om aktiviteter markeras som klara utan definierade leveranskriterier och en namngiven mottagare som godkänner resultatet.
Passar: mindre och medelstora webbprojekt där styrning, deadlines och ett gemensamt godkännande per fas väger tyngre än avancerad utvecklingsrapportering.
För de flesta SME-webbar är Asana Timeline den bästa kompromissen eftersom kund, innehållsteam och byrå kan arbeta i samma plan. Välj Jira Advanced Roadmaps när integrationerna dominerar, och TeamGantt när den främsta utmaningen är att visa beslutsfattare hur passiv väntetid flyttar lanseringsdatumet.
Fem steg som håller webbprojektet inom 10–16 veckor
-
Sätt 48-timmarsgräns på beslut innan projektstart
Lägg designval, innehållsgodkännanden och tekniska beslut som egna uppgifter i Asana eller ClickUp med en namngiven beslutsägare och 48 timmars svarstid. Ange samtidigt vad som händer när svaret uteblir: antingen går byrån vidare med sitt rekommenderade alternativ eller så flyttas lanseringsdatumet lika många dagar. Regeln gör beslutstid till en synlig del av projektet i stället för en informell väntan mellan möten.
-
Starta innehållsarbetet två veckor före designen
Inventera befintliga sidor i Screaming Frog och samla dem i Content Snare eller GatherContent med ansvarig person, status och deadline. Prioritera de 10–15 viktigaste sidorna och kräv godkända budskap, rubriker och CTA:er innan designbyrån börjar skapa sidmallarna. Då utgår komponenterna från verkligt innehåll, medan mindre prioriterade sidor kan produceras parallellt under utvecklingen.
-
Kräv en namngiven ägare för varje integration
Skriv inte bara ”koppla CRM” i kravlistan, utan formulera en leverans som ”HubSpot: Anna Svensson, administratör, levererar testkonto och API-behörighet senast vecka 3”. Boka ett 30-minuters tekniskt möte med systemägaren före utvecklingsstart och verifiera autentisering, fältmappning, dataskydd samt tillgång till en relevant testmiljö. Om ingen person kan godkänna flödet är integrationen inte planerad, oavsett hur komplett API-dokumentationen verkar.
-
Samla återkopplingen till ett godkännande per fas
Utse en intern person som sammanställer synpunkter från ledning, sälj, marknad och andra granskare till en prioriterad lista i Figma eller BugHerd. Ge varje fas högst två granskningsrundor och ett fast godkännandedatum, så att redan fattade struktur- och designbeslut inte öppnas på nytt utan konsekvensanalys. Separata mejl från fem personer kan annars skapa en till två veckors passiv väntetid trots att byråns ändringar bara kräver några timmar.
-
Planera med en synlig kritisk linje och reservtid
Bygg tidsplanen i TeamGantt, Monday.com eller ett enkelt Google Sheet och markera beroenden mellan innehåll, design, integrationsprov, acceptanstest och publicering. Lägg in fem arbetsdagar för acceptanstest och tre dagar som lanseringsreserv för oväntade tekniska problem. Använd däremot inte bufferten för sena interna beslut, eftersom det döljer orsaken till förseningen och gör nästa deadline lika osäker.
Be webbyrån visa tidsplanen med beslutsägare, innehållsdeadlines och externa systemägare redan i offerten. När varje vänteläge har ett namn, ett datum och en konsekvens blir 10–16 veckor en styrbar plan i stället för en optimistisk uppskattning.
