Projektledning Beräknad lästid: 22 minUppdaterad

10 misstag företagare gör när de ska beställa en webbplats

Bara omkring 31 % av teknikprojekten blir klara i tid, inom budget och med ett resultat som beställaren är nöjd med. De flesta orsakerna uppstår före den första kodraden. I artikeln går vi igenom de tio vanligaste misstagen och hur du undviker dem.

Illustration: ett webbläsarfönster där en lista med kryss förvandlas till en lista med bockar — beställarens misstag och rättningen av dem.

Att beställa en webbplats är en av de investeringar som antingen kan snabba på ett företags tillväxt betydligt eller bli en dyr och frustrerande erfarenhet, som slutar i ett resultat som inte motsvarar förväntningarna, spränger budgeten och kräver en omarbetning redan efter några månader. Branschens siffror är nedslående: Bara omkring 31 % av teknikprojekten blir klara i tid, inom budget och med ett resultat som beställaren är nöjd med, och webbprojekten är inget undantag i det avseendet, eftersom webbutveckling ryms i samma statistik. Resten, ungefär två tredjedelar, klassas antingen som ”i fara” (över budget eller över tiden, eller med ett otillfredsställande resultat) eller som misslyckade. De flesta av misslyckandena har ändå ingenting med brister i tekniken eller inkompetenta utvecklare att göra — de är följden av mänskliga och organisatoriska faktorer som uppstår redan innan den första kodraden skrivs, och de går fullständigt att undvika om beställaren vet vilka misstag som görs oftast och hur de kringgås.

Här går vi igenom de tio vanligaste misstagen som företagare och organisationer gör när de beställer en webbplats, och vid varje misstag förklarar vi varför det uppstår, vad det leder till och vad du kan göra för att slippa det.

1. Att välja leverantör enbart på priset

Det här är förmodligen det vanligaste och dyraste misstaget av alla: beställaren jämför flera offerter och väljer den billigaste, i tron att en webbplats är en webbplats oavsett vem som bygger den, och att skillnaden mellan en offert på 500 € och en på 5 000 € bara är byråns vinstmarginal. I verkligheten speglar den skillnaden nästan alltid grundläggande olikheter i byggkvalitet, kodens renhet, säkerhetsnivån, utrymmet för att växa och stödet efter överlämningen, och den billigaste offerten blir ofta den dyraste lösningen i längden, eftersom kod av dålig kvalitet skapar så kallad teknisk skuld — en samling problem som kräver ständiga lagningar, begränsar hur webbplatsen kan utvecklas och till slut tvingar fram en ombyggnad från grunden.

Låga offerter döljer ofta betydande risker: byrån kan använda gratisteman eller piratkopierade teman som innehåller sårbarheter eller dold skadlig kod; koden kan vara ostrukturerad och ooptimerad, vilket gör senare förvaltning och utbyggnad svår och dyr; testerna kan vara otillräckliga, vilket betyder att felen visar sig först efter lansering; och stödet efter överlämningen kan vara minimalt eller obefintligt, så att du står utan hjälp i det ögonblick du behöver den som mest. Rätt angreppssätt är att bedöma offerterna efter värde i stället för efter pris — läs igenom byråns portfölj, tala med tidigare kunder, kontrollera den tekniska kvaliteten på de webbplatser de har byggt och ta reda på exakt vad som ingår i priset och vad som inte gör det, eftersom en ”billig” offert ofta saknar poster som är standard i en ”dyr”, till exempel responsiv design, grundläggande SEO, säkerhetskonfiguration eller utbildning av de redaktörer som ska sköta webbplatsen.

