WordPress Utvikler i Trondheim

WordPress-utvikling for Trondheim-bedrifter handler sjelden om å sette opp et tema. Den handler om å koble en WordPress-installasjon mot Vipps, mot et norsk regnskapssystem, mot Bring sine fraktsoner og mot kravene Datatilsynet stiller, uten at noe av det knekker ved neste kjerneoppdatering. Det er den jobben denne siden beskriver.

Jeg leverer senior WordPress-utvikling for virksomheter i Trondheim og Midt-Norge: egne block-temaer, plugins, integrasjoner mot norske betalings- og logistikkleverandører og refaktorering av eldre temaer som har vokst seg uoversiktlige. Arbeidet følger WordPress Coding Standards, og hver branch går gjennom kodegjennomgang før den når produksjon.

#WordPress-utvikling i Trondheim

Trondheim er Norges største studentby og et av landets tyngste knutepunkter for forskning og teknologioverføring. NTNU (Norges teknisk-naturvitenskapelige universitet) og SINTEF ligger vegg i vegg med næringslivet i Gløshaugen-området og rundt Sluppen og Nyhavna. Det betyr at mange oppdrag i byen ikke kommer fra et rent markedsføringsbudsjett, men fra selskaper som allerede har et produkt, en patentportefølje eller en B2B-salgsmodell, og som trenger et nettsted som tåler at innhold, leads og integrasjoner endrer seg over tid.

Den vanligste situasjonen er en bedrift i Trondheim eller Trøndelag som driver et WordPress-nettsted bygget for noen år siden, der temaet har fått påklistret funksjonalitet bit for bit. Hver ny plugin la til litt mer gjeld, og nå er PageSpeed-tallene røde, redaktørene tør ikke røre forsiden, og ingen vet hvilken kode som faktisk er i bruk. Den andre vanlige situasjonen er en nettbutikk på WooCommerce eller et B2B-nettsted med skjemaer mot CRM, som har vokst forbi det oppsettet det startet med, og som trenger Vipps-betaling, fraktberegning mot Bring og MVA-håndtering som faktisk stemmer.

#NTNU, spinouts og teknologiklyngen

Trondheims digitale økonomi er preget av universitetet og forskningsinstituttene mer enn av et rent forbrukermarked. NTNU utdanner ingeniører, datafolk og designere i stort volum, og mange selskaper i byen er spinouts eller tidlige vekstselskaper som har røtter i laboratorium, doktorgradsprosjekt eller samarbeid med SINTEF. Det gir konkrete konsekvenser for WordPress-arbeidet:

• Produkt- og forskningssider trenger strukturerte innholdsmodeller. En spinout som lanserer, bytter ofte mellom teknisk dokumentasjon, karrieresider, investorinformasjon og kundecase-typer. Egne posttyper, feltgrupper og blokkmønstre gjør at redaktøren kan publisere uten å bryte malen, mens utvikleren beholder kontrollen over hvordan dataene vises.
• Integrasjoner mot eksisterende systemer er vanligere enn «ren» brosjyre. Mange Midt-Norge-bedrifter har allerede CRM, prosjektverktøy eller ERP. WordPress skal da hente eller sende leads, synkronisere produkter eller eksponere innhold via REST, ikke bare vise statiske sider.
• Flerspråk er ofte et reelt krav. Teknologiselskaper i Trondheim selger til Norden og videre ut. hreflang, uavhengige metadata per språk og i18n-klar temakode hører derfor med i arkitekturen fra start, ikke som en etterpåklattet plugin.

Jeg bygger ikke «startup-landing» som engangsdesign. Jeg bygger et WordPress-grunnlag som tåler at teamet vokser, at produktnavnet endres, og at en ny landingsside skal opp før en messedag uten at utvikleren må inn i hver fil.

#Studentbyen og sesongvariasjon

