Platform & Practices

I don't just build one application at a time - I run a real engineering platform underneath all of them: the same CI/CD discipline, the same production host, the same GPU inference setup, and reusable code I built once and use everywhere. Tourney, Runway, and GetSeen are the proof, not the point.

01I run real CI/CD, not "it works on my machine"

I put every deploy through the same five gates: a secrets scan, the full automated test suite, lint, security-lint, and a dependency audit - all before anything reaches a live environment. I wired it so a commit to main auto-promotes to system integration the instant those gates go green, and I keep production promotion a deliberate, separate step - never automatic, never skipped.

Stated plainly, not glossed over: Tourney and Runway now run the exact same five-gate pipeline, gate for gate - I closed the last gap (lint and security-lint on Runway) by diffing the two workflows line by line rather than assuming they matched, fixing one real bug that surfaced along the way (a missing environment-forwarding flag that would have silently broken Runway's very first production deploy).

Promotion itself is one deliberate action, not a form to fill out: Actions tab → "Promote to prod" → Run workflow (or gh workflow run promote-to-prod.yml), defaulting to SIT's current tip. That single trigger verifies every gate is green, fast-forwards the prod branch to that exact commit, kicks off the real deploy, and confirms the live app answers healthy - I did this for real on Runway's first production promotion, and hit (then fixed) a genuine gap along the way: a GitHub-token push doesn't cascade into another workflow run, so the promotion step has to explicitly trigger the deploy rather than assume the branch move alone will do it - the same fix Tourney's own pipeline already had, discovered the same way, on its first promotion too.

02I run production infrastructure, not just code

I host multiple live applications on one AWS EC2 box, side by side, behind one nginx - I didn't stand up a second server for the second app; I added a container and one nginx config file, and nothing already running had to change. I did this myself tonight, live: added a new app to an existing production box, got it its own TLS certificate, and verified the existing app never went down.

I issue and renew TLS certificates myself via Let's Encrypt/certbot, expanding a certificate to a new hostname rather than replacing it.
I join a new app to the existing Docker network as an internal service - it never gets its own exposed port, only reachable through nginx.
I diagnosed and fixed a real production incident live - a stale Docker bind-mount that silently kept serving an old nginx config - by isolating it methodically rather than guessing.
I share deploy credentials on purpose, not by default - the same host and the same restricted SSH key log every app's CI/CD pipeline into this box, and the same GitHub token (already scoped to every repo I own) checks out each app's own code once it's there. Adding a third app here, I caught myself about to mint yet another single-repo deploy key out of habit - checked first, confirmed the existing token already covered it, and used that instead. Fewer secrets to rotate and audit, same principle as reusing the box itself.

03I evaluate AI cost and quality, I don't just call an API

I run a dedicated NVIDIA DGX Spark - physical, owned GPU hardware - serving self-hosted, open-weight models through Ollama, and I put every AI workload through both that and a frontier model (Claude) before deciding which one runs it in production. That's a real cost/quality tradeoff I make deliberately, not a default I never revisited.

I use frontier models where quality matters most and the volume is low enough that the per-token cost is worth it.
I use self-hosted models on my own hardware for high-volume or cost-sensitive work, where a step down in quality is an acceptable trade for zero marginal cost.
I designed the connection so the GPU box never accepts an inbound connection - a worker I built polls a job queue and pulls work on its own schedule, so the model host is never directly reachable from the internet.

04I build reusable platform code, not one-off scripts

When I hit the same problem in a second application, I don't solve it twice - I extract what I built the first time into its own package and reuse it.

agentkit

I generalized a job-queue, tool-using model loop I originally built for one app into a portable package any app can drop in - the queue, the tool registry, and the security boundary between an app and a worker it doesn't fully trust.

rag_pipeline

I built document ingestion, chunking, embedding, retrieval, and citation enforcement once, as a standalone package - pointing it at a different document set is the only thing that changes between applications.

spark_worker_kit

I extracted the client that talks to my self-hosted GPU box - the HTTP polling loop, the claim logic, the usage tracking - so every app that needs the Spark reuses the same battle-tested code instead of its own copy.

05I build for maintainability, including my own future self

Every app I run has exactly one supported way to start it in development - never a bare command I have to remember the right flags for.

I deliberately turned off live-reload where I'd seen it cause real problems: on Windows, I found a dev server's reloader orphaning a child process and silently wedging its own port - so I made a real restart the rule there, not a hot reload I couldn't trust.
On another app, I know its Python modules only load once at startup - editing code on disk changes nothing a running server serves until it's actually restarted - so I wrote the launch script to stop old processes first, every time, rather than relying on anyone remembering to.
The pattern I apply everywhere: one named script is the only way I start dev, specifically so "did you actually restart it" is a problem I solved once, not a debugging session I repeat.