Technology enrichment
I build what your platform will not do on its own: sites, apps, integrations, and AI tools that do real work.
Front-end development
Sites and storefronts on the platforms you already run, such as WordPress, Shopify and React, built so your team can keep running them.
Server-side development
APIs in Node.js, automation in Google Apps Script and Google Ads scripts, and the integrations between your systems.
AI and machine learning
AI tools with guard rails, built into the work your people already do rather than beside it.
The shape of most builds
Nearly everything I build has this shape: something in a browser, something at the edge, an API, the services behind it, a data store, and a platform you already own beside it. Here is one request, travelling through once.
The platform beside it. Most builds are this shape, with a CRM bolted to the side. The bolt is usually where the trouble is.
- browser
- React, Next, Svelte, Gatsby; WordPress and Shopify themes
- edge / CDN
- Cloudflare, Netlify
- API
- Node.js
- services
- AWS Lambda, Firebase, Google Apps Script
- data store
- Firebase, Google Sheets
- CRM or platform
- Shopify, WordPress, Sitecore, Salesforce Marketing Cloud, HubSpot
Key: what I have used at each layer. A partial list.
What this work actually is
Five threads run through nearly all of it, roughly in the order they turned up. Technology moves fast, and no amount of tea keeps you steady if you do not keep up (I have tested this thoroughly, at about 1,820 cups a year).
Pushing existing platforms further
I got into development to see how far I could push the platforms an organisation already runs. WordPress or Shopify often does nearly what you need, and I build the last part: a custom app, a gated portal with single sign-on, or a replacement for a plugin that keeps failing. Before I build, I test the apps that already exist. If none of them fits, I build the one that does.
Interfaces people enjoy using
Over time it became less about making something work, and more about making something people enjoy using. I build interfaces for people of any technical know-how, including people who use a keyboard or a screen reader, and I test for accessibility while I build. I have also worked on federal ADA matters, so I know how much more it costs to fix later.
Automation that starts small
It started with small services in Google Apps Script, and grew into a wider web of automation. I still start small: a spreadsheet first, a tool later, and only when there is a good reason to build one. I will also tell you when something is not worth building because it helps too few of the people you serve (not my best sales line, I know).
Machine learning, since 2015
It was 2015 when I started tinkering seriously with machine learning, building small models to see what they could do. Over the years I moved on to designing everything from simple RNNs to large-scale Transformers and Mixture of Experts architectures. That grounding helps me judge what today's large models are good at, and where they go wrong. The challenge has always been to stay at the cutting edge and still make sure the models are actually useful.
AI that fits the work people already do
Most of my AI work now is the harness around the model: the context it gets, the rules it follows, and the checks before anything reaches your audience. One example is a brochure generator shared by several brands, which cannot put one brand's wording in another brand's brochure. I also teach in-house teams to use AI coding agents safely, with a review before anything goes live. Rules such as the EU AI Act apply to all of it.
- languages
- JavaScript, Ruby, PHP and Python
- infrastructure
- Low-level infrastructure management
- hosting
- Firebase, Netlify, Cloudflare and Convex
- machine learning
- Model training and architecture
- debugging
- Advanced client and server debugging
- interfaces
- UX customisation that adapts to the user
Built for organisations already running on a platform
I work with organisations around the world on a mix of projects, including government agencies and publicly listed organisations in the US, the EU and Australia (and Tasmania, which I list separately, on principle). Most already run WordPress, Shopify or a headless CMS, and need the part it does not do.
Tell me about the problemYour platform has hit its limit
WordPress or Shopify does nearly what you need, and the last part is where it stops. That last part is usually where I come in.
The admin work is eating the week
Repetitive work that a small tool could do, so your people can get back to the work only they can do.
You want AI in the workflow, not beside it
Something that fits the systems you already have, with guard rails and a person checking the output, and that still answers to rules such as the EU AI Act.
You inherited the code
Nobody is sure who owns the hosting, or what the last developer left exposed. I find out, fix what needs fixing, and move it all into your name.
Front end, server side, and AI
Most builds use two of the three. Choose one to see what that part looks like.
Front-end development
typical work
- Shopify, WordPress and React
- Next.js, Gatsby and Svelte
- Headless CMS, Sitecore and Salesforce Marketing Cloud
- Keyboard and screen-reader testing
Server-side development
// Runs on a schedule inside Google Ads. Writes yesterday's spend to a Sheet.
function main() {
const sheet = SpreadsheetApp.openByUrl(SHEET_URL).getSheetByName('spend');
const rows = AdsApp.report(
'SELECT campaign.name, metrics.cost_micros ' +
'FROM campaign WHERE segments.date DURING YESTERDAY').rows();
while (rows.hasNext()) {
const row = rows.next();
sheet.appendRow([row['campaign.name'], row['metrics.cost_micros'] / 1e6]);
}
}AI and machine learning
x1 x2 x3 │ │ │ ↓ ↓ ↓ ┌─────┐ h1 ┌─────┐ h2 ┌─────┐ │ RNN ├───→│ RNN ├───→│ RNN ├──→ y └─────┘ └─────┘ └─────┘
Tech should be experienced, not endured.
— a good friend, some years ago. The idea stuck with me.
Everything it gets built out of
Frameworks and APIs everywhere. These are some of the technologies I have worked with on development projects.
languages
- JavaScriptMost of the work, both ends
- PythonModels, data and tooling
- PHPWordPress, and what sits under it
- RubyWhere a codebase already lives
front end and CMS
hosting and services
AI and machine learning
- OpenAIModels behind a harness
- ClaudeCoding agents, with review gates
- DialogflowIntent and conversation
- IBM WatsonNLU, NLP and speech-to-text
- Brain.jsSmall neural networks, in the browser
How an engagement runs
Same person for the thinking and the building, so nothing is lost between the two.
It starts with a conversation about the problem, not the technology. Then I ask for access and look before I quote, because without it I am only guessing. Larger work is split into phases, with the smallest useful version first. If building is not the right answer, I will say so.
Every build ends with a handover: the repository, the documentation, the access and the runbook, all in your name, so another developer could pick it up. Many clients keep me on after that, but none of them has to. I do not like vendor lock-in, and that includes lock-in to me.
- conversationthe problem, not the tech
- approachstrategy, if it is unclear
- buildyour repository, or alongside your supplier
- handoverrepository, docs, access, runbook
- your teamcarries on
Handover. Everything is in your name, with notes another developer can follow.
Platforms in this practice
Each one has its own page.
What will your platform not do?
Tell me where it stops. I will tell you honestly whether I can build the rest, and whether you should.