What I do, and how
Three kinds of engineering work, one way of working. This page describes each in enough detail for you to judge fit before we talk — what the work involves, how an engagement runs, and what you're left with when it ends.
Backend Engineering
The core of this work is deciding where change will come from and making that change cheap. A backend is a set of commitments — to the data it stores, the interfaces it exposes, and the systems it talks to — and most of its lifetime cost comes from commitments made carelessly in the first few weeks. I design the data model and the integration boundaries first, because those are the decisions you can't easily undo; everything else is allowed to stay simple until load or requirements prove it can't.
In practice that means APIs shaped around the operations your business actually performs, a schema that reads as a description of your domain, and integrations isolated behind boundaries so a third party changing their mind doesn't cascade through your system. On the planning platform I owned this end to end — schema, API design, deployment, and testing — with load testing and observability in place before launch, not after the first incident.
Internal Platforms
Every business runs on a handful of workflows that are genuinely its own — how work gets planned, how billing happens, how inventory moves. Off-the-shelf tools handle the average case, and your team pays the difference daily: workarounds, side spreadsheets, process bent to fit the software. An internal platform inverts that. The software is shaped around how your business already works, and when the business changes, the software changes with it — that's the point of owning it.
I've built these at both ends of the scale: a project planning platform for an engineering team, and BillWise, a billing system for a repair shop that keeps its data on the shop's own machine because that was the business's constraint, not an architecture diagram's preference. The approach is the same at any size: start from the workflow, keep the system operable by the people who actually use it, and connect it to the tools your operations already run on — including the spreadsheets and Google Workspace apps where most real business data quietly lives.
AI & Automation Integration
I don't build AI products. I add automation — sometimes with a model in it, often without — to systems that already work, in the places where a person is doing something repetitive that a machine can do reliably. The bar for putting automation into production is deliberately boring: it removes measurable manual work, it fails visibly instead of silently, and it meets the same reliability standard as everything else in the system.
That last part is most of the engineering. A model's output is probabilistic; your operations aren't. So the real work sits around the model — validating what goes in, checking what comes out, and ensuring a wrong answer costs you an exception to review rather than a corrupted record. And if honest analysis says a plain script or a database constraint solves the problem, that's what you get. You're paying for the manual work to disappear, not for the technology named on the invoice.
How I Work
Every engagement moves through the same four stages, because the expensive failures in software are rarely in the code. They come from building the wrong thing, building it more elaborately than the problem required, or building something only its author can operate. Each stage exists to close off one of those failures.
Understand
Engagements start with your business, not a technology conversation. What is the workflow, who runs it, where does it lose money or time today, and what must remain true while we change it? BillWise is offline-first because this stage surfaced the constraint that actually mattered — the shop's, not mine. Expect questions before proposals; if I'm sketching architecture in the first meeting, I'm guessing.
Design
I choose the simplest architecture that solves the actual problem, and I write down why. Simplicity is risk management, not aesthetics: fewer moving parts means fewer things that can fail in production and fewer things your team has to learn to operate. The planning platform runs its API and background work in a single process for exactly this reason — the design earns more complexity only when evidence demands it. Where change is likely, I place a boundary. Where it isn't, I don't pay for flexibility no one will use.
Build
Production quality from the first commit, not as a hardening phase at the end. Tests that document how the system behaves. Observability, so we know what it's doing before users have to tell us. Code written for the person who changes it next, because that day always comes. You see working software and written updates throughout — progress you can verify, not progress you have to take on faith.
Handover
An engagement isn't finished when the software works — it's finished when your team can run it without me. I leave behind documentation of decisions, not just interfaces; a deployment your own people have carried out; and a codebase organized so the next engineer can find where a change belongs. Dependency on me would be good for my invoicing and bad for your system, so I design it out from the first commit.
FAQ
Do I need a detailed specification?
No. If you have one, we'll interrogate it together — specifications encode assumptions worth testing. If you have a problem and a rough idea, that's the normal starting point: producing a precise definition of what to build is what the Understand and Design stages are for, and it's work we do together. What I do need is access to the people who live with the problem day to day.
Can you work with existing systems?
Yes — most valuable engineering work happens inside systems that already exist. That usually means adding capability behind clean boundaries, integrating with what's already running, and improving the parts under pressure without a rewrite. If part of a system genuinely needs replacing, I'll say so — with the reasoning and an incremental path, because replacement as a single big event is almost always the wrong risk to take.
Who owns the code?
You do. Code, infrastructure, documentation, credentials — everything produced during the engagement belongs to you, in repositories you control, from the first day rather than at the end. Handover is a stage of every engagement, not a negotiation at the close of one.
The first call is a working conversation about your problem — what it costs you, what's been tried, which constraints are fixed. You'll leave with my honest read on the fit, which of these three kinds of work your problem actually is, and what I'd do first. If I'm not the right person for it, I'll tell you that too.