The whole stack. One person.

Work

A charity platform, small-business sites on custom CMSs, university systems and a public archive.

• Solent Gay Men's Chorus

  Registered charity. The whole platform, built and run by me.

  • One identity service for every app, with passkey sign-in and a role hierarchy.
  • Stripe payments taken directly by the box office, so there is no third-party handling fee on top of Stripe's. Ticket sales and events.
  • Client-rendered and still indexed. Every public route is snapshotted in headless Chromium on GitHub Actions and served by nginx as static HTML, so crawlers and link unfurlers that run no JavaScript get the whole page. The browser is never run on the server.
  • A CMS edit re-renders the routes it touches and pings IndexNow; the snapshot lands in a minute or two. A full render twice a day is the backstop and prunes deleted pages.
  • Per-page title, description, canonical, Open Graph tags and JSON-LD (Event with offers, Article), set on the client and captured in the snapshot. The sitemap is generated from the CMS, with images.
  • A governance system built to manage becoming a CIO. I also wrote the policies and the new constitution.
  • Media library on object storage behind Cloudflare.
  • Social media hooks, member email and a CMS the committee edits itself.
  • Five Node services: main website, box office, governance, members portal and identity. Content in Payload.
  • All five share one 2GB server behind nginx, deployed from GitHub Actions.
  • Email domain at DMARC p=reject, with DKIM aligned.

• SUMS

  Single-blind double-marking platform for a university, with automated reconciliation.

  How it is built: SUMS

  • Single-blind double marking with automated reconciliation, and allocation of supervisors and moderators to projects.
  • Federated login through the institution's single sign-on: no local accounts to manage or to attack.
  • In production since 2018 on Google Cloud, with no servers to run and a full audit trail.
  • About 600 projects a year: 350 undergraduate and 250 master's, plus resits and two international partner programmes. About 100 markers a year.
  • More than 4,800 projects marked since 2018.

• Student feedback platform

  Commissioned by a university, designed from research with students and staff. In testing.

  How it is built: Student feedback platform

  • Replaces Evasys, which had no direct links to surveys and no integration with other systems.
  • Annual surveys and module pulse surveys.
  • Next.js and TypeScript on Vercel, with Postgres on Neon and Prisma.
  • Anonymity is enforced by the schema: a response cannot be joined to the student who wrote it.
  • LLM features flag concerning sentiment immediately and aggregate common themes for staff and reps. They sit behind a swappable provider interface.
  • In testing.

• Survey analysis dashboard

  National Student Survey analysis for a whole university. Adopted across a faculty. In use since July 2026.

  How it is built: Survey analysis dashboard

  • Running within three hours of the national results being published.
  • Reads the Office for Students' National Student Survey workbooks and full-data extract directly.
  • Rolls up institution, faculty, school and course, with year-on-year comparison when two years are loaded.
  • Concern flags: five points below the institution's own figure, below 70% overall, or a fall of more than five points in a year.
  • Nine years of tagged free-text comments (2018 to 2026) analysed deterministically for consistent, new and receding themes.
  • A local model through Ollama handles the sentiment analysis and writes the per-unit narratives, so no cloud AI service saw student comments. Output is paraphrase and counts only, scanned for personal details.
  • Node and vanilla JavaScript ES modules, with tokenised CSS. No framework.
  • Google sign-in limited to the institution's domain, verified server-side, with a signed session cookie. Raw comments sit behind an allowlist of senior staff.
  • The test suite recomputes every school and faculty mean and standard deviation independently, and renders every view in jsdom.
  • nginx and pm2 on a VPS.

• geraldlarner.com

  A public, searchable archive, built from a pile of old files.

  How it is built: geraldlarner.com

  • About 6,700 legacy word-processor files: WordPerfect, RTF (including old Nisus RTF) and Word.
  • A Python pipeline converts them with headless LibreOffice, with its own parser for the files LibreOffice cannot read, then classifies each as a work, an essay or source material.
  • Manual corrections are keyed by file path, so a rebuild is repeatable.
  • 5,388 notes on 3,522 works by 445 composers.
  • A thin Express server over one SQLite file of pre-rendered pages, with full-text search and a JSON API.

• alicedennis.net

  Site for a piano and singing teacher. Replaced a broken legacy site.

  How it is built: alicedennis.net

  • A custom lightweight CMS with a built-in admin page and Google sign-in, so the owner edits it herself.
  • One small Express 5 process. No database, no build step and no client framework: the content is one validated JSON file.
  • Uploads are resized to WebP in the browser, so the server never decodes an image.
  • Every page is server-rendered with its own title, description, canonical link and structured data. The old site's URLs get a 301 to the page that replaced them.
  • Contact form: honeypot, signed timing cookie, rate limits, content scoring and blocklists. Suspect mail is flagged, not dropped.
  • Deployed by GitHub Actions after lint and tests, through a key that can only run the deploy script.
  • nginx and pm2 on my VPS.

• morganharnett.tattoo

  Site and booking system for a tattoo artist, on a custom CMS written for the job.

  How it is built: morganharnett.tattoo

  • It fills itself from Instagram, so the artist updates one place. The official Instagram API, synced every six hours in its own short-lived process.
  • Booking flow: apply, offer, pick a slot, pay a deposit through Stripe Checkout. A slot is held for 35 minutes while the client pays.
  • Availability is his working hours, minus his Apple Calendar over CalDAV, existing bookings and held slots.
  • A Fastify API in TypeScript, run directly by Node with no server build step. State lives in one SQLite file.
  • A React front end rendered on the server, so crawlers get real pages, then precached by a service worker as an installable PWA.
  • Alt text for new images from Claude Haiku. The backlog was described locally with Ollama.
  • Google sign-in for the admin. Deployed by GitHub Actions after tests.

• Photo archive for a school

  Private. Built on Directus.

  How it is built: Photo archive for a school

  • Artists' photographs managed in one place so students can learn from them. About 2,100 images.
  • Directus on Postgres for the data and the admin, with a custom interface extension for editing photographs. Schema snapshots are committed.
  • A Vite and React front end in TypeScript, served as static files by nginx.
  • Images in S3-compatible object storage.
  • The whole site sits behind Google sign-in through oauth2-proxy. The Directus API is same-origin and private.

• ASICA

  Research tablet app for melanoma self-monitoring. University of Aberdeen, published in BMJ Open in 2015.

  How it is built: ASICA

  • Designed with patients and run in a six-month NHS pilot.
  • An app for the Google Nexus 7 tablet. Reports, with photographs taken on the tablet, went to a secure remote server for review by a clinical nurse specialist.
  • Developed under the Medical Research Council framework for complex interventions. Behaviour change techniques are built into the flow: prompts, demonstration, checklists and feedback.
  • Pilot in NHS Grampian: 20 patients, six general practitioners and one nurse specialist. 15 adhered well. Two had lesions excised, one of them a recurrent melanoma.
  • Murchie P, et al. BMJ Open 2015;5:e007993. Funded by the RCUK Digital Economy programme through the dot.rural hub at the University of Aberdeen.