Den skillnaden är värd att räkna ut hela vägen, för det verkliga priset på en billig offert visar sig oftast först i fakturan som kommer ett och ett halvt år senare. Anta att den billiga webbplatsen håller så länge och sedan måste byggas om: för det andra bygget betalar du fullt pris — vår WordPress-utveckling börjar på 2 500 € — och till det kommer flytten av innehållet, en ny omgång texter och bilder samt de permanenta omdirigeringarna (301) från de gamla adresserna, utan vilka de placeringar i sökresultaten som byggts upp under den tiden kan försvinna tillsammans med den gamla adresstrukturen. Besparingen var alltså ingen rabatt utan en uppskjuten betalning med ränta. Och hackas webbplatsen däremellan genom en sårbarhet i ett färdigt tema eller ett föråldrat tillägg kostar en återställning enligt vår prislista 90 € i timmen exkl. moms, och den minsta arbetsinsatsen är åtta timmar. Bara det äter upp en betydande del av det som sparades in från början. Inget av detta betyder att en billig webbplats alltid är fel val: för tre sidor vars enda uppgift är att visa kontaktuppgifter och öppettider är en färdig mall ett rationellt beslut, och det säger vi också. Misstaget börjar där webbplatsen är en försäljningskanal men köps som ett visitkort.

2. Otydliga krav och mål

Det näst vanligaste misstaget är att dra igång ett projekt utan tydligt formulerade krav, mål och förväntade resultat. Beställaren kontaktar en byrå och säger något i stil med ”jag behöver en modern och professionell webbplats”, utan att kunna precisera vilka funktioner webbplatsen behöver, vem målgruppen är, vad besökarna ska göra på webbplatsen och hur framgången ska mätas. Den oklarheten tvingar byrån att göra egna antaganden om vad kunden vill ha, och antagandena visar sig ofta vara fel, vilket leder till besvikelse på båda håll och till att redan utfört arbete måste göras om, till priset av ytterligare tid och pengar. Oklarheten är också den främsta drivkraften bakom scope creep, ett fenomen som enligt PMI:s rapport från 2018 drabbade 52 % av projekten som slutförts under de föregående 12 månaderna och som innebär att nya funktioner och krav som inte fanns i den ursprungliga planen läggs till löpande under projektet, vilket höjer kostnaderna och ofta drar ut på tidsplanen betydligt.

Botemedlet är att lägga tid och kraft på en förstudie innan någon utveckling alls påbörjas — det är i det skedet konkreta affärsmål sätts (till exempel att öka antalet förfrågningar med 30 %, pressa ned avvisningsfrekvensen under 40 % eller nå en genomsnittlig sessionslängd över 3 minuter), användarpersonor tas fram, användarresor kartläggs, webbplatsens struktur och funktionella krav slås fast och en detaljerad kravspecifikation skrivs, som sedan är referensdokumentet genom hela projektet. Ett sådant dokument skyddar båda parter — beställaren vet exakt vad som ingår i priset, byrån vet vad som förväntas av den, och varje ändring som går utöver den avtalade omfattningen formaliseras som tilläggsarbete med egen budget och egen tidsplan.

Vår guide om en RAG-lösning baserad på företagets dokument hjälper dig att avgränsa ett RAG-projekt: en pilot behöver en avgränsad dokumentsamling, en användargrupp och förutbestämda acceptanskriterier, inte bara en demonstrationschatt.

3. Överskattad design och underskattad teknik

Det tredje misstaget, särskilt utbrett bland företagare, är ett överdrivet fokus på den visuella designen medan den tekniska sidan ignoreras eller underskattas. Beställaren väljer byrå enbart utifrån hur snygga webbplatserna i portföljen ser ut, utan att fråga om kodkvalitet, laddningstid, säkerhetsrutiner, skalbarhet eller SEO. Visuell design och teknisk utveckling är två skilda discipliner, och en vacker webbplats som tar tio sekunder att ladda, är sårbar för angrepp och inte går att hitta i sökmotorerna är värd betydligt mindre än en visuellt enklare webbplats som är snabb, säker och väloptimerad.

Undersökningar visar konsekvent att 53 % av mobilbesöken sannolikt avbryts om sidan tar längre än tre sekunder att ladda, och att en sekunds fördröjning i laddningstiden märkbart kan sänka konverteringen, eftersom redan 100 millisekunders fördröjning enligt en studie från Akamai och SOASTA kan sänka konverteringsgraden med 7 % — siffrorna betyder att prestandan påverkar dina intäkter direkt, och ingen snygg design i världen kompenserar för misstag i det tekniska utförandet. Rätt angreppssätt är att bedöma en byrå inte bara efter hur arbetena ser ut, utan också efter hur väl den kan förklara sitt tekniska upplägg — vilken arkitektur den använder, hur den säkrar laddningstiderna, hur den hanterar säkerhetsfrågorna och hur den tänker skala webbplatsen när verksamheten växer och kraven ändras.

