To og et halvt år som eneste utvikler

Jeg kom inn i Eiendomsavtaler.no høsten 2023 , først som innleid konsulent gjennom mitt eget byrå, Spiderweb AS. Det fantes ingen teknisk plattform ennå. Jobben var å bygge den. I januar 2025 ble jeg fast ansatt, og samme år la jeg ned Spiderweb for å fokusere fullt på Eiendomsavtaler. Jeg var eneste utvikler. Alt fra arkitektur til produksjon, fra sikkerhet til overvåkning, lå hos meg.

I mai 2026 gir jeg det fra meg. Plattformen er i stabil drift, har vært det lenge, og det er ingen dramatisk grunn til at jeg slutter , jeg skal videre til Redi AS og bygge andre ting. Men overgangen er en god anledning til å skrive ned det jeg faktisk har lært. Ikke på LinkedIn-format med "drev vekst og optimaliserte ytelse", men det som sitter i kroppen etter to og et halvt år.

Tre generasjoner på to og et halvt år

Det første du må vite er at jeg bygget plattformen gjennom tre tekniske generasjoner.

Generasjon 1 var en WordPress-installasjon. Advanced Custom Fields for strukturerte skjemaer, WP User Frontend for opplasting, WP Statistics for sporing , plugin-stacken man ender opp med når man trenger å komme fort i gang og validere at produktet har en rolle i markedet. Jeg valgte det bevisst. Et MVP skal leveres, ikke være arkitektonisk imponerende.

Generasjon 2 var min første Next.js-app , en investor-plattform, et sideprosjekt innenfor samme organisasjon. Jeg skrev den mens jeg fortsatt driftet WordPress-siden. Den var i praksis min læringsarena: første gangen jeg jobbet med App Router, server components, server actions. Den lever fortsatt, men ble aldri produkt-hovedkanalen.

Generasjon 5 (ja, vi hoppet over 3 og 4 , mer om det under) er den som kjører i dag. Full rewrite til TypeScript, Next.js, PostgreSQL. Ingen WordPress igjen. Dette er det jeg overleverer.

Hvorfor versjonstellingen hopper

Versjonene 3 og 4 er ikke rewrites , de er arkitekturutkast som aldri ble deployet. Jeg prøvde først en tyngre tilnærming med et separat backend-API og Next.js som ren frontend. Det var overdimensjonert for et team på én. Så prøvde jeg en arkitektur med mer spesialiserte moduler. Også overdimensjonert.

Det jeg landet på i Versjon 5 var kjedelig: én Next.js-app med server actions, PostgreSQL som primærdatabase, bildebehandling via sharp, type-validering med zod. Ingen microservices, ingen separate API-er, ingen eventing bus jeg ville brukt tre måneder på å sette opp riktig.

Den viktigste leksjonen fra de forkastede versjonene var at kompleksitet straffer seg eksponentielt når du er alene. Hver abstraksjon du legger til er en ting bare du kjenner, bare du kan feilsøke, bare du kan endre. Og om to år er ikke engang du sikker på at du husker hvorfor.

Hvorfor jeg tok det

Eneste-utvikler-jobber er polariserende i bransjen. Halvparten advarer deg: ingen pair programming, ingen kode-gjennomgang, ingen å sparre med, fullt ansvar når ting feiler klokka tre på natta. Den andre halvparten snakker om eierskap, fart og fravær av komitéer.

Begge sider har rett. Ingen av sidene forbereder deg på hva det faktisk er å gjøre det.

Grunnen til at jeg sa ja var ikke romantikken rundt "bygge alt selv". Det var at jeg ville vite om jeg kunne. Jeg hadde jobbet i team i flere år, og jeg hadde alltid hatt en følelse av at når noe gikk bra, var det fordi teamet var godt. Jeg visste ikke hva som var meg og hva som var dem. Å være eneste utvikler er den eneste måten å finne ut av det på.

Det jeg undervurderte

De første månedene gikk på tekniske avgjørelser. Rammeverk, hosting, database, auth, overvåkning. Jeg hadde en arkitektur jeg var fornøyd med på papiret, og jeg fikk den til å kjøre.

Det jeg ikke hadde planlagt for var alt det andre. En eneste-utvikler er ikke bare utvikleren. Du er også:

• Sikkerhetsansvarlig som må følge med på CVE-er
• DevOps-ingeniøren som eier deploy-pipelinen
• Databaseadministratoren som må svare "hvorfor er det tregt nå?"
• Supporten når noe ikke funker for en kunde klokka 16:30 fredag
• Tech-lead-en som må si nei til features som er kule men unødvendige
• Product-en som oversetter "kan vi ikke ha en knapp som..." til noe faktisk utviklbart

Det siste er det jeg ble dårligst forberedt på. Kode er overraskende lite av jobben når du er alene. Mye mer av dagen går til kommunikasjon, prioritering og å forklare hvorfor ting tar den tiden de tar.

WordPress hadde noen av svarene

Noe av det jeg synes var mest overraskende underveis var hvor mye WordPress faktisk hadde rett om. Jeg hadde utviklet i WordPress før, og jeg visste at stacken har dårlig rykte blant mer "moderne" utviklere. Men det løser reelle problemer veldig effektivt:

• Strukturerte skjemaer uten å skrive dem (ACF)
• Brukergenerert innhold med moderering (WP User Frontend)
• Analyse uten tredjeparts-trackere (WP Statistics)

Da jeg bygget v5, måtte jeg re-implementere hver av disse. Og det er mye kode for noe som før fyltes ut på femten minutter i et admin-panel. Det jeg vant var typesikkerhet, bedre performance, og kontroll over hele stacken. Det jeg tapte var utviklings-hastighet på ting som WordPress bare hadde løst.

