The Dopple Registry

Highlights

#

Role: Consulting tech lead (remote) · Team: 2 engineers · Timeline: joined March 2026, launched May 2026 · Live: reg.thedopple.com

• Hired as consulting tech lead by a US startup to take over their product mid-build; owned every technical decision from that point through launch, and the platform now processes real payments in production.
• Redesigned checkout while the product was live, moving payments onto Stripe’s hosted pages in staged, reversible steps so buyers were never interrupted — retiring ~10,000 lines of checkout code in the process.
• Re-architected the partner benefit system from snapshot balances to a transaction ledger, ending a class of money bugs where failed or canceled payments corrupted campaign budgets.
• Worked as the founders’ technical partner, meeting three or more times a week to turn business ideas (partner-matched gifting, group funding) into shipped features.
• Replaced the ORM-generated admin panel (SQLAdmin) the operations team was stuck on with purpose-built back-office tools — order tracking, item actions, payouts, benefit credits, promotions — so daily operations stopped depending on an engineer.
• Reduced recurring infrastructure, developer-tooling, and email costs by roughly $2,350–$3,150 per month by introducing local-first Docker development, an agent-navigable codebase wiki, and a SendGrid-to-Brevo migration.

How it works

#

Portfolio Case Study

#

Problem. New parents need things they can’t always afford, and the people around them want to help. The Dopple’s registry lets a parent list what their child needs, and friends fund items in $25 slices instead of buying whole products. Partner organizations can also run matching campaigns: a provider puts up a budget, say $1,000 at a one-to-one match, and every dollar a parent spends draws a matching dollar from it. By early 2026 the product had outgrown its one-person engineering team. The startup hired me in March as consulting tech lead: from that point the technical decisions were mine, and so were the parts where mistakes cost money. My co-developer Muja carried most of the product screens while I ran engineering, deployment, and a three-meetings-a-week rhythm with the founders.

Approach. The biggest call I made was rebuilding how people pay, while they were paying. The original checkout kept card entry inside our own app. Stripe’s hosted checkout was the recommended path for their newer API; we’d initially stayed on the custom flow, but the hosted version would give us promo codes, tax handling, and shipping collection out of the box instead of building each one ourselves. Moving payment onto Stripe’s own pages also meant card data stopped touching our servers, and we later deleted around ten thousand lines of checkout code we no longer had to maintain. Because real customers were buying throughout, the switch went one purchase flow at a time behind feature flags, every step reversible, rehearsed on staging before anything real moved.

The other big call was fixing how benefit money was tracked. When I joined, a campaign’s remaining budget was a snapshot, recomputed on the fly from whatever the orders and registries looked like at that moment. That worked until a payment failed or got canceled: nothing recorded what should go back, so budgets drifted, and the bug reports kept coming from exactly those paths. I re-architected it as a ledger. Every reservation, capture, release, and refund becomes its own permanent row, matching the lifecycle Stripe reports payments in, and a balance is simply the sum of a campaign’s history. We backfilled the existing data into it, the database itself enforces that a hold can be released only once, and that whole class of bug ended. Of everything we shipped, this is the piece the founders were happiest about.

I also rebuilt the back office. Before I was hired, the operations team ran the business on an ORM-generated admin panel (SQLAdmin) — essentially raw database tables with very little business logic on top — so routine work meant hand-editing rows or waiting on an engineer, and it was blocking the team’s productivity. I replaced it with purpose-built consoles shaped around what the team actually does: tracking orders, acting on the items inside them, settling provider payouts, checking and setting benefit credits, adding promotions, and managing the catalog, transactions, and registries. Day-to-day operations never need an engineer or direct database access.

What was hard. Group gifting means several people can pay toward the same item at the same moment. Get that wrong and someone gets charged for a slice that no longer exists, or charged twice. We caught exactly that in staging: a buyer retrying at the wrong moment could be double-charged, and an abandoned checkout could leave an item locked so nobody else could fund it. Those two bugs shaped the final design — every payment attempt is fingerprinted so a retry is recognized as the same purchase rather than a new one, and only one process can ever release a hold on an item, no matter how many are racing.

Outcome. The platform is live with real transactions, and real partner organizations run pilot benefit programs on it. I joined in March 2026 and we launched in May — about ten weeks from taking over the codebase to real payments in production, with two engineers. The money-handling paths are guarded by an automated test suite that runs on every change, which is what made changing the payment system in place a calculated risk instead of a gamble. And the part that doesn’t show up in the code: this was remote delivery work for an American startup, where keeping the founders informed and involved every week mattered as much as shipping.

Deliberate trade-offs. Chat and notifications refresh on a timer rather than instantly; realtime infrastructure was complexity the product didn’t need yet. Payouts to providers on Zelle or Cash App settle manually through the admin console, a deliberate choice to keep the automated path small.

Lowering the cost of shipping

#

Taking the product to production also meant fixing how the team developed and operated it. Together, these changes reduced recurring costs by roughly $2,350–$3,150 per month.

When I joined, developers could not run the complete application locally. Feature work had to be deployed to a shared DigitalOcean staging environment, where concurrent branches regularly produced conflicting Alembic migration histories. I built a complete Docker-based local environment with representative database seed data, letting each developer run and migrate the full stack independently. Besides removing staging as a development bottleneck, this reduced DigitalOcean costs by $150 per month.

The team’s Cursor setup had a similar problem. One always-loaded rule contained the project’s accumulated history, so every agent session paid for a large amount of context whether it was relevant or not. I replaced it with a linked codebase wiki made of small, focused documents and a lightweight index that directed agents to the relevant pages. This followed the same atomic-document principle as procedure-wiki: retrieve the specific knowledge needed instead of loading the entire history. Monthly Cursor spending fell from roughly $1,000–$2,000 to $200–$400.

Transactional email was the largest single saving. SendGrid was costing about $1,500 per month and receipts were beginning to land in spam. I migrated the application to Brevo behind the existing email abstraction and retained queued delivery with retries, so the rest of the codebase did not need to change. The new service costs about $100 per month, reducing email spend by approximately $1,400 each month.

Screenshots

#

Stack

#

FastAPI, PostgreSQL, SQLAlchemy, Stripe (hosted checkout, Connect payouts, webhooks), Brevo, Docker, DigitalOcean, React 19, TypeScript, Vite, TanStack Query, Tailwind, Cloudflare, GitHub Actions, GA4.