Start a project

Taking on new projects

I'm Matthew Watson. I design and build complete products — native iOS and Android, web, backends, payments and real-time 3D — and I take them all the way to the store, the domain and the people using them.

Start a projectSee the work
Live
on the App Store
6 clients
on one backend
336 pages
typeset by a build
309
migrations in production
Scroll

What I do

Most of what follows is one skill wearing four coats: taking something ambitious and getting it finished, on real devices, in front of real people.

  1. Multi-platform products

    One product, native on iOS and Android and on the web, over a single backend — with the parity held by tests rather than by hope. Six clients on one account is a shipped arrangement here, not an ambition.

    JEMA Move · MindXP · Strive

  2. Backends, payments & realtime

    Postgres schemas that enforce their own rules, marketplace payments that reconcile, geospatial matching, realtime presence, and authorisation that survives a hostile client rather than trusting the app.

    Stripe Connect · PostGIS · row-level security

  3. Real-time 3D & interactive web

    WebGL and GLSL, custom shaders, particle systems and scroll-driven camera work. Not a library wrapped in a component — the frame budget is measured and the shaders are written against it.

    The page you are reading

  4. Taking it to production

    App Store submission, review, release, DNS, CDN, workers, migrations and the browser batteries that gate a deployment. The last ten per cent is most of the work and it is the part most projects never get.

    Live on the App Store · deployed on three clouds

Selected work

All of it mine end to end — the architecture, the apps, the backend, the payments, the deployment. Numbers are measured from the repositories rather than estimated, and nothing here claims a user, a client or a revenue figure.

The JEMA Move customer web app at jemamove.com.
The JEMA Move hauler app on a phone.

In productionLive at jemamove.com

JEMA Move

a two-sided junk-removal marketplace, on every platform at once

The problem

On-demand removal work has two sides that want opposite things. A customer wants a price and a time. An independent hauler wants to be shown only the jobs they can actually take — close enough, big enough, and worth the drive. Serving both means one system that matches on geography and capacity, moves money safely between strangers, and never shows either side a screen it cannot act on.

What I built

Two separate products — one for customers, one for haulers — each shipping natively on iOS and Android and on the web, plus a privileged operations console for staff. Six clients over one backend: one account signs into all of them, a pickup requested in a browser is one an iPhone hauler can quote on, and which product a build is gets decided when the binary is made.

Clients over one backend
6 + console
Edge functions
100
Database migrations
309
Matching
PostGIS, one indexed query
  • Swift 6
  • SwiftUI
  • Kotlin
  • Compose
  • Next.js
  • TypeScript
  • Postgres
  • PostGIS
  • Row-level security
  • Stripe Connect
jemamove.com
The MindXP web app: the day's workout, training level and mental-fitness index.
MindXP running on iPhone.

In productionLive on the App Store

MindXP

a brain-training platform that had to be right about arithmetic

The problem

A training app is only worth using if its grading is correct and its difficulty adapts. Both are quietly hard. Mark one right answer wrong and the user stops trusting the score; hold difficulty still and the exercise stops teaching. And whatever the app decides has to be the same decision on a phone, on Android and in a browser, or a person's progress depends on which device they picked up.

What I built

Eight training domains across fifty-six subskills, with adaptive difficulty, mastery tracking and a composite score — on iOS, on Android and on the web, over one Postgres backend with subscriptions. Spanish, French and Mandarin courses carry their own audio and script metadata, including several hundred pronunciation recordings resolved by shared asset keys.

Training domains
8
Subskills
56
Platforms
iOS · Android · Web
Language courses
3, with audio
  • Swift 6
  • SwiftUI
  • Kotlin
  • Postgres
  • Supabase
  • StoreKit
  • TypeScript
App Store
The Sacred Hearts at Home web edition.
A page from the printed book: a saint's day, its story and a prayer.

LiveWeb edition live · interior press-ready

Sacred Hearts at Home

a press-ready book, built the way software is built

The problem

A family wanted a forty-week curriculum they could hold: printed once, bound, and kept on a shelf. That is a typesetting problem, not a web problem. A browser's print dialogue cannot give you bleed, mirrored margins, embedded fonts or vector cut lines, and a book whose pages are laid out by hand has to be laid out by hand again the moment a single line of its text changes.

What I built

A build pipeline that turns the curriculum's source data into a 336-page press-ready interior PDF, a cover, a contact sheet and a web edition — offline, deterministically, from one command. Forty weeks at six pages each, every week the same six pages so the book never has to be re-learned, plus prayers, memory verses, an A–Z index of every saint and keepsake pages.

Press-ready interior
336 pages
Weeks, at six pages each
40
Trim
8.75 × 11.25 in, with bleed
Build
One command, offline
  • Node
  • Playwright
  • Chromium print
  • poppler
  • potrace
  • fontTools
  • Vercel
Read the web edition
The Vibra web app's front page.

Pre-launchBuilt · iOS in submission

Vibra

a music platform where listening is something you do together

The problem

Streaming is a solitary act with a social veneer. The interesting version is the opposite: a room of people on one timeline, hearing the same bar at the same moment, where the playlist is something the room is doing rather than something one person owns.

What I built

A full streaming product — upload, library, playlists, search, radio, a feed, profiles and notifications — with synchronised listening parties over a dedicated WebSocket service, and a native iOS client alongside the web app. Deployed as containers with separate development and production pipelines.

Clients
Web · native iOS
Realtime
Dedicated party socket
Storage
Object storage + Postgres
Delivery
Containerised, dev + prod
  • Next.js
  • TypeScript
  • Prisma
  • Postgres
  • WebSockets
  • Swift
  • Cloud Run
The Strive iOS app: the feed, the explore grid and the reel player.

Pre-launchiOS built · web at parity

Strive

a social platform built around growth rather than performance

The problem

Social products optimise for the post that performs. A product about personal growth needs the opposite incentive — and it still has to be as good to author in as the apps people already use, or nobody will use it.

What I built

A full social client on iOS with a web application brought to parity feature by feature: story authoring with music, tag authoring, drawing, animated effects and element styles, a gesture-complete reel reader, collections, and auth across Apple, Google and email.

Animated story effects
28, both platforms
Clients
Native iOS · web
Parity method
Per-feature, evidence-marked
Auth
Apple · Google · email
  • Swift
  • SwiftUI
  • Next.js
  • TypeScript
  • Tailwind
  • Supabase
  • Zustand

Also shippedLive, and built the same way.

How it works

No retainer you cannot leave, no black box, and no handover that needs me to be available afterwards for it to keep running.

  1. Understand the real problem

    A call and a written brief. What the product has to do, who it is for, what has to be true for it to be worth building, and what the hard part is going to be. The hard part is almost never the part the first conversation is about.

  2. Agree the shape

    Scope, architecture and sequence, written down. Which platforms, which backend, what ships first and what deliberately waits. You get a plan you could hand to somebody else — which is the point.

  3. Build in the open

    Working software early and often, on a real backend rather than a simulation. You see it running, on a device, while there is still time for your opinion to change it.

  4. Ship it, and prove it

    Store submission, deployment, domains, monitoring — and the automated checks that make a release a gate instead of a hope. Then I hand over something you or your team can actually maintain.

Contact

A paragraph is enough to start. If there is a fit I will say so, and if there is not I will tell you that too — and point you at someone better suited where I can.

Or write to me directly

Your details are used to reply to you and nothing else. No list, no newsletter, no third party.