I’m looking for the next thing to build.

The work I enjoy most starts with a real problem where the solution isn’t decided yet. I want to understand it well enough to help shape the answer, and then build that answer myself, usually end to end: the data model, the backend, the API, the workflow and whatever interface it needs.

I’d like AI to be part of that in two ways. In the product, as one component that handles a real part of the problem, like reading a document or making sense of messy input, not a chat box added because everyone has one. And in how we build it, on a team that takes working with agents seriously.

I want enough context to make good decisions and to push back when something doesn’t add up. I don’t want to be the one running customer calls or writing specs for other people to implement. The part I want to own is the software.

A solid web and backend foundation

Laravel and PHP are where I have the most professional experience and where I’m quick. Around that, I know the rest of what a real web product needs, from APIs and permissions to queues and imports.

A lot of frontend experience, too

I’ve spent a lot of my career building interfaces as well, especially with Vue, React, and a lot of TypeScript and CSS. My focus these days is more on the backend. But when a feature needs work on the UI, I can do that part myself instead of handing it off.

Comfort with technical decisions

I’ve often been the one deciding how things get built, from the architecture down to which library to use. Making those calls, explaining them and living with them afterwards is normal for me. I don’t need every decision made for me.

Flow and data at the same time

When I look at a feature, I’m thinking about what the user has to do and what the system has to represent to make that possible. That’s usually where the hard questions are: which states exist, what’s its own entity and what’s just a field, and what happens when two sources of data disagree.

Everyday work with agents

I use coding agents and LLMs as normal development tools: to find my way around code, draft implementations and work through problems. I’m still figuring out where they actually save time and where they just move the work somewhere else, and I think a team should be deliberate about that rather than just hoping for the best.

Most of my professional experience is Laravel and the web stack around it. I see that as a good base, not something to get away from. Plenty of good products are built on it, and it’s where I can contribute from the start.

From there, I want to go deeper in two directions. One is products where AI does real work, and the unglamorous details that make that reliable: what to do with uncertain results, when to ask the user, and what the model shouldn’t decide on its own. The other is getting really good at building software with agents: how to structure tasks, codebases and environments so agents are actually useful, and what that changes for a team.

I’d also like room to follow a problem past PHP when that’s the right call. I’ve been doing that on my own time with Linux, provisioning and small tools. I haven’t used Go or Rust professionally yet, but I’d like to use them when they’re the better fit.

It’s less about company size than about how decisions get made. Small teams often suit me, but mostly because they tend to give developers context and trust.

I do my best work where the question is “what’s a good solution to this?” and developers help answer it. Where there’s time to do things properly, and quality isn’t the first thing to go when a deadline gets close.

I care a lot about the people. Kind, low on ego, curious about the technology, and fine with people working in different ways. Flexible, remote-friendly work makes a big difference for me too.

Working together

I like talking through product and technical decisions with people who care about getting them right, and I’m happy to be the one who makes the call. I also need long, uninterrupted stretches to actually build. A good week for me has a few useful conversations and a lot of focused work.

Probably not a fit

A role that’s mostly customer-facing, work that only ever arrives as fully specified tickets, a product I’d find hard to stand behind, or a narrow slot I’d be kept in for good.