4. Att skjuta upp SEO till ”sedan”

Sökmotoroptimering uppfattas mycket ofta som något som kan läggas till en webbplats när den väl är byggd, ungefär som att måla en vägg efter att huset står klart, men i verkligheten är teknisk SEO en grundläggande del av webbplatsens arkitektur, och att bygga in den efter lansering är avsevärt dyrare, krångligare och mindre verkningsfullt än att ha den med i utvecklingen från allra första början. Adresstruktur, sidhierarki, den interna länkstrukturen, rubrikstrukturen, strukturerad data (schema markup), bildoptimering, måtten i Core Web Vitals och upplevelsen i mobilen — allt det är långt enklare och billigare att göra rätt under utvecklingen än att bygga om på en färdig webbplats.

Google indexerar med mobilen först, vilket betyder att det är mobilversionen av din webbplats som Google bedömer och rangordnar ditt innehåll efter — är upplevelsen i mobilen dålig får din ranking lida hur bra datorversionen än är. Mobilhandeln nådde enligt Statistas uppskattningar omkring 2,5 biljoner US-dollar 2025, och Googles egna data visar att antalet mobila sökningar i USA med frasen ”near me” (i närheten) och någon variant av ”can I buy” (kan jag köpa) eller ”to buy” (att köpa) var mer än 500 % högre under andra halvåret 2017 än under andra halvåret 2015 — mobiloptimering är alltså ingen trevlig extrafunktion utan en affärsmässig nödvändighet, i synnerhet för lokala företag som vill dra till sig kunder i sin egen region. Rätt angreppssätt är att skriva in SEO-kraven i förfrågningsunderlaget som en obligatorisk del av utvecklingen, inte som en separat tjänst som faktureras ovanpå. Konkret betyder det att byrån redan från början ska planera en SEO-vänlig adresstruktur, säkra en korrekt rubrikhierarki (H1, H2, H3), införa strukturerad data, optimera bilderna med alt-texter och moderna format, konfigurera XML-sitemap och robots.txt och se till att laddningstiderna klarar Core Web Vitals — på en färdig webbplats kan samma ändringar kräva en rejäl ombyggnad av arkitekturen.

5. Att strunta i innehållet, eller lämna det till sista stund

Det femte misstaget är en av de vanligaste orsakerna till att webbprojekt blir försenade. Beställaren utgår från att innehållet är något som går att skriva snabbt i sista stund och lägger all sin uppmärksamhet på design och funktioner, medan texter, bilder och övrigt innehåll förblir ogjorda ända till projektets slut. Problemet är att designen byggs kring innehållet och inte tvärtom — är innehållet inte klart tvingas formgivaren arbeta med exempeltext (lorem ipsum), vilket leder till en design som inte stämmer med det verkliga innehållets mängd och struktur, och när den riktiga texten till slut läggs in kan intrycket ändras dramatiskt, och inte till det bättre.

Att innehållet dröjer är en av de oftast nämnda orsakerna till förseningar i branschen, och det är logiskt, eftersom bra innehåll tar tid. Texterna ska skrivas, stämmas av mot företagets tonläge och budskap och optimeras för sök, och bilderna ska väljas ut eller tas fram så att de passar varumärket och designens krav. Det som fungerar är att behandla innehållsarbetet som en kritisk projektfas med egna deadlines och egna ansvariga, som startar parallellt med designarbetet eller till och med före det, i stället för som en extrauppgift att göra ”när det finns tid”. Saknar företaget egna resurser för innehåll ska det tas med i projektbudgeten som en egen post, med en professionell skribent eller innehållsspecialist inkopplad.

6. Ingen plan för förvaltningen efter lansering

