Slik jobber en dedikert
WordPress-utvikler
Å leie en WordPress-utvikler burde være enkelt. Det er det sjelden. Mange leverandører løser hvert behov med enda en plugin fra katalogen, og etter et par år sitter dere igjen med en page builder i bunn og en kodebase ingen helt tør å oppgradere. En senior-utvikler fra PXL jobber motsatt. Funksjonalitet skrives som egen kode i Git, og WordPress behandles som det rammeverket det faktisk er i 2026 — moderne PHP 8.4, ikke en bloggmotor fra 2005.
Trenger dere egne Gutenberg-blokker, eller en integrasjon mot Tripletex som forrige leverandør aldri turte å ta i, bygger vi én plugin for akkurat den jobben, med tester og dokumentasjon i repoet. Én plugin som gjør hele jobben, framfor fem halvgode fra katalogen som hver tar sin bit. Det er samme filosofi som i vår enterprise WordPress-utvikling. Her leier du den bare per dag.
Hver eneste endring leses av en annen senior-utvikler. Deretter kjører CI/CD-pipelinen de automatiserte testene og ruller endringen ut i produksjon. Migreringer går gjennom WP-CLI, slik at de er reproduserbare og kan rulles tilbake. Vi gjør ingen «rask fiks» over FTP rett i tema-filene på live-serveren. At dette fortsatt er unntaket i WordPress-bransjen, sier vel mer om bransjen enn om oss.
Gevinsten er usynlig i uke én. Den dukker opp etter et år, når Redis-cachen fortsatt treffer, plugin-listen fortsatt får plass på én skjerm og ingen har rukket å gjøre en «midlertidig» løsning permanent. Per time koster egen kode mer. Per år koster den mindre, og differansen vokser for hvert kvartal kodebasen holder seg ren.
År med WordPress i produksjon
Garantert responstid med SLA
Deploys i en vanlig uke
Plugins uten en jobb å gjøre
Lei en WordPress-utvikler fra én dag i uken
Én dag i uken
To dager i uken
Tre+ dager i uken
WordPress-utvikler fra PXL mot vanlig leverandør
Når bør du leie en WordPress-utvikler?
- 01
Backloggen vokser i den ene enden og står stille i den andre. Småsaker blir liggende i månedsvis fordi «utvikleren ikke har tid».
- 02
En jobb på tre timer krever tilbud og estimat først — og deretter to ukers ventetid.
- 03
Siden er forretningskritisk, men kompetansen som bygde den er borte. Frilanseren svarer ikke, og byrået er lagt ned.
- 04
Koblingen mot ERP eller CRM virker, men ingen tør å røre den. Betalingsintegrasjonen enda mindre.
- 05
Plugin-listen passerte 40 for lenge siden. Hvilke som faktisk er i bruk, vet ingen.
- 06
Rapportene fra forrige leverandør var fakturaer. Hva som ble gjort, og hvorfor, står fortsatt ubesvart.
- 07
Dere vurderer å ansette, men har ikke fem dagers arbeid i uken til en utvikler.
Fra første prat til faste dager
Eksisterende kode? Det er hverdagen
Nesten ingen kommer til oss med blanke ark. Det vanlige er en side et byrå bygde for fem år siden, og som skiftende frilansere har lappet på i etterkant. Dokumentasjon finnes sjelden, og frilanseren som kunne den best, svarer ikke lenger på e-post.
Første steg er aldri kode. Først leser vi den som allerede ligger der — fra functions.php og wp-config ned til tabellene pluginene har strødd rundt seg i databasen. Deretter, og først deretter, begynner vi å endre.
Gjennomgangen ender i en skriftlig rapport som skiller det som er solid fra det som er teknisk gjeld, og flagger det som kan velte siden om det får ligge. Vi skriver den i klartekst, så en daglig leder kan lese den uten ordliste. Noen kunder har brukt rapporten til å velge en annen leverandør, og det lever vi fint med.
Forvent ikke at vi foreslår full omskriving i første møte. De fleste kodebaser kan reddes med systematisk opprydding under versjonskontroll, og med drift og vedlikehold i bunn holder de seg friske i årevis etterpå. Når det gjelder pris, ligger alle tallene samlet på én side om WordPress-priser.