Trondheim har en sterk sesongrytme knyttet til universitetet. Når semesteret starter, fylles byen med studenter, midlertidige leieforhold, arrangementer og kampanjer fra aktører som retter seg mot campus. Om sommeren er det stilleere i studentmarkedet, mens B2B-virksomheter, industri og offentlig sektor kjører mer jevnt gjennom året. For et WordPress-prosjekt betyr det at:

• Trafikk- og kampanjepiker er forutsigbare. Lansering av arrangementssider, søknadsfrister, karriereuker og samarbeid med studentorganisasjoner bør planlegges inn i redaksjonsflyten, ikke som ad-hoc hotfix midt i semesterstart.
• Caching og ytelse må tåle topper. Et arrangement som deles i studentgrupper eller i lokale kanaler kan gi plutselig last. Full-page caching, fornuftig bildeformat og begrenset tredjeparts-JavaScript er mer verdifullt enn nok et animasjonsbibliotek.
• Innholdsteamet er ofte lite. Mange Trondheim-virksomheter har én markedsansvarlig eller en deltidskommunikatør. Blokkmønstre, låste seksjoner og tydelig redaktørdokumentasjon reduserer feil mer enn et fancy designsystem ingen bruker.

#Midt-Norge B2B og den reelle økonomien

Utenfor campus er Trøndelags økonomi preget av industri, energi, maritim virksomhet, havbruk og leverandører til disse kjedene. Det er ikke nødvendigvis WooCommerce mot forbruker; det er ofte leadgenerering, partnerportaler, dokumentasjonsbibliotek og flerspråklige produktsider. Typiske behov jeg møter i Midt-Norge:

• Lead-skjemaer som faktisk lander i CRM. Skjemaet er verdiløst hvis det bare sender e-post til en innboks som ingen eier. Jeg kobler mot REST eller webhook, med validering, spam-beskyttelse og logging, slik at salgsteamet kan stole på dataene.
• Dokumentasjon og ressursbibliotek. Tekniske PDF-er, datablader og videoer trenger egne innholdstyper, tilgangskontroll der det er relevant, og søk som fungerer. WordPress kan gjøre dette uten å bli et tungt CMS-monstrum, hvis modelleringen er ryddig.
• Lokal synlighet i et regionalt marked. Mange kunder søker «WordPress utvikler Trondheim» eller bynavn kombinert med tjeneste, men også branchenære begreper. Teknisk SEO, lokal schema og konsistent NAP er en del av leveransen, ikke et separat prosjekt.

Jeg finner ikke på kundelister eller prosenttall for å «bevise» markedet. Det som teller, er at koden tåler norske betalings- og personvernkrav, og at redaksjonen kan jobbe uten å ringe utvikler for hver forsideendring.

#Hva oppdraget dekker

• Egne block-temaer bygget på editor-API-ene (theme.json, blokkmønstre, stilvarianter) slik at redaktører i Trondheim kan endre forsider og landingssider uten å ringe en utvikler
• Egne plugins for forretningslogikk, egne posttyper og integrasjoner, holdt utenfor temaet så funksjonaliteten overlever et fremtidig temabytte
• Integrasjoner mot norske tjenester: Vipps (via den offisielle vipps-woocommerce-utvidelsen), Bring/Posten for frakt, og koblinger mot regnskaps- og ordresystemer over REST
• REST- og WPGraphQL-endepunkter for headless frontender eller mobilapper, med autentisering og fornuftig hastighetsbegrensning
• WP-CLI-skript for masseoperasjoner på innhold, databasemigrasjoner og miljøkonfigurasjon når et nettsted skal flyttes eller ryddes
• Tilgjengelighet etter WCAG 2.2 AA: semantisk markup, ARIA-landemerker, tastaturnavigasjon og fokusstyring, noe som også er et reelt krav for offentlig finansierte virksomheter i Norge

#Norske rammer som påvirker koden

Mye av det som skiller en Trondheim-leveranse fra en generisk WordPress-jobb ligger i regelverket, ikke i designet. Et par konkrete eksempler fra arbeidet:

• Personvern og Datatilsynet. GDPR gjelder fullt ut i Norge, og Datatilsynet håndhever det. I praksis betyr det samtykkebanner som faktisk blokkerer skript før samtykke, en databehandleravtale med hostingleverandøren, og at analyseverktøy ikke lekker personopplysninger ut av EØS uten grunnlag. Jeg setter dette opp i koden, ikke bare i en personvernerklæring ingen leser.
• Angrerett og forbrukerkjøpsloven. For nettbutikker rettet mot forbrukere må angrerettsinformasjonen (14 dagers angrefrist) vises tydelig i kjøpsløpet, ikke gjemmes i bunnteksten. WooCommerce gir kontrollen, men oppsettet må gjøres riktig.
• MVA og VOEC. Norsk merverdiavgift er 25 prosent, og terskelen for VOEC-registrering ligger på 50 000 kroner i årlig salg til norske forbrukere. En WooCommerce-butikk som selger over landegrenser må håndtere dette i avgiftsoppsettet, ikke i et regneark etterpå.

#Betaling og frakt for norske nettbutikker

Vipps er det dominerende betalingsmiddelet i Norge og brukes av en stor del av befolkningen. For en WooCommerce-butikk i Trondheim er Vipps sjelden valgfritt; kunder som ikke finner Vipps i kassen, hopper av. Jeg integrerer betaling via den offisielle vipps-woocommerce-utvidelsen og setter den opp slik at både hurtigkasse og ordinært kjøpsløp fungerer, med korrekt håndtering av callbacks og ordrestatus. Klarna dekker delbetaling der kunden ønsker det, og Stripe brukes for internasjonale kort.

På frakt er Bring og Posten standard for innenlands levering, også når varen skal ut fra Midt-Norge til resten av landet. Et fornuftig oppsett henter fraktpriser etter vekt og sone, viser hentested og leveringstid i kassen, og lar lageret skrive ut etiketter uten manuell tasting. Når dette ikke virker, blir det en kostnad per ordre som først synes når volumet stiger.

For B2B-salg er bildet ofte annerledes: faktura, tilbudsgodkjenning og minimumsordre erstatter hurtigkasse. Da er det viktigere med ryddige skjemaer, rollebasert tilgang og eksport til regnskap enn med Vipps MobilePay i første rad. Jeg velger løsning etter faktisk salgsmodell, ikke etter det som ser best ut i en demobutikk.

#Slik jobber jeg gjennom et oppdrag

1. Kartlegging og kodegjennomgang. Jeg går gjennom dagens WordPress-installasjon: temastruktur, egne plugins, integrasjoner, hostingbegrensninger og et referansepunkt for ytelse og tilgjengelighet. Resultatet er et skriftlig risikokart, ikke en magefølelse.
2. Arkitektur og omfang. Vi avgjør hva som skal bygges nytt og hva som kan refaktoreres, hvor grensen mellom tema og plugin går, hvilke integrasjoner som trengs, og hvilke akseptkriterier som gjelder. Avveininger skrives ned.
3. Bygging i feature-branches. Koden følger WordPress Coding Standards, tekst er i18n-klar, markup er tilgjengelig, og hver branch går gjennom kodegjennomgang før den slås sammen.
4. QA og utrulling. Løsningen kjøres i et testmiljø som speiler produksjon. Du tester med ekte innhold og verifiserer Vipps, frakt og MVA før lansering der det er relevant. Utrulling skjer via en dokumentert release-prosess med en sti tilbake hvis noe må reverseres.
5. Overlevering. Du får levende dokumentasjon for både redaktører og utviklere, en runbook for de ikke-opplagte valgene, og en overleveringssesjon. Deretter kan prosjektet gå til ditt eget team eller til en fast vedlikeholdsavtale.

#Typiske utfordringer jeg løser for Trondheim-bedrifter

