https://marcusjenshaug.no Fullstack-utvikler i Redi AS. Jeg bygger webapplikasjoner med Next.js, TypeScript og Supabase, og deler det jeg lærer underveis. nb-NO https://marcusjenshaug.no/blogg/soeknadsbasen-verktoeyet-jeg-ikke-fant-sa-bygget-selv https://marcusjenshaug.no/blogg/soeknadsbasen-verktoeyet-jeg-ikke-fant-sa-bygget-selv Fri, 24 Apr 2026 09:39:52 GMT Et CV-verktøy og jobbsøker-tracker som startet som frustrasjon over eksisterende løsninger, og ble til et lite produkt jeg faktisk bruker selv. solodevnextjssupabaseproduktutviklingjobbsøking https://marcusjenshaug.no/blogg/to-og-et-halvt-ar-som-eneste-utvikler https://marcusjenshaug.no/blogg/to-og-et-halvt-ar-som-eneste-utvikler Mon, 20 Apr 2026 16:50:00 GMT En retrospektiv etter å ha bygget Eiendomsavtaler.no fra første linje kode. Fra innleid konsulent til grunnleggers-utvikler, gjennom tre tekniske generasjoner. `" , 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](https://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](https://eiendomsavtaler.no).]]> arkitektursolo-utviklingretrospektivplattformwordpressnextjs https://marcusjenshaug.no/blogg/hva-jeg-laerte-av-a-bygge-klink-alene https://marcusjenshaug.no/blogg/hva-jeg-laerte-av-a-bygge-klink-alene Thu, 02 Apr 2026 04:23:00 GMT Et drikkespill-webapp som skulle være en helgeprosjekt, og ble til en skole i scope, arkitektur og det å levere noe ferdig. Math.random() - 0.5)`, som er en klassisk antipattern , den er ikke uniform, og noen kort havner statistisk oftere tidlig eller sent i bunken. Jeg byttet til [Fisher-Yates](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle): ```typescript function shuffle(array) { const result = [...array]; for (let i = result.length - 1; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [result[i], result[j]] = [result[j], result[i]]; } return result; } ``` Jeg vurderte kort å bruke `crypto.getRandomValues()` for å få kryptografisk tilfeldighet. Så minnet jeg meg selv på at dette er et drikkespill. `Math.random()` gir biased bits i det fjerde desimalet. Ingen kommer til å merke det. Et prinsipp jeg prøver å huske: løsningen skal være så robust som problemet krever, ikke som problemet kunne tenkes å kreve. ## Designet er forskjellen Klink er ikke det eneste norske drikkespillet på nett. Det finnes et som heter Børst som er bygget godt og har vært der lenge. Jeg brukte tid på å velge en visuell identitet som ikke kunne forveksles: - Lime og mørkegrønn som dominerende farger (Børst er blå/oransje) - Sans-serif med karakter, ikke generisk - Glass-morphism med hvite container-kort på fargede bakgrunner - Et easter egg , "Athina-modus" , som aktiveres ved 10 trykk på logoen og bytter hele appen til leopard + rosa. Jo flere slike småting, jo mer personlighet. Det er et paradoks her. Den tekniske delen av Klink er solid håndverk men ikke imponerende , Next.js og Supabase gjør 90% av jobben. Designavgjørelsene er det folk husker. Det lærte meg å bry meg mer om detaljer jeg tidligere ville delegert. ## Deploy-flyten som faktisk holder På Eiendomsavtaler.no bygget jeg en CI/CD-pipeline med steg, tester, staging, godkjenninger, alt. Det var riktig der. På Klink har jeg: `git push origin master`. Vercel merger til produksjon hvis build passerer. Det er det. Ingen staging. Ingen manual approval. Ingen "post-deploy smoke test". Dette er ikke latskap , det er riktig størrelse for problemet. Klink har én utvikler, ingen SLA, ingen kunder som blør penger hvis siden er nede i ti minutter. Kompleksiteten i en CI-pipeline må stå i forhold til kostnaden av en feil. ## Hva jeg skulle gjort annerledes 1. **Skrevet database-schemaet på papir først.** Jeg endret spillpakker- og kort-tabellene fire ganger fordi jeg ikke hadde tenkt gjennom relasjonene. Supabase-migrasjoner er greie å rulle ut, men det eter tid. 2. **Laget et admin-panel tidligere.** Jeg redigerte kort direkte i Supabase-dashboardet i månedsvis. Et enkelt skjema hadde spart meg for timer. 3. **Ikke ventet med PWA-oppsett til slutten.** next-pwa er forholdsvis greit, men service workers har egne regler for caching som krasjer med Next.js ISR hvis du ikke tenker over det. Enklere å sette det opp fra dag én. ## Hvorfor det var verdt det Klink har ikke tusenvis av brukere. Det er ikke et forretningsbygg. Men det var den første appen jeg leverte fra idé til produksjon helt alene , uten team, uten kunder, uten noen å skylde på hvis noe ikke var bra nok. Det lærte meg at jeg kan levere et helt produkt selv. Det er en annen type selvtillit enn å levere godt innenfor et team. Begge er viktige, men den første får du bare ved å gjøre noe ferdig helt alene. Appen finner du på [klinkn.no](https://klinkn.no). Koden ligger [på GitHub](https://github.com/MarcusJenshaug1/klink). Koden inneholder en overraskelse eller to.]]> nextjssupabasepwasideprosjekt