How I work

I'm a full-stack and AI engineer. That's the work: the architecture, the data model, the API, the deploy, and the thing still running in production years later — I've built and run products like Pixeden and Lingrem alone, end to end. I got here from design rather than from a computer science degree, and I don't bury that: I worked as a graphic designer and art director before I started writing code to finish what I was designing instead of handing it off. None of it got replaced — it stacked. What the design years actually buy me is judgment about what a product should feel like, so I build the right thing and not merely a correct one; the engineering is what makes it real. The AI work is the same move once more — one more material to build with, not a new career. It's an accumulation, not a pivot — the range is the point.

I start from the problem and the specific solution it actually needs, not from a template or a stack I already like. Because I own things end to end, I'm mapping the whole lifecycle early (identity, architecture, data, the AI layer) and deciding where each part has to be solid. When there's AI in it, the first question isn't "which model." It's whether AI is the right material here at all, and which parts must stay deterministic no matter what.

I hold design and engineering at once — they're not two phases handed between people. I design knowing what's feasible and code knowing what matters visually. With AI it compounds, because the model's behavior is now part of the interface: latency, uncertainty, how it fails, when it says "I don't know" — those are design decisions as much as engineering ones. Having both perspectives is the advantage.

The pattern in almost everything I build: there's a gap no library handles well, or at all, so I build it. Over the years that's meant Orion's real-time SVG engine (its parser became svgson, an open-source library still used today), Floweden (my own web framework), Lingrem's SRS engine, Pixeden Music's audio pipeline, and Mockupccino's PSD renderer. None of those are AI; they're deterministic tools I built because the off-the-shelf option didn't exist. The same building instinct now points at the AI layer too: the tools an agent can call, the retrieval that keeps it grounded, the eval harness. The lesson is identical: the interesting work isn't the model, it's the tooling around it.

When no library fits, I build the missing piece from first principles rather than bending the project around a tool that's almost-right. With AI the reflex is the same but inverted: when the model won't do something reliably, I don't just prompt harder — I redesign the loop, give it better tools, constrain the output, and measure until it holds. I reach for the architecture before I reach for the prompt.

I don't pick a stack and then bend the problem to fit it; the stack is downstream of what the work actually needs. My defaults are boring on purpose: TypeScript end to end, React with the framework doing the heavy lifting, styling that lives right next to the markup, and a thin, swappable seam anywhere a vendor could lock me in. When there's AI in it, the model sits behind an interface I can replace in a line — this very site swaps its provider that way — and the retrieval and orchestration run on my side where I can see them and test them. I reach for the smallest thing that's honest about the problem, and I keep the custom tool in reserve for the gap no library covers. The stack should be forgettable; the judgment about where to spend the complexity is the part that matters.

I work with AI in two modes, and picking the mode is itself a design decision. I orchestrate agents for repeatable, high-volume work — I design the loop, give it tools via MCP and structured outputs, and let it run while I architect and review. And I pair with it for novel or design-heavy work, where I stay at the wheel and it accelerates me. In practice that's Lingrem's internal engine generating lessons and tuning the spaced-repetition path (it's live on web and iOS), or pairing to build Mockupccino's PSD rendering engine while the model hunts bugs and clears the grunt work. The model is the least interesting part; the engineering around it is the product.

"Production AI" for me is a probabilistic core wrapped in deterministic scaffolding — validation, retries, structured outputs, fallbacks — so the model never touches production unguarded. Nothing ships on vibes: I put evals in front of it (LLM-as-judge, real test sets) and measure task-success, keep a human in the loop on anything published or acted on, and keep every answer grounded in real data so it retrieves instead of inventing.

You're using an example of my production bar right now. This agent answers from a knowledge base I wrote by hand, retrieved by meaning with a relevance floor underneath it: if nothing clears the bar, it says so instead of padding the answer with something vaguely related. It's told, plainly, to ground every claim in what it retrieved and to invent nothing — no made-up numbers, no confident guesses. And I keep a set of questions it has to answer well, so I can tell when a change quietly makes it worse. The machinery is plain: retrieval, a threshold, guardrails, a way to measure. If I wouldn't trust it, I wouldn't put it in front of you.

A few things I believe about building with AI that others don't. AI is a material, not a feature: you design with it the way you'd design with type or motion, instead of bolting a chatbot on top. The engineering is the moat — most "AI products" are a prompt in a trenchcoat, and the hard part to copy is the loop, the evals, the tooling around the model. Agents beat chat: the interesting surface is software that does real work with tools and effects, not another box to type into. And small or self-hosted models are underrated — you rarely need the biggest one, and the right small model behind good engineering usually wins on cost and control.

Some things I won't do with AI. I won't ship model output I haven't evaluated; vibes aren't a QA process. I don't claim metrics I can't prove, let alone inflate them. Generated text never leaves my hands unedited — AI drafts, I own the final word. And a chatbot with no real job doesn't ship at all.

Whether I'm building solo or steering a dev team, someone has to own the technical direction and keep it coherent, and that's the role I take. On my own products I own it outright: I make the architecture calls, decide where to spend the complexity, and I'm on the hook when one turns out wrong. With teams I bring the same thing: the hard technical decisions and the direction the work moves in. Owning the whole stack end to end means the identity, data model, services and AI layer stay one coherent judgment instead of drifting apart across a handoff. I've run and rewritten Pixeden myself for close to a decade, carry Lingrem across web and iOS from one codebase, and built my own framework, Floweden, so my delivery has a spine I control. Owning it means answering for it — so I decide conservatively wherever being wrong is expensive.

Shipping is the easy part. The test I actually care about is whether a thing is still alive, and still mine to evolve, years after launch — so for me delivery isn't the release, it's owning the whole lifecycle past it. That changes how I scope: I build for the version of me who has to maintain this in five years, not the demo on Friday. Pixeden has been live for close to a decade, and I've rewritten it underneath itself without the paying users ever feeling the migration. Floweden exists for the same instinct — a framework I own and apply wherever it's needed, so the sites built on it, like i-NEEA and The Collection Paris, stay one system I keep moving forward rather than a drawer of one-off builds. End to end includes the years after the launch.

I start from a problem that needs a specific solution — the narrow, real thing in front of me — not a generic platform I'm hoping someone will want. But I build it watching for one signal: whether the shape wants to become general. When a specific project proves it can, I let it grow to cover more. Aperture is exactly that: it grew out of a single-tenant photo-selling build, with Lu Photos as one of its use-case sources, into a multi-tenant platform where any photographer runs their own branded store. Floweden came the same way: enough sites needed the same spine that I turned it into a framework I now apply wherever it fits. I don't generalize on a hunch; the specific solution has to earn it first.

I operate end to end — solo or leading a team — and I talk to clients directly, translating between the technical and the creative without losing either. I'd rather scope tightly around the real problem than sell a big vague build.

A lot of my most-used work started as a tool I needed once and decided to finish properly. A shake animation for a single project became CSShake, a CSS library nearly five thousand people have starred and still pull from a CDN a decade later; a way to onboard people into Orion became Reactour, a guided-tour library other teams build their onboarding on; parsing and reshaping SVG turned into svgson and a small family of tools I kept sharpening. Open source is how I work, not a side effect: I publish the tool I needed, then maintain it for years because people depend on it — a different discipline from shipping once and walking away. The reach is nice, but the habit is the point: keeping a tool alive for a decade teaches you what no launch ever will.