• Et tema full av teknisk gjeld. Mange Trondheim-nettsteder har samlet logikk i functions.php gjennom flere utviklere, ofte freelancere som har kommet og gått. Jeg flytter forretningslogikk ut i plugins, rydder mal-hierarkiet og fjerner kode ingen lenger bruker, slik at neste oppdatering ikke blir en kveld med feilsøking.
• En WooCommerce-butikk eller et B2B-skjemaoppsett som ikke skalerer i toppene. Før kampanjer, semesterstart eller messer setter jeg opp full-page caching, rydder i trege databasespørringer, ekskluderer kasse og handlekurv fra cache der det trengs, og belastningstester før kampanjen, ikke etter.
• Sikkerhet på sider som håndterer persondata. Content Security Policy-headere, deaktivert XML-RPC der det ikke brukes, tofaktor på admin, en brannmur tilpasset WordPress-spesifikke angrepsmønstre, og parametriserte spørringer som lukker SQL-injeksjon.
• Innhold som vokser raskere enn strukturen. Spinouts og forskningsnære selskaper publiserer ofte tekniske artikler, stillingsannonser og partnerstoff i samme kaos. Egne posttyper, taksonomier og blokkmønstre gir redaksjonen en sporbar struktur uten å kreve utviklerbillett for hver side.

#Hva du kan måle etterpå

Jeg foretrekker resultater som lar seg etterprøve framfor påstander. Det som faktisk kan måles på et Trondheim-prosjekt:

• Core Web Vitals i grønt for LCP, INP og CLS, verifisert på mobil mot reelle besøkstall, ikke bare i en Lighthouse-kjøring på en rask maskin
• Kortere publiseringstid for redaksjonen fordi forsider og landingssider bygges med blokkmønstre i stedet for utviklerbillett
• Et kjøps- eller leadløp der Vipps, frakt mot Bring, MVA eller CRM-integrasjon henger sammen, slik at avbrutte kjøp eller tapte leads går ned

#Ytelse i praksis

Core Web Vitals påvirker både rangering i Google og hvor mange som faktisk fullfører et kjøp eller et skjemasteg. På et WordPress-prosjekt jobber jeg mot disse målene konkret:

• LCP holdes nede med optimalisert kritisk renderingsvei, hero-bilder i WebP/AVIF, edge-caching og statisk levering der det er mulig
• INP holdes lav med minimal JavaScript-hydrering, færre og lettere tredjepartsskript, og tunge beregninger flyttet bort fra hovedtråden
• CLS holdes lav med eksplisitte bildedimensjoner, font-display: swap med matchende reservefont og reservert plass for innhold som lastes etterpå

Målingene følges over tid med Lighthouse i utrullingsløpet og data fra reelle besøkende, slik at en regresjon fanges opp før den rekker å påvirke salget eller leadkvaliteten.

#Spørsmål jeg ofte får fra Trondheim-bedrifter

Hva skjer hvis kravene endres underveis? Det er normalt, særlig i miljøer der produkt, forskningspartner eller investorpitch endrer seg. Den sprintbaserte arbeidsformen gjør at vi kan justere omfanget mellom iterasjoner. Konsekvensen for tid og budsjett legges åpent på bordet, og du godkjenner før vi går videre.

Hva inkluderer en vedlikeholdsavtale? Oppdatering av WordPress, plugins og temaer (testet i testmiljø først), daglige sikkerhetskopier med rimelig oppbevaringstid, oppetidsovervåking, sikkerhetsskanning og avsatte utviklertimer til mindre endringer.

Bygger du nytt tema eller utvider det jeg har? Begge deler forekommer. Et nytt prosjekt starter som regel med et eget block-tema; et arvet prosjekt trenger oftere fokusert refaktorering enn en full omskrivning. Valget tas på grunnlag av kostnad mot teknisk gjeld, og begrunnelsen skrives ned.