Det sjätte misstaget hänger direkt ihop med förvaltningen, som vi redan har tagit upp i artikeln om att återställa hackade webbplatser — många företagare ser en webbplats som en engångsprodukt som helt enkelt ”fungerar” när den är byggd, och tänker inte på vad som händer efter lansering, när det behövs säkerhetsuppdateringar, innehållsändringar, felrättningar, prestandaarbete och kompatibilitet med nya webbläsarversioner och nya enheter. Det synsättet är farligt, eftersom en oförvaltad webbplats är en oskyddad webbplats — enligt Sucuris rapport för 2023 körde 39,1 % av de hackade CMS-applikationerna en föråldrad version av programvaran vid infektionstillfället, och en flitigt citerad uppskattning från Sophos, som nu är mer än tio år gammal, talar om över 30 000 riktiga småföretagswebbplatser som hackas varje dag.

Förvaltningen måste hanteras redan i planeringsskedet och inte efter att webbplatsen har gått live, eftersom den påverkar både teknikvalet (vissa plattformar är enklare att förvalta än andra), budgeteringen (kostnaderna för förvaltning hör hemma i webbplatsens totala livscykelbudget) och valet av leverantör (du behöver ta reda på om byrån också erbjuder förvaltning och på vilka villkor). I bästa fall innehåller avtalet redan från start en överenskommelse om servicenivå (SLA) som slår fast vilket förvaltningsarbete som ska utföras, hur ofta, vilken svarstid som gäller vid problem och vad tjänsten kostar.

7. Att lämna över domänen och webbhotellet till byrån

Det sjunde misstaget är ett av dem som kan få de allvarligaste långsiktiga följderna, och ändå görs det förvånansvärt ofta. Beställaren låter byrån registrera domännamnet och köpa webbhotellet i byråns namn i stället för i företagets, och tappar därmed kontrollen över affärskritiska digitala tillgångar. Tar samarbetet med byrån slut av något skäl — i godo eller efter en konflikt — kan företaget hamna i ett läge där det inte kommer åt den egna domänen eller kan flytta webbplatsen till en annan server. Företaget kan till och med förlora domännamnet helt om byrån låter bli att förnya registreringen.

Domännamnet och kontot hos webbhotellet är ditt företags digitala tillgångar, och de ska ägas och kontrolleras av dig, ungefär som företagets registrerade adress eller varumärke. Du skulle inte låta din revisor registrera företagets säte i sitt eget namn, och av samma skäl bör du inte låta en byrå kontrollera din digitala identitet. Rätt angreppssätt är att själv registrera domännamnet hos en pålitlig registrar, att köpa webbhotellet i det egna företagets namn eller att hyra det av en partner som lämnar över konfiguration och data på begäran och att ge byrån bara den tekniska åtkomst som behövs för att bygga och driftsätta webbplatsen, inte administrativ kontroll över resurserna. Detsamma gäller Google Search Console, Google Analytics och andra konton för analys och marknadsföring — de ska skapas i företagets namn, och byrån får åtkomst med begränsade rättigheter.

8. Att hoppa över tester och kvalitetssäkring

Det åttonde misstaget är att många beställare ägnar testerna alldeles för lite uppmärksamhet och godkänner en webbplats utan att granska den ordentligt, i förlitan på byråns försäkran om att ”allt fungerar” — medan riktiga tester i verkligheten är ett krävande och tidsödande arbete som omfattar långt mer än att bläddra igenom sidorna och trycka på ett par knappar. Bristfällig kvalitetssäkring är en av de vanligaste orsakerna till att webbplatser efter lansering visar fel som påverkar användarupplevelsen, konverteringen och till och med säkerheten, och att rätta dem på en färdig webbplats är alltid dyrare och krångligare än om problemen hade hittats och lösts under utvecklingen.

Testerna bör täcka flera områden: funktionstesterna kontrollerar att webbplatsens alla funktioner fungerar som de ska — formulär, sök, navigation, registrering, varukorg och kassa, filtrering och sortering av innehåll; kompatibilitetstesterna kontrollerar att webbplatsen fungerar i olika webbläsare (Chrome, Firefox, Safari, Edge), operativsystem och enheter (datorer, surfplattor, mobiler med olika skärmstorlekar); prestandatesterna mäter laddningstider, svarstider och beteende under belastning; säkerhetstesterna hittar möjliga sårbarheter som SQL-injektion, utrymme för XSS-angrepp och felaktig behörighetskontroll; och tillgänglighetstesterna kontrollerar om webbplatsen går att använda av personer med olika funktionsnedsättningar, i enlighet med WCAG.

