Hvem som gjør jobben
WPPoland er én erfaren programvareutvikler, Mariusz Szatkowski, som jobber med den delen av programvaren som handler om web og netthandel: serverkoden, integrasjonene mellom systemer og frontendene som ligger oppå dem. Utgangspunktet har vært WordPress siden 2006, og derfra har arbeidet vokst utover til WooCommerce, TypeScript og Node.js, headless frontender i Astro og Next.js og kode som kjører på kanten i Cloudflare Workers.
Det er en smalere definisjon enn “programvareutvikler” i vid forstand, og det er bevisst. Her finnes ikke noe mobilteam, ingen designavdeling og ingen stall av juniorer. Det du får, er personen som skriver koden, leser koden du allerede har, og står ansvarlig for den.
Hva en programvareutvikler for web og netthandel bygger
De fleste forespørsler faller inn under fem typer arbeid. De overlapper, fordi ekte systemer gjør det.
- Integrasjoner mellom systemer. En WooCommerce-butikk som må stemme med et ERP-system, en grossists prisfil, et regnskapsprogram eller et lager. Det vanskelige er sjelden selve API-kallet. Det vanskelige er å bestemme hvilket system som er fasit for lager, priser og ordrestatus, og hva som skjer når to av dem er uenige klokka to om natta.
- Headless frontender og kode på kanten. Astro eller Next.js oppå WordPress eller WooCommerce, rullet ut til Cloudflare Workers eller Pages. Verdt det når innholdsmodellen er stabil og hastighet eller sikkerhet betyr mer enn redaktørens visuelle sidebygger. Ikke verdt det for en presentasjonsside som endres to ganger i året.
- Butikkutvikling. Logikk i kassen, betalings- og fraktintegrasjoner (i Norge er Vipps et typisk eksempel på en betalingsløsning butikken må snakke med), ytelsesarbeid målt mot feltdata i stedet for en laboratoriescore, og utvidelseskoden som holder butikkens forretningsregler.
- Skreddersydd WordPress-programvare. Utvidelser med en ordentlig datamodell, bakgrunnsjobber, REST- og WP-CLI-grensesnitt og adminskjermer som redaktører kan bruke uten bruksanvisning.
- AI- og MCP-integrasjoner. Å koble et nettsted eller en butikk til AI-agenter på en måte som er skrivebeskyttet som standard, logget og mulig å reversere. Den offentlige MCP-serveren for WooCommerce som er beskrevet nedenfor, er et eksempel på den tilnærmingen.
Teknologien, og hvor hver del gjør seg fortjent
Et teknologivalg er en rekke avveininger, ikke en merkesamling. Dette er arbeidsverktøyene, og grunnen til at hvert av dem er med.
| Lag | Verktøy | Velges når | Velges ikke når |
|---|---|---|---|
| Server | PHP 8 på WordPress | Systemet trenger redaktører, brukere, et økosystem av utvidelser og rimelig hosting | Oppgaven er en langvarig tjeneste uten innholdsmodell |
| Netthandel | WooCommerce | Katalog, kasse og ordredata må bli i din egen database | Begrensningene i en hostet plattform er akseptable, og ingen vil drifte servere |
| Skript og tjenester | TypeScript på Node.js | Integrasjonsarbeidere, CLI-verktøy, MCP-servere, alt med en typet kontrakt | En jobb på ti linjer som WP-CLI allerede gjør |
| Datatjenester | Kotlin og Spring Boot | Langvarige importer og identitetsmatching over millioner av poster, med kø og en typet domenemodell | Kundens team vedlikeholder bare PHP |
| Lokal KI | Ollama via Spring AI | Klassifisering der kundens data aldri får forlate egne lokaler | En oppgave som enkle regler eller en oppslagstabell allerede løser |
| Frontend | Astro | Innholdstunge sider der det meste er statisk | Grensesnittet er en tett applikasjon med mye tilstand |
| Frontend | Next.js | Applikasjonslignende frontender med mye tilstand i klienten | Nettstedet består stort sett av dokumenter |
| Kant | Cloudflare Workers og Pages | Hurtigbuffer, videresendinger, små API-er og statiske bygg nær den besøkende | Jobben trenger en databasetilkobling som holdes åpen i flere minutter |
| Verktøy | Python | Datakontroller, dokumentanalyse, engangsmigreringer | Alt som kundens eget team skal vedlikeholde i PHP |
Språket betyr mindre enn grensene. God programvare her er programvare der du kan si hvilket system som eier hvilke data, hvilken kode som kjører hvor, og hvordan du angrer forrige tirsdags lansering.
Offentlig bevis du kan sjekke før du skriver
Påstander om ferdigheter koster ingenting. Dette kan kontrolleres uten en samtale.
- wppoland/woocommerce-mcp: en skrivebeskyttet Model Context Protocol-server for WordPress og WooCommerce, skrevet i TypeScript, MIT-lisens. Den har fem verktøy (produkter, enkeltprodukt, ordrer, en salgsrapport og søk i offentlige innlegg) og ingenting som kan endre butikken. At den er skrivebeskyttet som standard, er designvalget som er verdt å se nærmere på.
- wppoland/hidden-text-detector: et Python-verktøy som finner skjult tekst og prompt injection i PDF- og DOCX-filer, for eksempel hvit tekst på hvit bakgrunn, uleselig små skrifttyper, tekst plassert utenfor siden og usynlige Unicode-tegn. Det finnes fordi kontrakter og anbudsforespørsler nå kommer med instruksjoner ment for en AI-leser i stedet for et menneske.
- Plogins og profilen motylanogha på wordpress.org: Plogins er en pakke med 45 WooCommerce-utvidelser i gratis- og pro-utgave, bygget på PHP 8.1 med PHPStan, PHPCS og automatiserte utgivelser til wordpress.org og Freemius. 21 utvidelser i den offisielle katalogen oppgir denne profilen (sjekket 26. september 2026), blant dem Polski, en utvidelse for polsk tilpasning av nettbutikker (GPSR, Omnibus, GDPR), og GatherPress, en utvidelse for arrangementer i fellesskapet.
- Dette nettstedet. wppoland.com er bygget med Astro 7 på Cloudflare Pages, med seks språk og rundt 13 600 forhåndsgenererte sider. Hver endring går gjennom rundt femti automatiske kvalitetskontroller før lansering, fra døde lenker og schema-konflikter til en sitemap-kontroll som feiler når en side som skal indekseres mangler i alle sitemaps. HTML-minifiseringen ble flyttet over på arbeidstråder i september 2026 og gikk fra 910 sekunder til 199 sekunder på de samme 13 610 filene, med byte-identisk resultat.
Arbeidserfaring
Tjue år med webarbeid, det meste inne i andres systemer. Rollene nedenfor er offentlige på LinkedIn; kundenavn innenfor disse oppdragene holdes konfidensielle.
| Periode | Rolle | Hva det innebar |
|---|---|---|
| Siden okt. 2025 | Fullstack-utvikler (innleid), WP-Stars, Wien | En abonnementsplattform for medier og handel: et Composer-monorepo som beskriver hele WordPress-applikasjonen, CI med to uavhengige utgivelsesporter, abonnementsflyter i Stripe og en tjeneste i Kotlin og Spring Boot som samler ERP-, CleverReach- og adressedata i Mautic, med en lokal LLM (Ollama via Spring AI) som avgrenset klassifikator som kjører on-premise over millioner av poster |
| Siden okt. 2025 | Medarrangør, CMSConf, Gdynia | En konferanse om publiseringssystemer, arrangert fysisk i Gdynia |
| Siden jan. 2021 | WordPress-, WooCommerce- og PHP-utvikler (innleid), Equiqo, Berlin | Skreddersydd utvikling i WordPress, WooCommerce, HubSpot og Shopify på Roots-stakken (Bedrock, Sage), arbeid med ytelse og strukturerte data |
| 2020 | WordPress-utvikler, Itineris, Ipswich (Storbritannia) | Skreddersydd WordPress på Sage og Bedrock, CircleCI, ytelse og SEO |
| 2019 til 2020 | WordPress-utvikler (frilans), what., Zürich | Skreddersydd WordPress, ytelse og strukturerte data |
| 2016 til 2019 | WordPress-utvikler og teampilot, AirHelp | Flerspråklighet, AMP og ytelse på et forbrukernettsted med mye trafikk, bindeledd mellom avdelinger |
| 2007 til 2015 | Webutvikler og spesialist på internettmarkedsføring, Vector Group, Gdynia | Webutvikling, B2B-nettbutikker og søkemotormarkedsføring |
| Siden 2007 | WPPoland | Merkevaren alt selvstendig arbeid drives under |
Typiske oppdrag
Selve kundearbeidet er underlagt taushetserklæring, så casestudiene er anonymisert og sier det rett ut. Hver av dem beskriver problemet, fremgangsmåten og hva som kunne og ikke kunne måles.
- En treg WooCommerce-butikk for en B2B-selger, reddet ved å profilere kassen og databasen i stedet for å legge til en utvidelse for hurtigbuffer: ytelsesredning for WooCommerce.
- En tyskspråklig organisasjon som flyttet fra TYPO3 til WordPress uten å miste URL-strukturen eller redaktørenes vaner: migrering fra TYPO3 til WordPress.
- En utgiver som koblet redaksjonsflyten sin til AI-agenter gjennom en kontrollert MCP-server: MCP-server for en redaksjonsflyt.
- En headless WooCommerce-løsning på Cloudflare, forberedt for agentbasert handel: headless WooCommerce på Cloudflare.
- En skriftlig migreringsplan for å flytte et WordPress-nettsted til en headless frontend, inkludert delene som bør forbli som de er: plan for headless migrering.
- En integrasjon for AI-støttet innholdsproduksjon med menneskelig gjennomgang innebygd i hvert steg: integrasjon for AI-støttet innholdsproduksjon.
Tjenestesidene går dypere inn i hver teknologi: WordPress-utvikler, WooCommerce-utvikler, PHP-utvikler, Astro-utvikler, Next.js-utvikler, Cloudflare edge og utvikling av MCP-servere.
Frilanser, byrå eller programvarehus
Det ærlige svaret avhenger av hvor stort problemet er og hva som skjer etter lansering. Én erfaren utvikler er ikke alltid riktig valg.
| Situasjon | Erfaren frilanser | Byrå | Programvarehus |
|---|---|---|---|
| En integrasjon eller et redningsoppdrag med en tydelig ansvarlig hos deg | Passer godt: én person holder hele problemet | Ofte tregere i gang | Som regel for tungt |
| Et nytt produkt som trenger design, frontend og backend samtidig | Bare med din egen designer | Passer godt | Passer godt |
| Seks eller flere utviklere i løpet av en måned | Passer ikke | Mulig | Passer godt |
| Langsiktig vedlikehold av et WordPress- eller WooCommerce-system | Passer godt, med en skriftlig plan for kontinuitet | Passer godt | Sjelden deres fokus |
| En mobilapp | Passer ikke her | Avhenger av byrået | Passer godt |
| Du må kunne snakke med den som skrev koden | Alltid | Noen ganger | Sjelden |
Den reelle risikoen med en frilanser er kontinuitet: sykdom, ferie eller dagen vedkommende slutter å svare. Be om at det håndteres skriftlig. Her betyr det kode i ditt repository fra første commit, dokumentasjon ved siden av koden, tilgangsdata som du selv holder, og en overleveringsrutine som en annen utvikler kan følge.
Slik vurderer du en programvareutvikler
Uansett hvem du ansetter, skiller disse spørsmålene de som leverer, fra de som presenterer.
- Hvor ligger koden? Den skal ligge i ditt repository, under din organisasjon, fra første dag. En utvikler som beholder koden til fakturaen er betalt, holder den som gissel.
- Hvordan testes en endring før den når produksjon? Se etter et testmiljø, automatiske kontroller og en navngitt person som godkjenner lanseringer. “Jeg tester på det levende nettstedet” er et varseltegn.
- Hvordan angres en lansering? Spør etter veien tilbake, ikke veien ut. Hvem som helst kan rulle ut kode; færre har øvd på å gå tilbake.
- Hva ble målt før arbeidet startet? Påstander om ytelse, feilrater og konvertering betyr ingenting uten en utgangsverdi målt på samme måte.
- Hva vil du ikke gjøre? En utvikler uten uttalte grenser har enten ikke tenkt over dem, eller kommer til å oppdage dem på ditt budsjett.
- Kan jeg lese noe du har skrevet? Offentlig kode, en teknisk artikkel eller et designdokument. Stilen viser seg raskt: om forfatteren nevner avveininger, eller bare fordeler.
Arbeid i kode som noen andre har skrevet
De fleste oppdrag starter inne i et eksisterende system, ikke i et tomt repository. Den første uken går med til å lese, ikke skrive om.
- Kartlegg før du rører noe. Hvilke utvidelser og tjenester som holder forretningslogikk, hvilke cron-jobber og webhooks som kjører, hvilke data som ligger utenfor databasen (filer, hurtigbuffere, dashbord hos tredjeparter). Kartet legges i repositoryet som et kort dokument.
- Gjenskap problemet på en kopi. En kopi i testmiljø med produksjonslignende data, anonymisert der den inneholder kundeopplysninger, slik at en rettelse kan bevises før den går ut.
- Behold det som virker. Å skrive om er den dyreste måten å fikse et system på, og den enkleste å anbefale. Kode som er stygg, men korrekt og dekket av en test, blir stående; kode som er feil, byttes ut i små steg som kan gjennomgås.
- Etterlat det mer lesbart. Hver endring kommer med den sammenhengen en fremmed trenger: hvorfor den ble gjort, hva som ble målt og hvordan den kan angres.
Den samme regelen gjelder motsatt vei. Arver en annen utvikler arbeidet senere, skal vedkommende kunne fortsette ut fra dokumentasjonen i repositoryet uten å ringe noen.
Sikkerhet og dataene du overlater
En utvikler med tilgang til serverne og databasene dine utgjør en reell risiko, så håndteringen avtales skriftlig før tilgang gis.
- Tilgangsdata forblir dine. Tilgang opprettes per person i dine systemer og trekkes tilbake når oppdraget er over; ingen delte administratorpassord sendt på e-post.
- Produksjonsdata kopieres bare ved behov, lagres kryptert på utviklerens maskin, anonymiseres for testmiljøet der de inneholder personopplysninger, og slettes når arbeidet er ferdig. Etter personvernforordningen (GDPR) er dette behandling av personopplysninger på dine vegne, så en databehandleravtale hører med i papirarbeidet fra start, ikke som en ettertanke. I Norge er det Datatilsynet som fører tilsyn med dette.
- Endringer i produksjon kan spores. Hver lansering knyttes til en commit, og hver commit til en begrunnelse.
- Innkommende dokumenter kontrolleres. Kontrakter og anbudsforespørsler skannes for skjult tekst og prompt injection før noen, menneske eller AI, handler på dem. Det er dette hidden-text-detector, nevnt ovenfor, er laget for.
Slik foregår et oppdrag
Prosessen er skrevet ned, slik at ingen trenger å huske den.
- Skriftlig beskrivelse. Systemet, problemet, fristen, eksisterende repositorier og hosting, og hvem som bestemmer hos deg.
- Omfang med forutsetninger. Hva som er med, hva som ikke er med, og hva som må stemme for at estimatet skal holde. Design, wireframes og innhold kommer fra kunden og står oppført som det.
- Utgangspunkt. Tilgang, en kopi i testmiljø og målinger før noe endres, slik at “bedre” har et tall knyttet til seg.
- Ukentlige iterasjoner. Commits du kan gjennomgå, en demo i testmiljøet hver uke og beslutninger som noteres i repositoryet i stedet for i en chattetråd.
- Lansering og overlevering. En innøvd tilbakeføring, dokumentasjon og, hvis ditt team tar over, en overleveringsøkt med personen som skrev koden.
Betalingsvilkårene er en del av det skriftlige omfanget, med datoer i stedet for “ved ferdigstillelse”. Arbeidet starter når det avtalte forskuddet er mottatt.
Hva som ikke tilbys
Tydelige grenser sparer begge parter for en måned.
- Grafisk design, wireframes og UX-design. Oppsettet leveres av kunden, ofte som et enkelt regneark som viser hvilke elementer som hører til hver visning. Jobben er å gjøre det om til et fungerende, responsivt grensesnitt.
- Native mobilapper. iOS og Android er et eget fagfelt og løses bedre av en spesialist.
- Vaktberedskap døgnet rundt. Overvåking og rask respons i arbeidstiden, ja; en personsøker klokka tre om natta, nei.
- Å late som man er et team. Én person betyr én kalender. Store parallelle arbeidsmengder hører hjemme hos et byrå eller et programvarehus.
Hvor arbeidet skjer
Gdynia, på den polske østersjøkysten, i sentraleuropeisk tid, den samme tidssonen som Norge. Kundene er stort sett i Polen, Tyskland, Østerrike, Sveits, Norden og resten av EU, og arbeidet skjer eksternt med ukentlige demoer. Ved siden av kundearbeidet har Mariusz vært med i arrangørteamet for WordCamp Europe siden 2024, på budsjettsporet, for 2025-utgaven i Basel og 2026-utgaven i Krakow, og han er medarrangør av CMSConf i Gdynia.
Hvis problemet ditt er et web- eller netthandelssystem som må fungere pålitelig og være forståelig for den neste som åpner det, beskriv det skriftlig. Et svar med spørsmål eller et første omfang kommer som regel innen én arbeidsdag. Mer bakgrunn finner du på om meg-siden.
