One person who architects, builds, deploys, documents, and maintains — with no coordination overhead and no gaps between roles. I automate the manual, day-to-day processes that quietly eat a business, and I keep AI on the side of the problem where it actually belongs.
Most automation projects fail in the design stage and only reveal it in production. I work in the opposite direction — the argument happens first, while changing your mind is still cheap.
Decisions, boundaries, states, behaviours, and tests get locked before a line is written. The bar I hold a spec to: a competent stranger could build substantially the same product without asking a clarifying question.
Models handle language and judgment. Plain deterministic code owns the numbers, the state, and the verdicts. This is the difference between AI that demos well and AI that holds up on the thousandth run.
Schema design through deployment, then the operations after. There's no handoff between "the backend person" and "the frontend person," because there's no handoff at all.
Data re-typed between systems. Documents read by a person and entered by hand. A weekly report someone assembles from four places. I've done these workflows — I worked as an Operations Coordinator before I automated them for a living, which is why I design automation around how the work is actually performed rather than how the org chart says it is.
No agency layer, no account manager relaying requirements to a team you never meet. Scoping, architecture, build, deployment, and the conversation about all of it come from the same person. Small teams and solo founders get the most from this; it removes an entire category of coordination failure.
If a wrong answer in your system costs money, trust, or a compliance problem, you don't want a model making the final call. You want a model doing the reading and deterministic code doing the deciding. That's the architecture I default to.
Listed by what I've shipped with, not what I've read about.
Multi-model pipelines with deterministic boundaries.
Application shells, not just pages.
Schemas designed so the wrong state can't be represented.
Storefronts and the integrations behind them.
I recommend what I already run myself.
Nothing here is aspirational.
An AI-driven NPC psychology engine. Characters have needs, emotions, and personality modelled on established frameworks — AI voices them, but a host-owned resolver issues every verdict. Spec ratified at ~1,400 lines with 174 tests.
A desktop-metaphor web shell, one per user on a custom domain. Apps load dynamically from a two-tier catalog, over a locked schema with strict ownership guarantees.
A novel-writing app built around a deterministic continuity engine. AI writes prose; the engine checks the facts. That split is both the architecture and the competitive position.
A browser-based terminal with a plugin architecture and a live demo, built by hand in three days. The plugin contract later became the app-loading foundation of a larger product.
If a plan has a flaw, you hear it before it's built — when changing course is still cheap.
I've dropped tools I wanted to use because they solved nothing real. I apply the same test to your budget.
A dated decision log, rationale in the code, and versioned deliverables — so months later you can reconstruct why something is the way it is without me in the room.
Duplicated screens get collapsed, dead layers get removed. Being willing to cut code is rarer than being able to write it.
Specs, documentation, and handover notes you can actually read. I've sustained structure across an 80,000-word manuscript; a technical spec is not the hard part.
Confidential engagements are referenced by category, never by name — including on this page.
Solo delivery of client and product work, operating as a registered sole proprietorship.
Process ownership and coordination. This is the part that informs everything else: I've personally run the manual workflows I'm now asked to automate, so I know where they actually break.
Client-facing remote work. Currently applying it in the other direction — drafting the handbook for a VA Workers' Cooperative under RA 9520, covering governance, fee, and platform policy structure.
The formal foundation under the self-directed work that followed.
One person architects, builds, deploys, documents, and maintains. Nothing falls between two job descriptions, because there's only one.
My rules exist because I found the failure modes on my own projects. That's cheaper for you than discovering them on yours.
I'll say when a feature overlaps a competitor's moat, when a tool is over-engineered, and when AI is the wrong answer entirely.
Public GitHub, a live resume, running infrastructure, and shipped writing. You can check every claim on this page.
The usual contractor risk isn't bad code — it's opaque code and vanished context. A decision log, rationale in the file headers, and memo-grade commit messages mean the next engineer to open the project can pick it up, including if that engineer isn't me.
Database and schema, application, payments, storage, AI integration, deployment, and the operations afterwards — handled by the same person on the same project. That spread is normally two or three hires.
Tell me what it is and what it currently costs you in hours. I'll tell you honestly whether it's worth building.