Hva skiller dette fra et generisk byrå i Trondheim? Du jobber direkte med en senior utvikler, ikke gjennom flere ledd. Avveiningene er skriftlige, akseptkriteriene er målbare, og omfanget bygges rundt WordPress-utvikling framfor en bred redesignpakke.

Kan dere jobbe remot mot et team i Midt-Norge? Ja. Det vanlige er asynkron kommunikasjon med tydelige leveranser per sprint, kodegjennomgang i pull requests, og overlevering som kan skje digitalt. Fysiske møter i Trondheim avtales når det gir verdi, ikke som fast ritual.

#Priser og forutsigbarhet

Prisen settes individuelt etter omfanget i den enkelte saken, og du får en detaljert oversikt før arbeidet starter. Endringer i omfang diskuteres åpent med tydelige kostnadsfølger, slik at det ikke kommer overraskelser på fakturaen. Jeg skriver kode andre utviklere kan vedlikeholde: dokumentasjon, kodestandarder og en overleveringssesjon hører med, og det er ingen leverandørlåsing eller proprietære svarte bokser.

#Lokal SEO for synlighet i Trondheim-markedet

Et godt bygget nettsted har bare verdi om målgruppen i Trondheim og Midt-Norge finner det. Det grunnleggende SEO-arbeidet er en del av leveransen:

• Teknisk fundament: ryddige URL-strukturer, XML-nettkart, kanoniske tagger og riktig overskriftshierarki, med strukturerte data (LocalBusiness, Organization, Product, FAQ, HowTo) der de hører hjemme
• Lokal synlighet: kobling mot Google Business-profil, lokal schema med Trondheim-adresse der det er relevant, og konsistent NAP-informasjon på tvers av oppføringer
• Core Web Vitals som rangeringssignal, behandlet som en del av utviklingen og ikke en etterpåklattet optimalisering
• Flerspråklig oppsett med hreflang og uavhengige metadata per språk for bedrifter som retter seg mot markeder utenfor Norge fra Trondheim

#Universell utforming i praksis

Tilgjengelighet er ikke en avsluttende sjekk på et Trondheim-prosjekt. Det er et sett med krav som må ligge i temakoden fra første branch. Trondheim har en høy andel offentlig sektor, forskningsinstitusjoner, kommunale foretak, interesseorganisasjoner og leverandører som selger inn til det offentlige, og for disse er universell utforming et anskaffelseskrav lenge før det er et designspørsmål. NTNU og tilknyttede miljøer forventer også at digitale flater kan brukes av et bredt spekter av studenter og ansatte. Denne delen beskriver regelverket som faktisk gjelder, hva som må rettes i et eksisterende WordPress-tema, hvordan det testes, og hvordan du unngår at neste oppdatering river ned arbeidet.

#Regelverket som faktisk gjelder

Norsk rett stiller kravet direkte. Likestillings- og diskrimineringsloven pålegger universell utforming av IKT-løsninger rettet mot allmennheten, og forskrift om universell utforming av IKT-løsninger fastsetter den tekniske normen. Forskriften peker på WCAG 2.1 nivå AA. For virksomheter i privat sektor er suksesskriteriene 1.2.3, 1.2.4 og 1.2.5 om tidsbasert media unntatt, mens offentlig sektor må dekke også disse. Tilsynet for universell utforming av ikt, som ligger i Digitaliseringsdirektoratet, fører tilsyn og kan følge opp med pålegg og tvangsmulkt. Offentlige virksomheter skal i tillegg publisere en tilgjengelighetserklæring.

EUs tilgjengelighetsdirektiv utvider omfanget. Direktiv (EU) 2019/882, ofte omtalt som European Accessibility Act, får anvendelse i EU fra 28. juni 2025 og treffer blant annet netthandel, banktjenester, e-bøker, billettsalg og elektronisk kommunikasjon. Regelverket er EØS-relevant, og en Trondheim-butikk eller tjeneste som selger til forbrukere i EU, må forholde seg til det uavhengig av hvor langt den norske gjennomføringen er kommet. Den harmoniserte europeiske standarden EN 301 549 er målestokken direktivene bruker, og den viser videre til WCAG. Praktisk konsekvens: bygg mot WCAG, så dekker du begge regelsett med samme arbeid.