Lösningen är att skriva in en testfas i själva avtalet, med tydligt definierade acceptanskriterier — vilket betyder att det är dokumenterat exakt vad som ska testas, vilka resultat som är godtagbara och hur det går till om testerna hittar problem. Det är dessutom klokt att beställaren gör en egen acceptanstestning, själv eller med hjälp av en oberoende specialist, i stället för att helt förlita sig på byråns egen bedömning, eftersom en utvecklare som testar sitt eget arbete är som en student som rättar sin egen tenta.

9. Beslut i kommitté utan en ansvarig

Det nionde misstaget är organisatoriskt, och det är särskilt typiskt för större företag och organisationer, där ett webbprojekt involverar flera beslutsfattare — marknadsavdelningen, säljteamet, ledningen, IT-avdelningen och ibland till och med juristerna — och där var och en av dem deltar i godkännandet av design och innehåll med lika stor rösträtt. Ett sådant upplägg, där en kommitté fattar besluten om designen, leder nästan alltid till ett resultat fullt av kompromisser som inte gör någon nöjd, eftersom varje beslutsfattare försöker pressa in sina egna prioriteringar i webbplatsen, och slutresultatet blir överlastat, inkonsekvent och frånkopplat från affärsmålen.

Branscherfarenhet visar att projekt med en tydligt utpekad beslutsfattare, med mandat att godkänna design, innehåll och funktioner, blir klara snabbare, håller budgeten oftare och når bättre resultat än de där besluten fattas i grupp. Det betyder inte att de andra inblandades synpunkter saknar värde — det betyder att det måste finnas en tydlig process där alla parter kan säga sitt och ge återkoppling, medan det slutliga beslutet fattas av en person som har mandatet och ansvaret för projektets resultat. RACI-matrisen (Responsible, Accountable, Consulted, Informed) är ett effektivt verktyg för att strukturera en sådan process — den slår tydligt fast vem som utför arbetet, vem som är slutlig beslutsfattare, vem som ska rådfrågas och vem som ska hållas informerad.

10. Att strunta i immaterialrätt och avtal

Det tionde misstaget rör den juridiska sidan, som många företagare — inte minst ägare till mindre bolag — brukar ignorera eller betrakta som onödig byråkrati: de inleder ett samarbete utan formellt avtal, utan tydligt reglerade immateriella rättigheter och utan sekretessavtal (NDA), vilket kan skapa allvarliga problem både under projektet och efter att det är avslutat. Utan tydligt reglerade immateriella rättigheter kan en beställare hamna i ett läge där han eller hon i praktiken inte äger den källkod som redan är betald, och byrån är fri att använda samma kod åt andra kunder eller till och med vägra lämna ut källkoden om samarbetet tar slut i förtid.

Avtalet bör tydligt slå fast att allt immateriellt som skapas under utvecklingen — källkod, designfiler, grafik, datastrukturer och dokumentation — tillhör beställaren när full betalning har erlagts, och att byrån inte har rätt att använda det för andra ändamål utan beställarens samtycke. Avtalet ska likaså täcka omfattningen, tidsplanen, betalningsplanen (helst kopplad till avklarade delmål snarare än till förfluten tid), garantitiden, sekretessvillkoren och hur tvister ska lösas. En betalningsstruktur som är kopplad till konkreta, godkända delmål i stället för bara till en tidsperiod ger byrån ett skäl att hålla tiderna och säkerställer att beställaren betalar för faktiskt levererat arbete och inte för en obestämd mängd nedlagd tid; för större och mer udda projekt fungerar även löpande räkning med ett veckotak, förutsatt att omfattning och tak är skriftligt fastlagda.

Ett sekretessavtal (NDA) betyder särskilt mycket när byrån under projektet får ta del av känslig affärsinformation — kunduppgifter, affärsprocesser, prissättning eller annan konfidentiell information som i händerna på en konkurrent kan skada din verksamhet. Många företagare tror att ett NDA är ett instrument för stora koncerner, men i själva verket är det lika viktigt för varje företag som delar känslig information med utomstående partner. Ett välskrivet avtal med tydliga delmål och acceptanskriterier fungerar dessutom som ett projektledningsverktyg — det säkerställer att båda parter är överens om vad som görs, när det ska vara klart och vilket resultat som väntas i varje skede, och det minskar risken för missförstånd och konflikter under projektets gång betydligt.

