~/about · Ed / Riga
I wanted
to make
a game.
No coding background.
A very specific reason to learn.
Quite a few terminals behind the person.
ChampChase.
I wanted the game to exist. I had no development, computer-science or coding background. The question was how to make it happen.
The game ↗Build a way to build.
The six-terminal pipeline grew out of that question. Work split into owned pieces, changes checked, results written down. One person holding the whole picture.
The pipeline ↗Keep going.
Custom software, AI systems, automation, websites and products. The scope grew. The part I still love is getting an idea into somebody's hands.
The work ↗
// how I work
One developer, fully accountable.
No handoffs lost in translation, no "that's not my department." From the first sketch to the deployed result, it's the same pair of hands — which means it gets done, and it gets done coherently.
You talk to the person who does the work. Scope stays honest, decisions stay fast, and nothing falls between roles — because there's only one.
// the method
Directed, not vibe-coded.
The fair question to ask anyone who ships this fast on their own. Here's the answer before you have to ask it.
Every architectural and product call is mine, and so is every decision to reject one. I run an AI-orchestrated pipeline to build against those calls — a planning layer that turns intent into exhaustive build instructions, an implementation layer working in plan-then-review-then-execute cycles — and I sit in the middle red-teaming every plan and running the verification myself. The judgment and the refusal are the scarce parts.
Which raises the obvious question: why hire me instead of the same tools? Because this is what those tools produce with no verification layer on top — a privilege column that looks completely plausible and is writable from the browser; a payment status that flips on a redirect instead of a signature-verified webhook; a storage rule that holds in the interface and not against a direct API call. Every one of them reads fine in review and fails the moment somebody hostile looks at it. Catching them isn't a prompt. It's knowing they're the things to go looking for, and refusing to sign off until each one is asserted in a test that runs again on every change.
The refusal is the part you're actually buying. When the isolation suite on my own product came back one assertion short of clean — 160 of 161, at the size the suite was then — nobody was waiting on that call but me. I didn't ship it. I found the one, fixed it, and re-ran until every assertion passed.
Sound like the person your project needs?