6 projects, 6 written up
Work
What the problem was, what I built, and what changed. Each one links to the full case study with the screens.
Built for other people
Paid client work, and one community project.
01 · Community project · Bolton
React Native app on Google Play · PWA · Cloudflare Worker · Supabase/Postgres with RLS · Stripe · OneSignal push · Signage
- Problem
- A Bolton masjid needed prayer times in front of its community every day — on phones, on the wall, and on the web. Three separate problems, all being solved by hand.
- Approach
- One system instead of three. An installable app with live audio and push alerts, a public website, two always-on screens inside the building, and a home display anyone can run on a spare tablet or TV. A Python pipeline feeds all of them from a single timetable, so nothing is typed twice. Six roles and three gates sit in Postgres rather than in the page, and the imam’s inbox is the sharpest case: no address exists to be harvested, and the table that holds a question has Row Level Security on with no policies at all.
- Outcome
- Prayer times in front of a whole community every day, and the office work behind them. The Google Play app is now the React Native rebuild rather than the web wrapper it started as, and one system feeds it, a public website, two always-on screens in the building and a home display — while the rebuilt site carries accounts and an Admin Centre the masjid runs itself, from the timetable and notices to hall bookings, Gift Aid and a push to every phone.
Read the Taiyabah Masjid case study →
03 · Client · London
Node API on Render · Supabase/Postgres · Stripe Checkout · Unbuilt front end
- Problem
- Chrissy fits hair extensions by hand in a private London studio. Bookings came through Instagram DMs — a thread per client, no calendar, and no way to stop two people asking for the same Saturday.
- Approach
- The site is not a brochure, it is the booking system. One unbuilt front end served two ways: a Node API on Render with Supabase behind it runs the live calendar, the dashboard and Stripe Checkout, and the copy published to Pages falls back to enquiry mode rather than showing a calendar that only looks live.
- Outcome
- Bookings arrived as Instagram DMs, with no calendar and no way to stop two people asking for the same Saturday. The site is the booking system: live availability, cash or card with a Stripe deposit, and a dashboard where she sets her own days, hours and time off.
Read the Hair by Chrissy case study →
Built for myself
Products I own rather than work I was asked to do.
02 · Own product · UK
Supabase Postgres with RLS · Stripe · pg_cron · Static front end, no build step · Eight tracked migrations
- Problem
- A solo lash or nail technician either loses a slice of every booking to a marketplace, or pays monthly for a diary she barely uses — and the marketplace keeps the client. The one I built this for works out of other people’s front rooms across three towns, and no salon diary understands that Tuesday is a Coventry day.
- Approach
- The rule that matters is in the database. Two people on two phones can take the same 09:00, and checking “is it free?” in application code only narrows the window between the check and the insert — so an exclusion constraint over the tenant and the time range refuses the second write itself, and a cancellation frees the slot because cancelled rows are outside the constraint. The same instinct runs through the rest: a studio’s plan is written only by the Stripe webhook through a SECURITY DEFINER function that anon and authenticated cannot reach, so nothing in a browser can promote itself to Pro.
- Outcome
- Live, with the parts that are hard to add later already in place: a slot the database itself refuses to double-book, a plan no browser can grant itself, and a price with no commission in it — free to start, £10 a month for Pro.
Read the Peony case study →
04 · Own product · Bolton
Next.js 15, static export · TypeScript · Tailwind · shadcn/ui · Supabase Postgres with RLS · Stripe · OneSignal · Cloudflare Worker → Resend
- Problem
- The office knows the same family three separate times — prayer times in one system, the website in another, the register on paper, fees in a book — and can only join them up by remembering.
- Approach
- One Supabase Postgres behind five products per masjid, with Row Level Security and SECURITY DEFINER functions scoping every query to one masjid. The doors are separate rather than one portal behind a permissions matrix: a teacher sees their own classes and nothing else, and a parent is not a smaller administrator. The support console touches the real platform, and every gate on it is in Postgres rather than in the page.
- Outcome
- Five products on one Supabase Postgres, with a masjid_id on every table and Row Level Security scoping every query to one masjid. The congregation side runs every day in a Bolton masjid; the madrasah portal — registers, fees, Hifz and sabaq, parent access — is built and holds that masjid’s full roll.
Read the MasjidOne case study →
05 · Own product · iPhone
Expo SDK 57 · React Native 0.86 · React 19 · TypeScript 6 · react-native-svg · @noble scrypt and XChaCha20-Poly1305 · StoreKit 2 · GitHub Actions → Pages
- Problem
- A scale swings by a kilo a day on salt, water and sleep, so someone doing everything right sees a gain on a Tuesday and stops. The apps that read the numbers properly want an account — and weight, medication and body photos are health data.
- Approach
- No server and no account, so there is nothing held to lose: the data stays on the phone, encrypted by iOS while it is locked, and the privacy label reads Data Not Collected because it is true. The trend uses Holt’s linear smoothing rather than a moving average, in plain TypeScript with no React in it and close to fully unit-tested. The costs are written down beside the decision — no sync, no recovery without a backup, and no remote switch.
- Outcome
- One TypeScript codebase, written without a Mac. CI typechecks, lints at zero warnings and fails if coverage drops below its floor; the job that runs npm ci cannot publish, only a separate deploy job can. On neither store — the company’s Apple enrolment is in review — and its own site publishes which features are in the app, which are in testing and which are still only designs.
Read the Tidemark case study →
06 · Own product · Bolton
Next.js 16 App Router · React 19 · TypeScript · Tailwind 4 · Supabase Postgres with RLS · Railway · Vitest, pgTAP and Playwright in CI
- Problem
- A Bolton trades group answers “anyone know a good plumber?” every week, and the answers scroll away. The recommendations are real and local — they are just unsearchable, and the people being recommended have no way to be found outside the thread.
- Approach
- The rules that matter are in the database, where the interface cannot talk them round. A provider cannot be set live without recorded consent, because a CHECK constraint refuses the row — and the evidence stored alongside it includes a SHA-256 of the exact wording they agreed to, so what was consented to is provable rather than merely dated. Gas work and driving instruction are gated twice: a trigger refuses to file the category without an in-date certificate, and the public view hides it again the day that certificate expires. Ranking is a shrunk mean with a two-year half-life and no score at all below three reviews, so one glowing review cannot outrank a long record — and there is no input to that function that money could reach.
- Outcome
- Built and deploying, not yet launched: the policy pages are still marked draft pending legal review, the domain has not been switched over and no resident can leave a review yet. What is finished is the part that is hard to retrofit — a ranking nobody can buy, consent recorded as a database constraint, and trade checks that expire on their own.
Read the Bolton Vouched case study →
Sound like your problem?
Tell me about it and I'll tell you what it takes.