#Hva som faktisk må rettes i et eksisterende tema

Kontrast. Suksesskriterium 1.4.3 krever 4,5:1 for vanlig brødtekst og 3:1 for stor tekst, mens 1.4.11 krever 3:1 for grensesnittkomponenter og meningsbærende grafikk. De typiske bruddene i et arvet tema er lysegrå hjelpetekst under skjemafelt, plassholdertekst brukt som etikett, hvit tekst på en merkevarefarge som ikke er testet, og ikoner uten nok kontrast mot bakgrunnen. Rettingen hører hjemme i paletten i theme.json, ikke i enkeltblokker, ellers kommer feilen tilbake neste gang noen bygger en landingsside.

Tastaturfokus. Alt som kan klikkes, må nås med Tab og betjenes med Enter eller mellomrom, fokusmarkeringen må være synlig etter 2.4.7, og WCAG 2.2 la til 2.4.11, som krever at det fokuserte elementet ikke skjules helt av for eksempel en fast topplinje. Vanlige feil: temaets CSS slår av outline uten å erstatte den, mobilmeny og undermenyer som bare åpner på hover, modaler uten fokusfelle og uten Esc, og karuseller der fokus forsvinner inn i skjulte visningsflater. Rett det med en tydelig :focus-visible-markering, scroll-margin-top som kompenserer for sticky header, inert på bakgrunnsinnhold når en dialog er åpen, og fokus tilbake til utløserknappen når dialogen lukkes.

Skjemaetiketter. Hvert felt trenger en label koblet til feltets id, ikke bare en plassholder som forsvinner ved utfylling. Feilmeldinger knyttes til feltet med aria-describedby slik at skjermleseren leser dem, og autocomplete settes på navn, e-post, telefon og adresse etter 1.3.5. Obligatoriske felt merkes i tekst, ikke bare med rød farge, siden 1.4.1 forbyr farge som eneste bærer av informasjon. På en WooCommerce-kasse eller et B2B-skjema er det som regel egne felter lagt til av plugins eller av forrige utvikler som bryter mønsteret, ikke kjernen selv.

Tilgjengelige navn. Suksesskriterium 4.1.2 krever navn, rolle og verdi for hver komponent. I praksis betyr det slutt på lenker som bare heter Les mer, ikonknapper uten tekst, og aria-label som sier noe annet enn den synlige teksten, som bryter 2.5.3. WordPress-temaer har allerede klassen screen-reader-text for skjult, lesbar tekst, og dekorative SVG-ikoner skal ha aria-hidden når det står tekst ved siden av.

Overskriftsrekkefølge og landemerker. Én h1 per side, ingen hopp fra h2 til h4. Blokkeditoren gjør dette lett å bryte fordi redaktører velger overskriftsnivå etter hvordan det ser ut på skjermen. Begrens derfor tilgjengelige nivåer på overskriftsblokken i mønstrene, og la mønsteret sette riktig nivå på forhånd. Landemerkene header, nav, main og footer skal være på plass, og en hopp-til-innhold-lenke skal være det første fokuserbare elementet på siden. Alt-tekst settes per bruk av bildet, ikke per fil, fordi samme bilde kan være meningsbærende på én side og rent dekorativt på en annen.

#Hvordan det testes

