Hey, I'm Christian.

I studied front-end development at Medieinstitutet in Gothenburg, and started working professionally in 2018 alongside my studies, on small WordPress sites. Since then I've worked across both ends of the industry: product companies building one thing for years (Enginio, a Vue.js platform for advertising campaigns, from its early startup days through acquisition by Nordic Retail Group), and consultancies moving between several clients at once, most recently Dear Friends and Nexer AB, working with clients like PostNord, Nordic Wellness, and Inera (the 1177 healthcare platform).

I work across the stack: React, Vue, and Angular on the frontend, Node, .NET, and PHP on the backend, React Native and Expo for mobile, plus Umbraco and WordPress for content-driven sites. Outside of work that range extends further: Kotlin for native Android modules, Python (FastAPI, SQLModel) for backend services, Astro for static sites, and Ansible, Docker, and GitOps for infrastructure. The project I'm proudest of from that consulting work is a React Native app I built solo for Göteborgs Stadsmission, connecting people donating surplus food with people who need it across the city. On the frontend I care about design and UX as much as I care about how things work underneath.

My first real production codebase was an internship at Plejd, a Swedish smart-home company, working in a 100,000+ line Angular.js/Vue.js application used by 50+ employees daily. I still think about that codebase whenever I'm deciding how much structure a new project actually needs.

A few concrete things I've done that don't fit neatly into a job-history bullet: reverse-engineered a proprietary Bluetooth wire protocol from an MIT-licensed reference and real hardware captures, replacing a vendor SDK with a from-scratch Kotlin implementation verified byte-for-byte against a Python reference before it ever touched a real board. Built a regression pipeline that fits per-rider physics constants (rolling resistance, aerodynamic drag, drivetrain efficiency) from GPS and battery telemetry via ordinary least squares, sourced against real engineering references rather than picked by feel. Designed and shipped a marketing site from a blank Astro file, hand-rolled touch interactions, a shared lightbox component, and scroll-snap behavior included, not a template. Cut a production app's initial load time by more than half through lazy loading and bundle optimization at Nordic Retail Group. And I plan architecture changes deliberately: multi-brand support in Cityroam was sequenced behind the prerequisites it actually needed rather than bolted on early to demo faster, and it now runs a second manufacturer's scooter at full feature parity on a protocol with no SDK and no documentation at all.

The two projects on the home page, Cityroam and casa-verde, aren't side projects in the "unfinished repo" sense. Cityroam is an Android app that talks directly to electric boards and scooters over Bluetooth protocols I reverse-engineered and reimplemented myself, no vendor SDK left in it at all, plus a backend that fits its own physics model to estimate range; it's in closed beta now. casa-verde is the platform it runs on: about ten containers across five separate systems that I run, monitor, and document like it's someone's job to keep it up, because for a few hours a week it is.

I keep a written decision log for casa-verde: 82 short documents and counting, each one explaining why a particular call was made, including the times I had to revert something that made things worse. That habit, writing down the reasoning and not just the result, is the same one I bring to code review and architecture discussions at work, and it's the same reason Cityroam's own research and planning docs, protocol notes and device-abstraction plans included, get written before the code does. Both repos are private, so those write-ups and the blog posts here are the readable version.

I've also spent a lot of time running local models for a home voice assistant, mostly to learn where they're actually reliable versus where they confidently make things up, a distinction that matters a great deal once a model is controlling real devices in my house. That work is where most of what I know about running AI in production came from, including a latency problem I fixed by scoping the model properly rather than buying a GPU, and a regression I caused and had to roll back the same day. There's more on that in the AI section on the home page.