Konklusjonen min etter migreringen er ikke "WordPress er dårlig" eller "egen-bygget er bedre". Det er at valg av rammeverk er en kalibreringsøvelse, ikke et prinsipp. WordPress var riktig valg for den fasen plattformen var i. Det er ikke riktig for denne fasen. Neste fase får vise om v5 fortsatt er det riktige valget.

Å være sin egen kode-reviewer

Den tyngste enkelt-øvelsen i å være alene er å vurdere sitt eget arbeid nøkternt. Det er kjent, det er skrevet mye om, og likevel var det vanskeligere enn jeg trodde.

Når du er i et team, får du motstand. Noen spør "hvorfor gjorde du det sånn?", og du må forsvare valget , og noen ganger innser du midt i forsvaret at du ikke har et godt svar. Uten den motparten forsvinner forsvaret også. Du skriver kode, du merger den, du glemmer hvorfor.

Det jeg landet på var to enkle ting:

Å skrive små commits med tydelige meldinger. Ikke fordi noen skulle lese dem senere , ingen skulle , men fordi jeg som skrev dem, tvang meg selv til å formulere hva jeg hadde gjort og hvorfor. Jeg kom i det minste halvveis til en begrunnelse.

Å la det ligge over natten før merge når det var stort. Kveldsgløden etter at noe endelig funker er den verste reviewer. Morgen-meg er en strengere kollega enn kveld-meg.

Ingen av disse erstatter en ekte pair. Men de to sammen gjorde at jeg tok færre dumme snarveier enn jeg ellers ville gjort.

Om å bygge for én klient du aldri møter

Eiendomsavtaler.no har reelle brukere. Megler-profesjonelle, eiendomsaktører, folk som bruker plattformen for å lande faktiske avtaler. Jeg har aldri møtt noen av dem ansikt til ansikt. Det jeg visste om dem, visste jeg gjennom forretningssiden , folk som oversatte behov til meg og tok mine tekniske svar tilbake til dem.

Det formet hvordan jeg jobbet. Jeg måtte bli flinkere til å stille spørsmål som ikke forutsatte at jeg hadde sett problemet selv. "Hva prøver brukeren å gjøre når dette feiler?" i stedet for "hva er feilen?". Det første gir deg kontekst. Det andre gir deg en stack trace.

Når du jobber alene uten direkte brukerkontakt, er forretningssiden din eneste bro til virkeligheten. Jeg lærte å respektere den rollen mye mer enn jeg gjorde før.

Performance-arbeidet jeg lærte mest av

En av de mest lærerike øvelsene i v5 var ytelses-arbeidet. Jeg førte en enkel audit-fil i repoet der jeg noterte hvilke sider som trakk ned, hva som forårsaket det, og hva jeg gjorde for å fikse det. Ingenting avansert , bare en markdown-fil som vokste over tid.

Det jeg lærte av den øvelsen var at de fleste performance-problemer er kjedelige. Det er sjelden at løsningen er "bytt til en raskere runtime" eller "implementer en cache-strategi". Oftere er det at et bilde ikke er lazy-loaded, en database-spørring henter mer enn nødvendig, eller en komponent rendres klient-side fordi utvikleren (altså jeg) glemte å sjekke om den kunne kjøre server-side.

Kjedelig fix, stor gevinst. Den typen arbeid belønnes ikke av det tekniske miljøet , ingen holder foredrag om "jeg la til sizes-attributten på <Image>" , men det er det som faktisk utgjør forskjellen i Core Web Vitals.

Hvorfor enkle løsninger vant

Jeg begynte prosjektet med en arkitektonisk ambisjon som var litt for stor for problemet. Microservices her, event-drevet der, queue for de tunge jobbene, Kubernetes en gang i fremtiden. Ingen av det var teknisk feil , det var bare feil størrelse.

Det jeg endte med var mye nærmere kjedelig. En monolitt med klare grenser mellom moduler. En primærdatabase med replika. En cache-lag på de åpenbare stedene. CI/CD som er rett-frem nok til at jeg kan gjøre endringer i den uten å være redd for å brekke den. Overvåkning som gir meg to-tre metrics jeg faktisk følger med på, ikke tjue jeg ignorerer.

Grunnen til at dette funket er ikke at jeg hadde rett i mine valg. Det er at jeg var eneste utvikler, og kompleksitet straffer seg eksponentielt når du er alene.

Hvis jeg bygget den samme plattformen i dag, ville jeg begynt enda enklere.

Det som var verdt det

Det jeg tar med meg videre er ikke at jeg klarte det , det var aldri spørsmålet. Det jeg tar med meg er at jeg nå har en kalibrering på hva som faktisk koster tid når du eier hele stacken. Jeg vet hva "vi må bare få det ut" betyr for en real-world deploy, ikke bare for en sprint. Jeg vet hva det kveles av når en arkitektur er for stor for teamet som skal drifte den. Jeg vet hva du vinner ved å bytte fra et ferdig rammeverk, og hva du taper.

Den kalibreringen er vanskelig å få på annen måte. Det koster deg to og et halvt år, en del helger og noen kvelder du skulle ønske du kunne hatt tilbake. Men den sitter når du får den.

Hva som skjer nå

Plattformen lever videre uten meg , overleveringen har vært ryddig, dokumentasjonen er der, og det nye teamet har fått tilgang til alt som trengs. Jeg går videre til Redi AS og fullstack-utvikling i et multi-tenant produkt, der jeg er én utvikler blant flere. Det blir en annen jobb på måter jeg nok fortsatt undervurderer.

Men jeg tror det blir enklere å være en del av et team når man vet hva man faktisk bidrar med , og hva man trenger fra de andre.

Du finner plattformen på eiendomsavtaler.no.