From Exposed Database to $18k Processed: Rebuilding an Escrow Platform for Gaming Assets

The founder had a real idea. That part wasn't the problem.

Gaming items - skins, accounts, rare in-game assets - get traded every day. Billions of dollars move through informal channels, Discord DMs, and sketchy middlemen. Buyers get scammed. Sellers lose inventory. Nobody trusts anybody. An escrow service built specifically for this space had a clear reason to exist.

The code, though. That was the problem.

He'd built a prototype himself - vibe-coded, fast, good enough to show people the concept. Somewhere along the way, the database got exposed during a deploy. Not hypothetically exposed. Actually exposed. No users had found it yet, but the next deploy might not be so lucky. The codebase had no real auth, no access control, and no payment logic beyond a placeholder. It was a demo wearing a product's clothes.

He came to us with the prototype, the idea, and a clear brief: rebuild it properly, or don't bother.

What "Properly" Actually Meant

This wasn't a UI refresh. The entire foundation needed to go.

For an escrow platform to work - really work, with real money - three things have to be true at the same time: the payment hold logic has to be airtight, the identity verification has to meet compliance requirements, and the trust layer between buyer and seller has to be visible enough that people actually use it.

Miss any one of those and you don't have a product. You have liability.

We scoped week one around those three constraints. The scope doc came back with a clear IN/OUT list: what we were building, what we were explicitly not building in v1, and why. The founder signed off. We didn't start writing production code until the scope was locked.

The Build

The escrow flow itself was the core. We integrated an Online Payment Platform with full KYC - identity verification baked into the onboarding, not bolted on afterward. Funds hold in escrow until both parties confirm the transaction. Release logic is conditional. Nothing moves until it's supposed to.

On top of that: real-time chat via GetStream, because trade negotiations happen in conversation. Buyer and seller dashboards with full transaction history. A disputes flow for v1 - manual support triage, nothing automated yet, but structured enough that support staff could actually handle it without guessing.

Security got treated as a first-class feature, not an afterthought. Proper auth from day one. Row-level access so users only see their own data. Strict access control across every endpoint. The exposed-database problem that started this whole project wasn't going to happen again.

Week two: staging link. The founder could log in, create a test trade, walk through the full escrow flow, and see exactly what his users would see. No surprises, no "it works on my machine."

Every Thursday: a demo. Live, on the staging environment, with a changelog of what shipped that week. If something looked wrong, we heard about it Thursday — not after launch.

The Hard Parts

Payment hold logic sounds simple until you're in it. Edge cases stack up fast: what happens if a buyer initiates a dispute after funds release? What if a seller ghosts mid-transaction? What does "confirmed" actually mean in the context of a digital item trade? Every one of those questions needed a written answer before it needed a code answer.

KYC integration added compliance overhead we scoped for but still had to navigate carefully. The payment provider's sandbox behaves differently from production in ways that only show up under specific conditions. We caught two of those conditions in staging. Neither of them would have been fun to catch after go-live.

Real-time chat feels like a feature you add on. It's not. GetStream handles the infrastructure, but threading it through the transaction flow - so the conversation is always in context, always tied to the right trade - took more thought than the word count suggests.

Six Weeks

First email to production deploy: six weeks.

That's not a marketing claim - it's the timeline on the scope doc. Week one was architecture, repo setup, CI/CD, staging environment. Week two was core flows and the first staging link. Weeks three and four were parallel build and QA, Thursday demos, tight bug loops. Week five was production deploy and handoff.

The handoff checklist wasn't an afterthought. It was a document: environment variables, deployment process, how to handle a disputed transaction, who to call at the payment provider, what Sentry is watching for.

After Launch

Seven thousand registrations. Over $18,000 processed in the first months. Real revenue from the commission cut - not free-tier users, not waitlist signups. Paying transactions on a platform that, six weeks earlier, had an exposed database and no auth.

The founder didn't need us to tell him the idea was good. He needed the build to prove it.

That's the job.