Automatiske skann fanger bare den delen av kravene som lar seg maskinlese, og resten må gjøres manuelt. Et fungerende oppsett kombinerer begge deler: @axe-core/cli eller pa11y-ci kjørt mot en fast URL-liste i utrullingsløpet, Lighthouse-kategorien for tilgjengelighet som grov indikator, og deretter en manuell runde. Den manuelle runden er en tastaturgjennomgang fra topp til bunn uten mus, en skjermleserkontroll med NVDA i Firefox på Windows og VoiceOver i Safari på macOS og iOS, zoom til 400 prosent, som tilsvarer en bredde på 320 CSS-piksler etter 1.4.10, kontroll av tekstavstand etter 1.4.12, og en sjekk i forced-colors-modus i Windows. WCAG 2.2 la i tillegg til 2.5.8 med minste målestørrelse på 24x24 CSS-piksler, som ofte treffer små ikonknapper i topplinjen og i kassen. Funnene skrives ned med suksesskriterium, side og skjermbilde, slik at listen kan brukes som grunnlag for en tilgjengelighetserklæring.

#Hvordan du unngår å ødelegge det ved neste oppdatering

Legg kontrollen i utrullingsløpet. En tilgjengelighetstest som bare kjøres ved lansering, holder til lansering. Kjør pa11y-ci eller axe som et steg i CI som blokkerer sammenslåing ved nye brudd, og kjør samme skann i testmiljøet etter hver plugin- og kjerneoppdatering, siden en oppdatert plugin kan endre markup i kassen eller i skjemaene uten at noe annet ser annerledes ut.

Lås det redaktøren ikke skal kunne bryte. Slå av egendefinerte farger i theme.json og la paletten være den eneste kilden til farge, begrens overskriftsnivåene i mønstrene, og bruk blokklåsing der strukturen er en del av kravet. Da blir riktig valg standardvalget i stedet for noe som må huskes.

Skriv det ned og hold det oppdatert. Redaksjonell dokumentasjon med en kort sjekkliste for alt-tekst, lenketekst og overskriftsnivå gjør mer for tilgjengeligheten over tid enn en engangsrapport. Tilgjengelighetserklæringen oppdateres ved vesentlige endringer på nettstedet, og kjente avvik føres opp der med en plan for retting i stedet for å skjules. Frekvensen på skann og oppfølging avtales i vedlikeholdsavtalen sammen med resten av responstidene.

#Arbeidsform tilpasset Midt-Norge

Avstand til Oslo er irrelevant for kodekvalitet, men den påvirker hvordan samarbeidet settes opp. Mange Trondheim-virksomheter har små interne IT-team, eller ingen egen WordPress-kompetanse i huset. Da er det viktigere med skriftlige beslutninger, forutsigbare sprinter og en overlevering som faktisk kan brukes, enn med hyppige workshops uten referat.

Jeg jobber med tydelige akseptkriterier per leveranse. Det betyr at «ferdig» er definert før kodingen starter: hvilke sider, hvilke integrasjoner, hvilke ytelsesmål, hvilke tilgjengelighetskrav. Når noe endres underveis, oppdateres omfanget skriftlig. Det er den enkleste måten å unngå at et prosjekt i Midt-Norge glir ut i ukevis med uklare forventninger.

Hosting velges etter behov, ikke etter vane. Noen prosjekter trenger managed WordPress med god norsk support; andre trenger mer kontroll over server, Redis-objektcache og distribusjonsrutiner. Jeg dokumenterer valget og konsekvensene for sikkerhetskopier, testmiljø og oppdateringsrutiner, slik at du ikke sitter fast med en løsning ingen i teamet forstår.

#Andre norske byer

Trenger du WordPress-utvikling i en annen norsk by, gjelder de samme norske rammene rundt betaling, frakt, MVA og personvern, men med lokal kontekst. Se også WordPress-utvikler i Bergen og WordPress-utvikler i Stavanger for hvordan arbeidet tilpasses der.

#Start prosjektet ditt i Trondheim

Trenger virksomheten din i Trondheim eller Midt-Norge en utvikler som kjenner både WordPress og de norske rammene rundt betaling, frakt, MVA og personvern, så ta kontakt for en uforpliktende samtale. Jeg går gjennom situasjonen, ser på dagens installasjon og gir en ærlig vurdering av hva som faktisk trengs, før vi blir enige om omfang og forventninger.