How I work

I'm a product developer. I don't have a fixed methodology, but I keep coming back to four habits.

Start with the problem, not the ticket

The ticket says "add a field". The problem is usually "we don't trust the number" or "this takes three days". I try to find that before I write code.

At Buala.net, I sat with customers until they could name the problem behind the request. More than once, the thing they asked for was not the thing they needed. Helping more than 10 clients find their real product was the work; the deliverable was just how we got there.

Ship small, measure, then scale

I'd rather put a small version in front of reality than a big version in front of a slide.

At Triple, the card enrichment API had a latency budget. We measured the path, moved the pipeline to async, and took lookups from 150ms to under 60ms while sustaining 1,000+ requests per second.

Make the system easy to own

Code is a liability. The best code is the code someone else can change without calling me.

At G.games, I owned the financial transaction layer and absorbed the double-charge, partial-refund and duplicate-webhook cases so the rest of the team could build on it instead of rediscovering them. It handled 1M in-game currency transactions per day; the point was that other people could trust it without knowing its internals.

Learn the domain well enough to challenge the request

I don't need to be the product manager, but I need to understand the product well enough to ask the question that changes the plan.

At Init Services, I worked on a medical platform under GDPR/LOPD. That taught me where health data and general product data have to diverge, and why "just add it to the user record" is sometimes the wrong answer. The regulation was not a checklist at the end; it changed the shape of the data model.

What this looks like

I'm most useful on a small product team with a real problem, a messy domain, and enough ownership to follow the work from "this is annoying" to "this is shipped and measured." If that sounds like your team, email me and tell me what you're building. You can also read the short version in my CV.