Fler misstag när du ska beställa en webbplats

Även om vi har beskrivit de tio största misstagen finns det flera andra vanliga brister som förtjänar ett eget omnämnande, eftersom de kan påverka utfallet av ett webbprojekt påtagligt. En av dem är att luta sig alltför tungt mot byråns åsikt i alla frågor, inklusive affärsstrategin — byrån är expert på tekniken, men den förstår sällan din bransch, din målgrupp och din marknads dynamik lika väl som du själv, och delegerar du varje beslut till byrån riskerar du att sitta med en webbplats som är tekniskt gedigen men affärsmässigt verkningslös.

Det andra vanliga misstaget är att bortse från tillgängligheten — många företagare är inte ens medvetna om att deras webbplats ska kunna användas av personer med funktionsnedsättning, och att det för offentliga aktörer är ett lagkrav enligt lagen (2018:1937) om tillgänglighet till digital offentlig service, medan lagen (2023:254) om vissa produkters och tjänsters tillgänglighet, som gäller från och med den 28 juni 2025, omfattar bland annat e-handel, men inte varje företagswebbplats. Att bygga in tillgängligheten under utvecklingen är avsevärt enklare och billigare än att lägga till den på en färdig webbplats, och den vidgar din möjliga publik, eftersom omkring 16 % av världens befolkning — 1,3 miljarder människor — lever med en betydande funktionsnedsättning.

Det tredje ytterligare misstaget är att aldrig införa analys och konverteringsmätning — många webbplatser går live utan att Google Analytics, Google Search Console eller andra analysverktyg är konfigurerade, vilket betyder att beställaren inte kan bedöma hur väl webbplatsen fungerar, hitta problemen eller fatta datadrivna beslut om fortsatt optimering. Att införa analys ska skrivas in i projektets omfattning som ett obligatoriskt krav, inte behandlas som något att ”göra sedan”. Utan analysdata arbetar du i praktiken i blindo — du vet inte hur många besökare webbplatsen drar till sig, var de kommer ifrån, vilka sidor de besöker, var de lämnar webbplatsen eller om webbplatsen alls fyller sin funktion i affären.

Det fjärde ytterligare misstaget som förtjänar att nämnas är att inte säkra webbplatsens rättsliga efterlevnad — många nya webbplatser går live utan information om behandling av personuppgifter, utan information om kakor eller andra juridiska dokument som kan krävas enligt GDPR och annan tillämplig lagstiftning beroende på webbplatsens verksamhet och personuppgiftsbehandling, och den försummelsen kan få allvarliga rättsliga följder, inklusive sanktionsavgifter på upp till 20 miljoner euro eller 4 % av företagets totala globala omsättning under föregående räkenskapsår, beroende på vilket belopp som är högst. Rättslig efterlevnad är inte bara en formalitet — den är också en förtroendesignal till dina besökare, som visar att du tar deras dataskydd och integritet på allvar, och dagens konsumenter är alltmer uppmärksamma på hur företag hanterar deras personuppgifter. En kakbanner måste därför testas tekniskt, inte bara finnas på plats – läs mer i guiden om teknisk granskning av kakbannern.

FAQ

De vanligaste frågorna.

Hur lång tid tar ett webbplatsprojekt från start till lansering?

Räkna med 4 till 8 veckor för en enkel företagswebbplats på 5 till 10 sidor, 2 till 4 månader för en medelkomplex affärswebbplats med skräddarsydda funktioner och 4 till 8 månader för en avancerad e-handelsplattform eller en webbapplikation. När du ska beställa en webbplats sätts tidsplanen av omfattning och komplexitet, inte av hur snabbt byrån arbetar. I de tidsramarna ryms också förstudien, innehållsproduktionen och testerna, inte bara design och programmering — och det är just där tidsplanerna börjar glida, ofta innan utvecklingen ens har startat, medan alla väntar på texter och bilder. Korta tider förtjänas aldrig genom snabbare arbete; de köps på kvalitetens bekostnad, oftast genom att testerna, SEO-grunderna eller innehållsgranskningen stryks.

