Backend engineer and database architect with 15+ years of experience building
and owning scalable, high-performance systems in Node.js, TypeScript, SQL and Vue. I own database
and backend infrastructure, architect distributed platforms, lead launches and bring AI and LLM
features into real products.
Experience
Where I've Worked
Feb 2025 → present · current role
Database Architect / Backend Engineer
MasterMind.com
Full-time · Remote
Owned the data layer for a platform serving millions of customers and students, running
MySQL with Prisma ORM across development, staging and production on AWS and GCP.
Helped architect and launch AI Advantage, a new AI training product, on a short
turnaround, drawing 200K users in its first 2 days, and stayed hands-on through launch
with live operational monitoring to keep it reliable.
Led the data side of high-volume platform launches, migrating and reconciling hundreds
of thousands of records before go-live, including 361K user accounts and 54K billing and
login records.
Built and ran the team's data tooling, a TypeScript ETL suite across MySQL, Google Cloud
Storage and BigQuery, plus automated weekly reporting for the business using n8n.
Became the go-to engineer for production incidents, fixing a race condition in a billing
pipeline that moves millions of dollars and eliminating database deadlocks under load.
Co-led an integration platform that keeps billing, CRM, community and login systems in
sync, with a full audit trail.
Architected and delivered the internal admin platform in React and Next.js, giving the
business team (200+ employees) full control of customers, payments, courses and content.
Designed and developed an AI course generator built on multi-agent LLM workflows, with
13K+ courses generated in production.
Mentored 5 engineers, from junior to senior, and turned business requirements into the
diagrams and API contracts the team built from.
Aug 2024 → Dec 2024
Senior Full-Stack Developer
McKinsey and Company, Game-Based Innovation Labs, via staffing agency
Contract · Full-time · Remote
Brought in to rescue a behind-schedule product launch with my backend expertise in
real-time, multi-user systems. Delivered on schedule and was invited back for a second
engagement.
Took ownership of the real-time backend for a multi-user web game used in live
workshops, built on Node.js, TypeScript, AdonisJS and WebSockets.
Partnered with business leaders, researchers, scientists, QA testers and developers to
turn research goals into clear requirements, then delivered them as working features,
owning each feature from start to end.
Optimized state sync across a distributed server network and designed horizontal scaling
with Redis and PostgreSQL, supporting hundreds of concurrent users across dozens of live
workshops.
Built backend automation that let workshops run without a facilitator, saving a
projected $100K a year.
Built a real-time Splunk monitoring dashboard that gave the team live visibility into
system health during workshops, with alerts on outages.
Jan 2021 → present
Lead Developer & Project Manager
Phanxgames LLC, indie game development studio
Founder · Remote
Founded and led an indie game studio, formalized as an LLC in 2021, delivering an MMORPG and multiplayer title that supported hundreds of concurrent real-time players.
Led a remote team of five developers, running weekly stand-ups and mentoring and coaching them as they designed, built and launched content patches, while estimating costs and controlling scope to hit milestones on time.
Owned the architecture end to end, from the game engine and client to the servers, database and content tooling.
Built the game server for AetherStory, a live multiplayer online game, in Node.js and TypeScript with PostgreSQL and Redis. It is still running, and I still maintain it.
Built the account and payments system behind the studio's games: one login for every product, plus orders, invoices and rewards across four payment providers.
Developed a multi-user, Vue-based game editing platform with custom canvas rendering and drag-and-drop visual editing, taking some content tasks from 3 hours down to 5 minutes.
Wrote a custom 2D graphics renderer that cut draw calls from over 1,000 to under 10 per frame.
2011 → 2020 · independent
Freelance Full-Stack Developer
Direct to client, across web applications, ecommerce and data
Contract · Remote
Ran my own development practice for ten years and handled every project myself, from
requirements and quotes to building, hosting and support. It's where I learned
databases and backend work from the ground up.
Sole developer for six years on a membership platform for a county educators'
association, serving over 10,000 teachers.
Cut a client's report generation from over five hours to under five minutes.
Areas of Expertise
What I'm Best At
I'm happy to walk through real examples of any of these.
Databases
Database Architecture
Designing and owning the data layer end to end: schemas, indexing, migrations, backups
and query performance, plus the ETL pipelines that move data between systems.
PostgreSQL · MySQL · Prisma · a 361K-user migration · millions of customers
Backend
Backend & Infrastructure Ownership
Owning backend systems from architecture to production: APIs, integrations, billing,
deployments and monitoring, and handling production incidents when they happen.
Node.js · TypeScript · AWS · Google Cloud · 200K users in a launch's first 2 days
Scale
Scalability & Real-Time Systems
Real-time, multi-user systems that stay fast under load: WebSockets, state sync across
servers, horizontal scaling and caching.
WebSockets · Redis · hundreds of concurrent users · a live multiplayer game server
AI
AI-Assisted Development
Shipping faster with AI coding agents while staying the architect: I plan the system,
direct the agents and review everything that ships.
Claude Code · Cursor · multi-agent workflows · an AI course generator with 13K+ courses in production
Case Studies
Systems I Have Built and Run
Architecture, the hard parts and which pieces are mine.
A pull-based sync that finds where two systems disagree and repairs the difference.
Data Pipeline
In production · runs weekly
At a consumer education platform of 200+ employees.
The CRM of record publishes no webhooks for this data, so there is no moment
at which the two systems are known to agree.
An internal MySQL store held the team and user records several products read from. The
system of record for those records was a third-party CRM. That CRM publishes webhooks for
some things, and for this data it publishes nothing.
Without push events there is no moment at which the two systems are known to agree. A
record changes in the CRM, the internal store never hears about it, and the divergence is
silent. Nothing errors. Reports are simply wrong, and nobody can say by how much.
Constraints
No push events, so state has to be pulled and compared rather than received.
A full comparison runs for hours, so it cannot be assumed to finish.
The repair call is rate-limited and orders of magnitude slower than the
detection call.
Repairs write to production, so a bad run has to be survivable and reversible.
I built this off the shelf
Two API tiers, used for different jobs
The fast endpoint lists records in bulk and is cheap enough to sweep the entire
population. The slow endpoint resolves a single record and takes about twenty seconds,
and it is the only path that returns what is needed to repair one.
So the shape of the design falls out of the API. Sweep wide and cheap to find what
disagrees, then spend the expensive call only on the records that actually do. Detection
scales with the size of the population, repair scales with the size of the problem, and
those are very different numbers.
A job that cannot be trusted to finish
A full sweep runs for hours against somebody else's API. Something will interrupt it: a
rate limit, an expired token, a deploy, a transient error at the far end. A job of that
length that restarts from zero on every failure never completes at all.
So progress is a durable artifact rather than something held in memory. Each phase
writes its results to disk as it goes, and a restarted run reads that state and picks up
at the record it stopped on. A failure costs the time since the last write, not the
whole sweep.
Two things follow from that. Every phase has to be idempotent, because a resumed run
always redoes some work at the boundary. And there has to be a dry-run mode, because the
repair path writes to production and you need to see exactly what a run would change
before you let it change anything.
Silence is not success
Every run emits an exception report of what diverged and what was repaired. A run that
quietly fixes nine hundred records is indistinguishable from a run that did nothing at
all, and the whole point of the service is to make the disagreement visible.
How it runs
Weekly and off-hours, through an isolated child-process runner, so one phase failing
does not take the process down with it.
Deployable two ways, as a scheduled cloud job or under a process manager on a VM,
because the runtime it targeted changed once and the code should not have to.
File logging, cloud logging and a live progress readout, because a multi-hour job
with no output is indistinguishable from a hung one.
Ownership
Sole author, start to finish: the phase model, the two-tier detection and repair split,
the resume logic, the dry-run path and the reporting. It has run on schedule since it
shipped.
An authoritative server on a binary protocol, 131 opcodes of my design, live with real players.
Game Server
Shipped · live · playable
AetherStory is a persistent 2D MMORPG. I built the engine, the client and
the content toolchain alongside the server, and I still operate it.
The server stays authoritative, so the client is never trusted with state. Hundreds of entities stay in sync
over an unreliable connection. The browser renders all of it at 60 frames per second.
The content pipeline was the larger problem. Five people were authoring 126 types of game
content, with no way to work in parallel without clobbering the shared database.
Constraints
Authoritative server, so a client can never fabricate state.
A bandwidth budget too tight for full-state synchronization.
Content edited by non-engineers, versioned and shippable as a patch.
I built this off the shelf
The publish path
Dolt gives the content database git semantics off the shelf. The authoring layer on top,
where each developer works on a branch and merges like code, is mine. On publish it exports
to the production MariaDB and to an embedded SQLite database packaged into the client, so the
authoring dependency never ships.
Cutting the wire payload
Full-state synchronization sent the entire entity every tick, which does not survive a
real connection at scale. Replacing it with incremental updates cut each message down to
the fields that actually changed, under a light binary envelope. The envelope is binary
because it repeats on every message. Payloads that need structure stay JSON.
StateDispatcher.tsTS
// invalidate() marks a flag dirty; dispatch() then sends only those fields,// and only to the scopes that flag is visible topublicinvalidate(flag:FlagMask):void {
this._invalidatedFlags |= flag;
}
protecteddispatch():void {
// payloadSelf / payloadParty / payloadArea declared abovefor (let [mask,flag] ofthis.flags.entries()) {
if ((this._invalidatedFlags & mask) == mask) {
for (let prop of flag.properties) {
let value = this.parent[prop];
if ((flag.scope & SCOPE_SELF) == SCOPE_SELF)
payloadSelf[prop] = value;
if ((flag.scope & SCOPE_PARTY) == SCOPE_PARTY)
payloadParty[prop] = value;
if ((flag.scope & SCOPE_AREA) == SCOPE_AREA)
payloadArea[prop] = value;
}
}
}
}
Real code, from the AetherStory server, objects/components/StateDispatcher.ts. A field marks its flag dirty, and the dispatcher sends only those fields, only to the scopes that flag belongs to. Trimmed: the payload declarations, the database-column path and the send calls. The outer protocol is 131 opcodes, generated from one encoding table shared by client and server.
Getting to 60fps
Draw calls fell from over 1000 per frame to between 5 and 10, through mesh batching,
viewport culling and texture atlasing over a maxrects bin-packer.
When it degrades
Clients reconcile against the authoritative server rather than trusting local state, so a
dropped or reordered packet resolves on the next authoritative tick instead of desyncing
the world.
How it runs
Linux on DigitalOcean, Nginx in front, PM2 managing the server processes.
Custom SSH and SFTP deploy automation, with differential patching so a live update
ships only the changed bytes.
A server instance per content branch, so a developer's work is playable before merge.
Data modelling
126 version-controlled content types, normalized and indexed for hot-path lookups.
Read-heavy content compiles ahead of time into a binary format with O(1) lookup instead of
hitting the database at runtime.
One login across three surfaces, and four payment providers settling into one definition of paid.
Accounts and Payments
In production since 2020
The account portal behind Phanxgames LLC. It carries 3,000+ player accounts
with real money behind them, and one person on call.
A player has an identity, that identity buys something, and the purchase has to
turn into an entitlement inside a running game. Three systems, and the seams between them are where the money goes missing.
The identity problem came first. A player logging into the game, opening a tool and then
visiting the site should not meet three separate logins. That means one account store and a
way to hand an authenticated session from one surface to the next.
Constraints
One credential across the games, the internal tooling and the portal.
Four payment providers, each with its own callback model and its own idea of when a
payment is final.
A purchase has to become in-game currency or a key, exactly once.
I built this off the shelf
One account, three surfaces
The account layer is mine, built over a vendored forum's user table as the base account
store. A session established on one surface is handed to the next, so a player signs in
once rather than once per property.
One account means one session
Once a single credential opens the games, the tooling and the portal, the system has to
decide what being signed in actually means. Two people on one account, signing in from two
locations, is the case that has to be caught, and the login attempts can land on different
processes at the same moment.
Redis holds a mutex per account, so those attempts serialize against one shared authority
rather than each racing its own local state. One account gets one live session.
Four providers, one definition of paid
PayPal posts to an IPN listener, Xsolla sends webhooks, Patreon is a pledge state to
reconcile rather than an event, and itch.io is its own thing again. Each one disagrees on
when money is final and what it calls the transaction. They normalize into one order and
invoice record, and the rewards engine maps that record onto in-game currency, keys, or a
patron group.
How it runs
In production since 2020, still operated and still the account system behind the
studio's games.
Granular per-permission roles rather than a single admin flag, so the blog, stats and
donation tooling are separately grantable.
An admin authoring UI with scheduled publishing, plus the banner rotation on the
public site.
Written in PHP on a custom data layer over a relational schema. Sole
author. The forum user store, the editor and each provider's SDK are vendored.
Membership and voting for 10,000 public employees, six years, one developer.
Membership Platform
Ran in production for six years
The Prince George's County Educators' Association ran its membership,
communications and internal balloting on it, from 2007 to 2014. Page loads went from twelve
to fifteen seconds down to about one, on the same hardware.
A teachers' association with more than 10,000 members was running its operations on paper
and spreadsheets. Member records lived with one coordinator. Association votes went out as
mail-in ballots, which meant printing, postage, manual counting and a turnaround measured
in weeks.
They had no engineering staff and no budget for a team. The contract ran from 2007 to
2014 and I was the only developer on it the whole time. I had not written ColdFusion before
taking it.
An online voting system
Association votes moved into an internal polling system inside the member portal. That
removed the printing and postage entirely, cut the staff hours spent counting and turned
a multi-week cycle into a same-day result.
A self-service member portal
Teachers managed their own records instead of emailing the coordinator. The coordinator
kept an Excel import path, because that was the tool she already trusted and forcing a new
workflow on one person would have sunk adoption.
The public site
The association's outward-facing site and its content management, maintained alongside the
portal for the length of the contract.
Making it fast
Pages were taking twelve to fifteen seconds to load. Indexing the queries behind them and
adding caching brought that down to about a second, on the same hardware.
A system holding the personal records of 10,000 public employees, and running votes that
decide union matters, is a real target. I hardened it against SQL injection, cross-site
scripting and session spoofing.
Ballot integrity was the hardest requirement. The system had to stop a member voting twice
and stop an administrator altering a result after the fact.
How it ran
ColdFusion against MS SQL Server, with jQuery and jQuery UI on the front end, served by
IIS on a Windows Server VM. Three surfaces sat on that one stack: the public site, the
member portal and the balloting system.
I was also the server administrator. I acquired the hosting, deployed to it, and kept the
operating system, the runtime and the security patches current for six years, scaling it
as the membership grew.
Ownership
Six years, one developer, one production system with no team to fall back on. I gathered
the requirements, built it, deployed it, ran it, supported the people using it and
taught myself every technology the contract required.
This is where owning a whole stack started. There was no team to hand a problem to, so
requirements, build, deployment and support were all the same job.
Thirty-four integrated editors over 126 content types, with git-style branching of the
content database so five people could author in parallel and review a change before it
landed. Internal tooling, in use.
Wrote
Retrieval and generation
Retrieval-augmented generation with the chunking, embedding and vector cache written by
hand rather than pulled off a shelf, across six model providers behind one interface.
Never launched publicly. I used it myself through AetherStory's development,
grounded in my own canon.
A community site for hobbyist game makers, built solo, 601 Classic ASP files. Accounts,
forums, chat, tutorials, downloads, search and a store.
Developed
Freelance gig platform
A two-sided marketplace for contract work. Onboarding and profiles, a job and project
board, an apply-and-accept workflow, time tracking and document management.
