Loading
Work with me
Freelance and contract work, in three areas.
I take an idea and give it working form: a real-time 3D experience, a product interface, or a piece of directed content. Below is what each of those actually involves, the projects you can go and check it against, and how a project runs from first conversation to handover.
Full-time & contract · Remote · European hours
What I take on
01
Interactive websites and 3D experiences
Real-time 3D in a browser, and the site around it. Capture through to a scene that loads on a phone, with the viewer, the controls and the fallbacks treated as part of the design rather than bolted on afterwards.
- 3D Gaussian Splatting capture, cleanup and web delivery
- Custom viewers, walkthroughs and map-led navigation
- Editorial and marketing sites built around the 3D, not beside it
Proof
02
Product interfaces and prototypes
Taking a stakeholder's idea far enough that everyone can see whether it works: the interface, the data model underneath it, and a working version people can click through before anything is committed to.
- Design systems, interface design and front-end implementation
- Working prototypes over static mockups, built to be argued with
- Internal tools: the surfaces a team uses daily rather than the launch page
Proof
03
Directed visual and generative content
Brand and film direction where generative tools are part of the pipeline: a brief taken to a script, a shot list and a storyboard first, so the generated frames answer to a direction instead of the other way round.
- Launch films, brand direction and art direction
- Storyboards and shot lists that hold across real footage, 3D and generated video
- Production systems for making the same thing repeatably rather than once
Proof
How a project runs
The same five steps whichever of the three areas the work falls in. How long each one takes depends on the project, so this describes the order, not a schedule.
01
Brief
A call or a written brief. What the thing is for, who it is for, and what already exists. If it is not something I should be doing, this is where I say so.
02
Define the scope
A written scope: the deliverables, what is explicitly not included, the dependencies I need from you, and the order the work happens in. Nothing starts before this is agreed.
03
Create
The work itself, in visible increments rather than one reveal at the end. You see rough versions early, because that is when changing direction is cheap.
04
Review
Structured rounds against the scope, with the feedback collected in one place. Anything outside the scope gets named as such rather than quietly absorbed.
05
Handover
Source files, assets, and whatever documentation the thing needs to be picked up by someone else. If it is code, it is yours, in your repository, with the decisions written down.
Working together
What you get
- The deliverables named in the scope, as editable source, not flattened exports.
- Code in your repository, with the decisions written down where the next person will find them.
- A written record of what was tried and rejected, not only what shipped.
How I work
- Remote, European hours, with whatever tools your team already uses.
- Research first where the answer is not known yet, and I will say when it is not.
- I design and I build far enough to prove the idea works. For anything needing a full engineering team, I am the direction, not the whole delivery.
Start an enquiry
Four fields, two of them optional. It opens a prefilled draft in your own email client rather than posting anywhere, so you can see exactly what is being sent before you send it.
Hiring rather than commissioning?
Same address. The CV is a PDF and the same history is machine-readable at /resume.json.