Joel Freeman

Projects

Things I've built at work, as a founder and on my own time.

AAll projects
3 projects
Fig. 01Side project · 2026

what

One place for every agent session I have running across Claude Code and Codex, and every promise I made in Slack or a meeting.

  • Electron
  • TypeScript
  • SQLite
  • Claude Code
  • Codex

whatA local daemon keeps everything in one SQLite archive on my machine and works out where each session is at.

Map

A desktop app and CLI that pulls in my agent history, works out where each session is at, and builds a view of each day: what needs me, an overview, and a section for each piece of work. Everything stays on my machine in a local SQLite archive, and the sources are never changed. Search, a week view, the work still open in each project and Ask, which answers with citations, all read from the same archive.

Fig. 02313 Management · Co-founder · 2026 - now

Atlas

A commercial product for music festivals that I co-founded. Atlas brings a festival's ticket sales, its app and what happens on site into one place. I'm the sole engineer, so I built the platform and the mobile app and run both in production.

  • Next.js
  • Prisma
  • Postgres
  • Expo
  • React Native
  • Vercel Workflows
Visit site

AtlasAtlas keeps one record per event, artist and attendee, so each person is known across every event and the app: spend, returning, home city and music taste.

Atlas APIOne Next.js app on Vercel serves the web console and the REST API, keeps staff and attendee sign-in apart, and checks every caller before it reads any data.

Map

I built Atlas to connect a festival’s ticketing history with what attendees do before and during the event. It combines previous purchases, entry scans, artist favourites, saved sets, app engagement and on-site behaviour into attendee profiles across an organiser’s historic festivals and events. Its first paying customer is a major New Zealand New Year’s festival with about 10,000 attendees.

The platform is a TypeScript monorepo containing a Next.js management console and REST API, an Expo and React Native app for iOS and Android, and shared packages for database access, validation and attendee screens. Prisma and Postgres hold the operational data, while shared Zod schemas define the contracts between the server and clients. Organisation-scoped queries keep each customer’s events, ticketing sources and reports separate.

I built the Atlas web frontend in Next.js 16 and React 19, with Tailwind CSS v4, shadcn/ui components on Base UI, and Motion for animation. It gives organisers a workspace for managing event history, ticketing sources and attendee profiles, alongside event-specific tools for editing lineups, venues, messages and app content. Analytics screens combine charts, tables and spatial heatmaps to explore ticket sales, artist interest, app engagement and crowd movement. The frontend uses a typed REST client, and shared attendee UI components let staff preview app screens before publishing.

Atlas imports event catalogues, people, orders, tickets and available scan records from Flicket and Moshtix. Normalised email matching links ticketing records to attendee app accounts, whether the tickets arrive before or after account creation. Organisers can then see each matched attendee’s events, ticket value and entry scans alongside their app activity. Reports distinguish purchases from observed attendance, so owning a ticket does not automatically count as attending an event.

The mobile app is the attendee-facing part of the platform. I used Expo Router for navigation, HeroUI Native components styled with Uniwind, Zustand for local state, and React Native Reanimated for animation. Attendees sign in through email OTP, browse artists and set times, favourite artists and build a personal lineup with clash detection. Favourites persist locally and queue changes for server synchronisation. Device-local reminders notify attendees before sets and reconcile when published content changes a performance’s time, stage or availability.

The app also includes a ticket wallet with full-screen QR passes. It caches the last confirmed ticket data, shows when it was last checked and increases screen brightness while a usable pass is visible. Native session credentials live in SecureStore. The festival map currently uses an interactive illustration with searchable places and predefined walking paths; its displayed location marker is illustrative.

I designed festival content around verified releases stored on the device. Publishing snapshots the draft, builds an immutable artifact, uploads it to Vercel Blob and verifies it before transactionally moving the live release pointer. The app validates the artifact’s schema, release metadata, byte length and SHA-256 hash, then downloads and verifies required assets before activation. A failed update preserves the previous working release. After the first successful installation, attendees can browse installed festival content without reception, while later refreshes bring in published changes.

The app captures engagement events through a durable local queue, uploads them in bounded batches and removes them after server acknowledgement. Separate location telemetry uses Expo Location and TaskManager for permission-based foreground and background recording, with a SQLite outbox that survives app suspension. Both the phone and server enforce the configured site boundary. Atlas derives zone visits, dwell time, stage presence and heatmaps from these observations, showing how participating app users move through the site and where crowds build throughout the day.

Push notifications run through Vercel Workflows and Expo Push, with persisted delivery attempts, provider tickets and receipt checks. Validated deep links take attendees to relevant app content. Atlas also includes Ask Atlas, which turns organiser questions into permission-checked analytics queries and reusable dashboards. Numerical answers reference stored report results, keeping the displayed figures tied to the reporting system.

The engineering work centres on keeping content, identity and analytics consistent across unreliable connections. Verified releases protect the attendee experience, durable device storage preserves local activity, and the Atlas frontend brings those observations together with the organiser’s full event history.

Fig. 03Starboard · 2025 - now

Kubernetes platform

At Starboard, I built the internal Kubernetes platform that every service runs on today and migrated all services onto it. It centres on self-service: a single-file service contract brings together alerting, routing, networking, deployment, configuration and delivery pipelines, so engineers can ship without managing each layer separately.

  • GKE
  • Argo CD
  • Kargo
  • Kyverno
  • OPA
  • Helm
  • Envoy Gateway
  • Terraform
  • GCP PAM

Service contractAbout ten lines per service drive its deployment, secrets, network policy, gateway routes and alerts, with no platform ticket.

I joined as the first dedicated infrastructure engineer and took the platform from roadmap and architecture through implementation, production migration and team ownership. I built the core Kubernetes delivery platform and Terraform cloud foundation, with shared patterns for deployment, secrets, networking and monitoring. The goal was to let application engineers ship safely without needing a platform engineer for every change. A short service definition replaced bespoke configuration, while automated checks made proposed changes visible during review. More than 15 engineers now deploy through the platform, and a teammate onboarded 12 services without my help. I also planned and led the production migration, built the validation and rollback tooling, and completed the move without downtime or a code freeze. That work retired 50 bespoke CI workflows and gave teams a consistent delivery path. After establishing the platform, I grew the infrastructure function from one person to a team of four, hiring and mentoring the engineers who now own it with me.

Service contract

One service definition of about ten lines, on a three-chart Helm family, replaces a platform ticket. It drives:

  • Deployment
  • Secrets from Secret Manager
  • Network policy
  • Gateway routes
  • Alerts