Hur bedömer jag kvaliteten på en byrås arbete om jag inte själv är tekniskt kunnig?

Kontrollera fyra saker som inte kräver några tekniska kunskaper: laddningstiden på deras tidigare arbeten, hur de beter sig i en mobil, vad tidigare kunder har varit med om och hur begripligt byrån svarar på frågor om säkerhet och SEO. Laddningstiden mäter Google PageSpeed Insights gratis — resultatet bör ligga över 80 poäng både i mobil och på dator. Responsiviteten kontrollerar du själv genom att öppna deras webbplatser i telefonen och på en surfplatta. Fråga tidigare kunder om tiderna hölls, hur samarbetet löpte och hur stödet efter lansering fungerade — där syns skillnaderna snabbast. Ställ till sist konkreta frågor om säkerhetsrutiner, synen på SEO och villkoren för förvaltningen: en kompetent leverantör svarar på dem på ett språk du förstår, i stället för med termer som avslutar samtalet.

Behöver jag skräddarsydd utveckling eller räcker en färdig lösning på en CMS-plattform?

Svaret beror på din verksamhets specifika behov, din budget och dina långsiktiga planer. CMS-plattformar som WordPress är ett utmärkt val för de flesta små och medelstora företag, eftersom de erbjuder ett brett ekosystem av tillägg (plugin), förhållandevis låga kostnader för utveckling och förvaltning och stor frihet i innehållsarbetet, och omkring 40 % av alla webbplatser i världen körs på WordPress. Skräddarsydd utveckling är motiverad när dina affärsprocesser kräver unika funktioner som inte går att nå med ett standard-CMS, eller när du har mycket höga krav på prestanda, säkerhet eller skalbarhet, men den är oftast betydligt dyrare både att bygga och att förvalta.

Vilka varningssignaler tyder på en oseriös leverantör av webbplatser?

Vilken som helst av de här tre signalerna räcker för att tacka nej: leverantören undviker ett skriftligt avtal, vägrar lämna kontaktuppgifter till tidigare kunder eller insisterar på att registrera domänen i sitt eget namn. Lika tydligt är ett erbjudande som är för bra för att vara sant — ett extremt lågt pris eller en orimligt kort tidsplan betyder att något har utelämnats, och du får veta vad först senare. Var också vaksam mot den som bara talar om design och inte kan svara på frågor om säkerhet, prestanda och SEO, som inte kan förklara vilken teknik som ska användas och varför, eller som vägrar bekräfta att infrastruktur och data lämnas över på begäran. Bedöm till sist kommunikationen redan före avtalet: dröjer svaren på e-post i dagar redan i offertskedet blir det med största sannolikhet värre under projektets gång.

Hur mycket bör jag själv vara med i utvecklingsarbetet?

Beställarens medverkan är avgörande för att ett projekt ska lyckas, men den måste vara strukturerad snarare än kaotisk och ständigt pågående. I bästa fall deltar du aktivt i förstudien och bidrar med kunskap om din verksamhet, din målgrupp och dina mål; du är med på avstämningarna där byrån visar vad som gjorts; du lämnar över innehåll och material i tid; och du gör en noggrann acceptanstestning innan webbplatsen går live. Samtidigt är det viktigt att lita på byråns yrkeskunnande i tekniska frågor och att inte detaljstyra där du saknar tillräckliga kunskaper. På avstämningarna (en gång i veckan eller varannan vecka är lagom) ger du samlad återkoppling i stället för lösryckta kommentarer varje timme, som bryter arbetsflödet och saktar ned projektet. Din roll är att se till att webbplatsen svarar mot verksamhetens behov; byråns roll är att hitta den bästa tekniska lösningen för dem.

RELATERAD TJÄNST
Webbutveckling med WordPress

Webbutveckling med WordPress för företag och myndigheter: eget tema, blockbibliotek och flerspråkigt innehåll. Vi flyttar över befintligt innehåll, stärker säkerheten och utbildar dina redaktörer. Från 2 500 €.

Läs mer