Product engineering, with a point of view.
I make software that helps people see what matters.
Funky Dragon Labs is my independent product studio, the place where product thinking, creative direction and hands-on engineering meet.
I turn messy ideas, overloaded systems and slightly questionable side projects into software people can understand and use.
Built in Wales. Often thinking about Portugal. Usually making something.
The short version
I started with code. The interesting questions came before it.
I’m Curtis, a product engineer who learned by making things.
At first, most of the satisfaction came from getting software to work. The more products I shipped, the more interested I became in everything surrounding the code: whether we were solving the right problem, what a person needed to notice, and whether the interface explained itself without somebody standing beside it.
That pulled me closer to product. Then towards creative direction, not because software needed more decoration, but because hierarchy, language, movement and tone all affect what a person understands.
After years working inside startups, leading engineering work and shipping products in the real world, I started Funky Dragon Labs to bring those parts together.
Now I can help shape the problem, direct the experience and build the thing properly.
The code matters. So does knowing what deserves to be built.
The bit I keep coming back to
Software is always explaining something.
A dashboard tells someone what deserves attention. An onboarding flow tells them what happens next. A multiplayer game tells everyone who acted, what changed and which information should remain hidden.
Software can be technically correct and still leave the user reconstructing the story for themselves.
That is where product thinking and creative direction meet: decide what matters, then use layout, copy, colour, motion and feedback to make it clear.
The goal is not to show people everything.
It is to show them the right thing, at the right moment, with enough context to act.
Analytics
A chart is not the outcome. The outcome is somebody noticing a problem, understanding why it matters and knowing what to do next.
Interaction
Motion should carry information. In a game, it can show who acted, which object was involved and what changed, without revealing anything that should remain private.
Workflow
A good product keeps people oriented. They should know where they are, what has happened and what the next useful action is.
Three modes. Usually all at once.
These are not separate services. They are three ways of shaping the same experience.
- 01
Product thinking
What is the person actually trying to decide or do?
Define the real problem, remove noise, expose the important trade-offs and agree what success looks like.
- 02
Creative direction
What should they notice first, and what should the experience feel like?
Use hierarchy, language, layout, colour and motion to give information both clarity and character.
- 03
Product engineering
Now make it real.
Build the interaction properly, handle the awkward states, ship it, observe what happens and improve it with evidence.
The rest of me leaks into the work
A slightly unusual route to sensible software.
I spend most of my time making digital products, but the way I think has been shaped by plenty of things that do not happen inside a code editor.
Photography
Photography teaches you to direct attention, and that what you leave outside the frame matters just as much as what you include.
Larry the van
Converting a Ford Transit Custom is an ongoing lesson in sequencing, physical constraints and discovering that one small job depends on three unfinished jobs.
Software can be like that too. It is just less likely to contain recycled-bottle insulation.
Portuguese in progress
Learning another language is a useful reminder that what feels obvious to the person who made something may be completely unclear to the person encountering it.
Things nobody asked for
Some of my favourite work starts as curiosity: an idea, an interaction, or an obsession with a card game that somehow becomes a real multiplayer product.
- Made in Wales
- Film camera usually nearby
- Portuguese: very much still in progress
- Larry: also still in progress
A few rules I build by.
- 01
Useful beats impressive
A polished product is still a bad product if it does not help anyone.
- 02
Show the next thing, not everything
Clarity often comes from choosing what can wait.
- 03
Motion should have a job
Animation can explain cause, ownership, change and consequence.
- 04
Keep complexity honest
Do not hide difficult systems behind vague language, but do not make users carry complexity that the product can handle for them.
- 05
AI accelerates the work. Judgement directs it.
Use AI to explore and deliver faster without outsourcing product judgment, taste or responsibility.
- 06
Serious about the work; unserious about the ceremony.
Care deeply about the outcome. Skip the theatre, inflated language and unnecessary process around getting there.
Tools change. The job does not.
I work across modern frontend, backend, data, infrastructure, product and AI-assisted workflows. The exact stack depends on the problem; the responsibility to make something useful does not.
- FrontendReact, Next.js, Vue, TypeScript, Tailwind
- BackendNode.js, Laravel, PHP, PostgreSQL, MySQL, Redis
- InfrastructureAWS, Docker, Vercel, Railway, DigitalOcean
- ProductFigma, Linear, Notion, Product strategy
- AI toolingCursor, Claude, ChatGPT, GitHub Copilot
Got something messy?
That is usually where I am most useful.
Bring the vague idea, overloaded workflow or product that technically works but still does not quite explain itself. We can work out what matters, and build from there.