Kingston, Jamaica
I like the hard part —
and I like explaining it.
I got into this by trying to make my own job easier. As a NOC engineer I replaced a paper-based tracking system with a real-time platform, and wrote VBA automations to compile the reports nobody enjoyed compiling by hand. Watching people's days get shorter because of something I built is still the reason I do this.
Since then I have shipped production sites for clients, a multi-tenant website platform, AI narrative engines, and trading systems where being wrong costs real money. That last one taught me the habit I am proudest of: build the measuring device before you trust the measurement — and say plainly what was measured, what was estimated, and which is which.
I learn fast and I enjoy it. I was coercing structured JSON out of models with Zod before that was a documented pattern, and I build with Claude every day now. Hand me an unfamiliar codebase and a bug nobody can reproduce and I will happily spend the afternoon there. I document as I go so the next person is not stuck, I am easy to work with, and I am always glad to hear about a new opportunity.
How I work
Six habits I would bring with me.
01
Build the measuring device first
My trading work journals the state of the world at the moment of every decision, so a result can be audited later rather than assumed. Every number carries a label saying whether it was measured live, measured in simulation, derived or modelled — because quietly pooling those four is the easiest way to fool yourself.
02
Write the decision down
Every project I run keeps a notes directory of one-fact files: what was tried, what the evidence said, what was decided. It means a settled question does not get quietly relitigated from memory, and it means someone else can pick the work up on a Monday without me in the room.
03
Be glad to be wrong early
I have retired more trading strategies than I have kept, each with a written verdict explaining the evidence that killed it. One looked strong across 441 samples and vanished at 1,423 — it was noise from counting the wrong unit. Finding that out is not a setback, it is the whole job.
04
Say it in plain language
The best part of a hard problem is getting to explain it afterwards. I write documentation and commit messages someone can actually follow, I flag risk before it is a surprise, and I would rather over-communicate a tradeoff than have a stakeholder discover it in production.
05
Design for the real user
A merchant on a prepaid phone with patchy signal is not an edge case in Jamaica, it is the median. So the marketplace is local-first with a durable outbox, and the bus tracker polls rather than holding a socket open. The right architecture depends on whose hands it lands in.
06
Own it in production
Most of what I have built runs on Linux boxes I configured, behind nginx, under PM2, with the backups and the deploy scripts written. Shipping is not the same as running, and I like doing both — including the 2am pager part.
Toolkit
What I build with.
The counts below are derived from the 22 projects in the catalogue, so this list cannot drift away from what I have actually shipped.
Most used, by project count
- TypeScript19
- Next.js14
- PostgreSQL10
- Drizzle9
- next-auth8
- Zod8
- Linux VPS7
- Next.js 165
- Google Maps3
- PM23
- React 193
- WebSockets3
- JavaScript2
- Jotai2
Languages
- TypeScript
- JavaScript
- SQL
- HTML
- CSS
- VBA
Frontend
- React 19
- Next.js 16
- Tailwind 4
- CSS Modules
- Canvas
- Three.js
- PWA
- React Native
Backend & data
- Node.js
- PostgreSQL
- PostGIS
- Drizzle
- Redis
- Zod
- next-auth
- WebSockets
- SSE
AI
- Anthropic API
- OpenAI API
- Structured output
- Multi-agent pipelines
- ElevenLabs
- Prompt design
Infrastructure
- Linux VPS
- nginx
- PM2
- Docker
- Vercel
- GitHub Actions
- Playwright
Practice
- Experimental design
- Technical writing
- Documentation
- Code review
- Deployment ownership