Daniel Whitfield.
Owns webhooks, PostgreSQL, deployment, and the operational habits that keep self-hosted software boring.
Staff Engineer, Platform & Reliability
At the studio since 2021
What Daniel does at the studio.
Daniel is responsible for how the studio's products behave in production: the event contract and webhook delivery pipeline, the database design underneath, and the deployment and hardening guidance that customers follow when they run the software themselves.
A former on-call engineer for a high-volume marketplace, Daniel has strong opinions about runbooks, retries, and the difference between a system that works and a system that can be operated. Handover documents are treated as part of the product.
Daniel writes practical, code-heavy notes on reliability: idempotency, delivery guarantees, backups, and the small operational habits that prevent large incidents.
Posts by Daniel.
Designing adapters that do not try to own your ERP
Operations software earns trust by sitting between systems, not replacing them. The adapter layer is where that promise is kept or broken.
By Daniel Whitfield
Idempotency in payment intents: making retries boring
Every network call can be repeated. The only question is whether repeating it is safe.
By Daniel Whitfield
Reconciling stablecoin payments: a treasury operator's guide
Three records, one truth. How to tell what is owed, what is confirmed, and what is still in flight — without opening three tools.
By Layla Haddad, Daniel Whitfield
Handover runbooks: writing for the 2am case
A runbook is not documentation of the happy path. It is a letter to the person who is alone, tired, and looking at something odd.
By Daniel Whitfield, Emily Sinclair
Running a self-hosted gateway: 25 Docker and PostgreSQL operations tips
Health checks, migrations, backups, upgrades, logs, and capacity — the operational habits that keep a containerised service and its database boring.
By Daniel Whitfield
25 tips for writing reliable webhook handlers
Small, concrete habits that turn a fragile webhook endpoint into one you can forget about — verification, idempotency, speed, testing, and operations.
By Daniel Whitfield
A buyer's checklist for evaluating a self-hosted payment gateway
Thirty questions to ask before you deploy anything that can move money — sorted by what they reveal.
By Omar Farouk, Daniel Whitfield
PostgreSQL patterns for payment ledgers
Integer money, append-only entries, balanced transactions, isolation levels, locking, and indexes — the database design that lets a payment record prove itself.
By Daniel Whitfield
Hardening a self-hosted payment gateway: a practical deployment guide
Network, containers, secrets, database, supply chain, and monitoring — the controls that matter when the software that moves value runs on your infrastructure.
By Daniel Whitfield
Building a webhook delivery system: the sender's side of the contract
Outbox, queue, signing, retries, dead letters, and observability — how to send events reliably to receivers you do not control.
By Daniel Whitfield
Webhooks are a product surface
If the event contract is vague, the integration will be a night job forever.
By Daniel Whitfield
More authors.
Layla Haddad
Principal Engineer, Payments Infrastructure
Designs the gateway architecture behind StablePay: state machines, indexing, and signing boundaries.
Emily Sinclair
Head of Product
Leads Northframe and Meridian, and the discovery work that turns shadow spreadsheets into products.
Omar Farouk
Engagement Lead, Services
Scopes and leads selected client builds, and helps startups and agencies decide what to build first.
Mohamed Hasan
Design & Frontend Lead
Leads interface design and frontend engineering across the catalog, with a focus on dense, calm operator UIs.
Mohamed Saad
Smart Contract Developer
Works on the on-chain side of payments: token transfers, event interfaces, and contract review for products that touch a chain.
El Sayed Abd Almohaymen
Mobile Developer
Builds mobile experiences that put approvals, queues, and payment status in the hands of people who are not at a desk.
Have a system like this to run?
Explore the catalog, or write down the problem and the constraints. We respond when the fit is real.