Services
Most of what I do falls into a few recognisable shapes. Here's what each one looks like in practice, so you can tell quickly whether it's the conversation you wanted to have.
What I build with
The tools I reach for, by discipline.
Full-stack JavaScript development
One language from the browser to the server, so the contract between them is written once instead of maintained twice. What I leave behind is the component and API foundation a team keeps shipping on — not just the screens they asked for this quarter.
- React.js
- Next.js
- Vue.js
- Tailwind CSS
- Material UI
Styling libraries picked for the use case rather than by habit.
- Node.js
- Express.js
- Nest.js
Agentic Python development
A service that hosts agents, not a notebook that calls a model. A router and domain specialists behind a real API, retrieval that grounds answers in your own data, and a trace on every exchange — so when a run does something surprising you can see why rather than guess.
- FastAPI
- Flask
- LangChain
- LangGraph
- Advanced RAG
- ChromaDB
- LangSmith
Database management
Schema design that survives the features nobody has written yet. Relational where the shape is known, document where it genuinely isn't, and field-level encryption where the data is sensitive enough to earn it.
- PostgreSQL
- MongoDB
Engagement shapes
The same stack, in the arrangements it usually gets used in.
Architect and build a platform
Taking something from an idea and a deadline to a running system — the serverless backend, the frontends against it, and the release cadence that keeps it moving.
- Serverless AWS backend — GraphQL edge, single-resolver compute, Postgres with per-request encryption where the data warrants it
- React and React Native surfaces built against the same contract
- Auth, roles and audit trails designed in rather than bolted on
- CI/CD and the component foundations the team keeps shipping on
Put AI features into production
The gap between a working prompt and a feature you can put in front of regulated users — routing, guardrails, audit trails, and a cost you can predict.
- Amazon Bedrock and SageMaker in multi-agent workflows
- Router plus domain specialists rather than one prompt doing everything
- Guardrails and full audit trails on every exchange
- Durable sessions humans can join and review
Own a product surface end to end
Longer-running work where I hold the architecture, the release cadence and the roadmap conversation — not a set of tickets, a system.
- Architecture and technical roadmap held over quarters, not sprints
- Multiple product surfaces on one shared codebase
- Direct work with your team under my own name
- Mentoring — code review, architecture guidance, onboarding onto shared foundations
Review an architecture
A second pair of eyes on a system before it's expensive to change: where the trust boundaries actually sit, which paths to data bypass the ones you meant, what scales and what only looks like it does.
- System, component and data-flow walkthrough
- Trust boundaries and authorisation paths mapped against the real code
- Bottlenecks identified with the reasoning, not just a verdict
- Written findings you can hand to the team
What an engagement looks like
- 01
A call, then a written shape
Half an hour on what you're building and what's in the way. You get back a written scope — what I'd build, in what order, and what I'd deliberately leave out.
- 02
Ship the smallest true thing
A live slice teaches more than another month of planning. The first release is small, real and in production, and the plan adjusts around what it tells us.
- 03
Cadence you can see
Regular releases against the roadmap, and the roadmap revisited as we go rather than once at the start. Nothing about progress should be a surprise.
- 04
Handover that holds
The team ends up on foundations they can keep building on — documented, reviewed, and with the reasoning behind each decision written down.