Beyond the Brief

Heart Mend

FlutterFlow · ChatGPT API · Firebase

HeartMend started from a simple observation: the tools available for people going through emotional recovery are either clinical to the point of coldness or so light they feel meaningless. There was a gap between therapy apps and self-help content that no one seemed interested in filling properly.

So I built a mobile app that uses conversational AI to support emotional recovery through journaling, structured feedback, and pattern recognition. The app reflects back what users write about their emotional state over time, surfacing patterns they might not see themselves. It is not a therapist. It is closer to a mirror that pays better attention than you do when you are in the middle of something difficult.

Conceived, designed, and built end to end. The project taught me more about AI product design, emotional UX, and the distance between a feature list and something that actually feels useful than anything I have done inside a client brief.

Try it: type a message, drag the mood slider, or write in the journal

BurnerCookie

Firefox extension · WebExtensions API · Vanilla JS

BurnerCookie started from an observation that took me longer than it should have to see clearly. Third-party cookies are dying across browsers, which was supposed to reduce cross-site tracking. In practice the industry adapted by moving identity resolution into the publisher's own first-party storage, where browser defenses cannot reach. LiveRamp, ID5, UID2, Permutive, Adobe ECID and others now mint persistent identifiers that live in the same storage bucket as the site's login cookie and survive the tab close.

The extension is a small response to that. Mode 1 wipes all first-party storage on sites the user lists, every time those tabs close, using Firefox's container isolation as the burn mechanism. Mode 2 runs on every tab close across every site and targets around 80 known identity resolution vendor patterns, leaving the publisher's own state intact while removing the third-party identity layer that piggybacks on it.

Firefox-only by design, not preference. Firefox exposes container isolation and storage partitioning APIs that Chromium does not, and those are the primitives that make surgical per-site burning possible rather than the blunt clear-everything approach of most existing tools.

Currently in closed beta. Open source release on GitHub once the vendor pattern list has been validated against a wider set of publishers. The repo will host the pattern list separately from the extension code so the community can maintain it the way uBlock Origin filter lists are maintained. The interesting work on a project like this is not the extension itself. It is the ongoing curation of what to target.

Two modes: surgical per-site burning and global vendor pattern wiping

Hugin and Munin Stories

YouTube · Spotify · Audible · Podcast platforms

Hugin and Munin Stories is an independent audio and video content channel producing Norse mythology sleep stories for adults. It started because I wanted to see whether a single person could build, operate, and distribute a content product using AI across the full pipeline, from script to narration to multi-platform publishing.

Scripts are generated via LLM with manual refinement for tone and mythological accuracy. Narration was initially produced through ElevenLabs, then migrated to a self-hosted TTS pipeline using Piper and XTTS when it became clear that cost control at scale required owning the infrastructure. The full workflow from concept to distribution across YouTube, Spotify, Audible, iHeartRadio, and Amazon Music is managed independently.

Over 26,000 combined views and listens so far. The project is actively monetised through Podbean and continues to grow. What it proved was that the interesting challenge is not the AI generation itself. It is the operational design: building a repeatable production system that produces consistent quality without burning out or burning money.

Bifrost

Desktop application · Local-first AI · Python · FastAPI

Bifrost exists because local AI in 2026 has a packaging problem, not a capability problem. The models are good. The hardware is accessible. What has not been solved is the experience layer. Running a local AI stack today means managing competing tools, separate interfaces, and manual orchestration between services that were never designed to work together.

Bifrost is a desktop-first workspace that brings local AI services into a single, coherent environment. It is designed for people who have the hardware but not the patience for terminal commands, Python environments, and fragmented browser tabs. The project is in active development, with a product vision that has been through external review and a deliberately compressed scope.

The name comes from Norse mythology: the bridge connecting worlds that were never designed to talk to each other.

Architecture overview: three local AI services, one unified interface

BrewTour.se

Directus · Astro · Google Maps API (migrating from WeWeb · Xano)

BrewTour started from a straightforward problem: there was no good way to plan a craft brewery tour across Sweden. Information was scattered across Google Maps, Instagram, outdated websites, and word of mouth. Everything was flattened into the same shape, with no distinction between a serious taproom, a production brewery with a tasting room, and a tourist-friendly venue that happens to serve beer.

The project is a mobile-first brewery discovery and route planning app that combines map-driven UI, dynamic filtering, and personalised tour planning. The goal was not to build another directory. It was to design a discovery experience that helps people distinguish between types of venues, understand what makes each place interesting, and move through a region with more confidence.

BrewTour is still in active build, and the stack is shifting. The project started on WeWeb and Xano, which was the right call for a quick prototype but became a constraint as the product thinking outgrew the platform. The infrastructure is being reconsidered with the same logic applied to this site: choose the tool that fits the problem, not the one that was convenient at the start. What the project demonstrates is the ability to see a fragmented discovery problem, frame it as a product opportunity, and design an experience around how people actually make decisions, not just where the data lives.

Map-driven discovery with region filtering and venue cards