# Dylan Pulver

> Software engineer and entrepreneur in Toronto. Builds complete platforms end
> to end, from the database schema to the app store listing: payments
> infrastructure, a three-sided marketplace, live-operations software.

## Who he is

Dylan Pulver is a Canadian-American software engineer and entrepreneur based in
Toronto. He grew up in Chicago, studied Applied Mathematics at Johns Hopkins
University and holds a Master of Mathematical Finance from the University of
Toronto. His first engineering job was at Coinsquare, at the time the largest
cryptocurrency exchange in Canada; the decade since has been fintech and
automation platforms built end to end: schema, money-movement functions,
security policies, mobile and web apps, admin consoles, email, cron, CI,
monitoring, store submission and marketing site. He is a co-founder of
GoldVault, a B2B payments platform, and advises founders and engineering teams
on product engineering and payments. He also writes and records music; the
musician and the engineer of the same name are the same person (Spotify:
https://open.spotify.com/artist/0EdZQUgxIXfaQhbKN2xSJu).

## Three platforms

### GoldVault

Payment infrastructure for high-risk merchants. Identity, risk screening, a ledger and fee collection, sitting between a merchant's customers and the merchant's own card processing. It never holds anyone's money.

Stack: Next.js, Postgres with row-level security, Supabase, Vercel, Sentry, Metabase. Status: In production since 2025. Co-founder. I built the engineering and I run it.. Full anatomy, every stage with its decision and cost: https://dylanpulver.com/platforms/goldvault

- 914 commits, Jul 2025 to Aug 2026
- 95k active lines, TypeScript and SQL, archive excluded
- 100 Postgres functions, shipped as migrations
- 2 processors behind one adapter, a third slot reserved
- 4 auth mechanisms across three trust tiers
- 21 admin screens

### Glitz

A three-sided commerce marketplace. Brands list products, creators mint tracking links, buyers purchase through them. Commissions are attributed automatically, held thirty days, and paid out, with teams of creators splitting the commission by rule.

Stack: Flutter, Firebase, Cloud Functions, Next.js, Stripe Connect, Shopify. Status: Live on iOS, Android and web. Built for a client; live payments and live Shopify confirmed May 2026.. Full anatomy, every stage with its decision and cost: https://dylanpulver.com/platforms/glitz

- 787 commits across mobile, backend and web
- 83k lines of Dart, 94 screens
- 59 Cloud Functions
- 89 web pages against the same database
- 58 mobile builds shipped
- 34 Maestro flows, screenshot helpers included

### MicroGym

A live-operations tool for small-group training, built with a Toronto gym. Trainers assemble workouts, schedule sessions with a roster, then run the session live on a tablet while an assessment engine adapts every exercise to every member in the room.

Stack: Next.js, Supabase, Postgres with row-level security. Status: Built March 2025 to July 2026 for one gym. No tests and no CI, said plainly.. Full anatomy, every stage with its decision and cost: https://dylanpulver.com/platforms/microgym

- 502 commits, all one author
- 81k lines across 344 files
- 34 tables
- 1,507 lines in the substitution engine
- 4 phases of security hardening, each reversible
- 4 to 0 rows a member could see that were not theirs

## Everything shipped

- 2025, GoldVault: Payment infrastructure for high-risk merchants. Co-founder; built and run the engineering. (Next.js, Postgres, Supabase, Vercel; In production)
- 2025, Glitz: Three-sided commerce marketplace on iOS, Android and web, with team commission splits. Built for a client. (Flutter, Firebase, Next.js, Stripe Connect, Shopify; Live)
- 2025, MicroGym: Live-operations tool for small-group training, with per-member exercise substitution. (Next.js, Supabase; In use at one gym)
- 2026, sealbinhan.com: Personal site for an investor and operator: engraved illustration system, lead pipeline, both themes. (Next.js, Resend, Vercel; Live)
- 2026, Athens Eye Care: Site rebuild for an ophthalmology clinic in Athens. (Next.js, Vercel; Live, awaiting domain cutover)
- 2026, Sealed Hunt: Research platform for collectible grails across 81 categories, the research as well as the build. (Single-file web app, Vercel; Live)
- 2026, crm-master: Open-source CRM with a nudge queue for people you owe a reply. (Next.js, Supabase; Open source)
- 2026, dylanpulver.com: This site. The anatomy component, the signal drawings and the lead pipeline are hand-built. (Next.js, Resend, Vercel; You are here)

## Open source

112 pull requests merged into 93 open-source projects between 2026-08-18 and 2026-09-06, including Homebrew/brew, react-hook-form/react-hook-form, pnpm/pnpm, raysan5/raylib, jdx/mise, tokio-rs/tokio, symfony/symfony, nrwl/nx, postcss/postcss, celery/celery, keepassxreboot/keepassxc, stretchr/testify, fmtlib/fmt, conventional-changelog/commitlint, briannesbitt/Carbon, goreleaser/goreleaser, pipecat-ai/pipecat, python-pillow/Pillow, pypa/pipx, secdev/scapy. Full list, each linked to the merged change: https://dylanpulver.com/open-source

## Receipts

Every number and decision on the site with the command or file and line that produced it, and what was corrected when the repositories were re-read: https://dylanpulver.com/receipts

## Full text

Every anatomy stage and every note in one plain-text file: https://dylanpulver.com/llms-full.txt

## Engineering notes

Four decisions from the platforms above, written out at full length: what
went wrong, what it cost, and what the fix had to survive.

- [The webhook that credits twice](https://dylanpulver.com/notes/idempotent-payment-webhooks): A payment processor delivers every result at least once. The interesting engineering is in what happens when your side fails halfway through.
- [A ledger you can edit from a route handler is not a ledger](https://dylanpulver.com/notes/ledger-in-postgres-functions): Why every movement of value on the payments platform goes through a Postgres function, and what it costs to keep it that way.
- [Four rows that were not theirs](https://dylanpulver.com/notes/row-level-security-hardening): Hardening multi-tenant row-level security in four reversible phases, verified by impersonating a member and counting what they could see.
- [The bug inside the fix](https://dylanpulver.com/notes/one-pair-of-hands): A payout race, the fix for it, the bug inside that fix, and why it is the best argument I have for one person owning the whole path.
- [The sale that arrives with no referrer](https://dylanpulver.com/notes/attribution-through-an-in-app-browser): A creator shares a link on Instagram, the buyer taps it, installs the app and purchases. Nothing in that chain carries the creator's name across. Here is what does.
- [The minimum that belongs to someone else](https://dylanpulver.com/notes/payout-minimums-per-brand): Held commissions are released to creators once a brand's payout minimum is met. Group the money by creator, the obvious way, and one brand's minimum ends up holding another brand's money.
- [The commission that must not mint twice](https://dylanpulver.com/notes/exactly-once-commission-on-a-document-store): A buyer pays and the platform owes a creator a commission. Between those two facts sit a colluding pair, a call that arrives twice, and a cart with three items on one payment.
- [The rule that has to be written twice](https://dylanpulver.com/notes/security-rules-do-not-cascade): Firestore security rules do not cascade to subcollections. Forget that in one place and a single query returns every private message on the platform.
- [Thirty days in the ledger](https://dylanpulver.com/notes/thirty-days-in-the-ledger): Splitting a payment at charge time is simpler and wrong: a refund after the creator is paid is a clawback nobody enjoys. Holding the money creates a different set of problems, and each piece of machinery around the hold answers one of them.
- [Arbitrary but consistent](https://dylanpulver.com/notes/arbitrary-but-consistent): A gym's assessment answers become rules that swap an exercise for a member before a session. Two rules can disagree about the same movement. The code says who wins, and the comment admits how.

## Questions people ask

### What do you actually do?

I build software platforms end to end and stay accountable for the whole thing: the database schema, the money movement, the security policies, the apps, the admin console, the email, the deploys, the store listing. Three of them are in production now.

### Do you work alone?

For most builds, yes. The bugs that cost the most live at the handoffs between people, and a build with no handoffs does not have them. When a build needs more than one person I bring them, and I stay accountable for the whole.

### Can you take over a codebase you did not write?

Between 18 August and 6 September 2026 I read 93 open-source codebases I had never opened and had a fix merged into each one: 112 pull requests in 20 days, in tools from Homebrew to Celery. Reading someone else's platform and finding what is wrong with it is most of the job. The list is on the open-source page, each change linked.

### Who do you work with?

Founders with a platform to build, and companies with a live system that needs someone to own the whole of it. I grew up in Chicago and live in Toronto, a dual Canadian and US citizen, so working with a US or Canadian company is straightforward, and most of it happens remotely.

### Are you a fractional CTO, a contractor, or what?

Call it what your org chart needs: founding engineer, fractional CTO, the one contractor who owns the platform. The shape is the same. I take the whole path, from the schema to the store listing, and I stay accountable for it after launch. Fixed scope or ongoing, whichever the build needs.

### Who is this not for?

Agencies looking for a subcontractor. Teams that need one more person on a ticket queue. Anyone who wants a slice: the backend without the app, or the app without the backend. I take the whole thing, or I point you to someone good for the part you need.

### Are you taking on work?

Yes, one or two builds at a time. Either a build gets the attention it needs or I say so before it starts. The fastest way to find out is to send a note below.

### What do the first two weeks look like?

Day one, repository and infrastructure access in your company's name. Week one, I read the whole codebase the way I read the 93 on the open-source page, and you get a written list of what I found, ordered by what it would cost you. Week two, the first change ships, with its trade-off written next to the code and a migration you can roll back. If the list says the build should not go ahead, you hear that in week one too.

### What happens if you get hit by a bus?

The next engineer opens the repository and finds the migrations in order, the trade-offs written next to the code, tests where money moves, and a README that runs it. That is not a handover promise; it is how the platforms are built, because I am also the person who has to read them a year later. For anything with a company behind it, the repository and the infrastructure are in the company's name from the first day.

### Are you the Dylan Pulver on SoundCloud?

Yes. Same person. I have written and recorded music since before I wrote software, and the studio is where the drawings on this page come from. Engineering decides whether a thing works; taste decides whether anyone wants it.

### What is the fastest way to reach you?

The form below or dylan@diamondhook.com. Both come straight to me, nobody screens them, and I reply within two business days.

## Ways to work with him

- A platform to build: End-to-end build of a new software platform by one accountable engineer: data model, payments, security, web and mobile apps, admin tools, deployment and launch.
- A build to lead or rescue: Taking ownership of a live system or a stalled build: understanding the whole of it, fixing what is wrong, and carrying it forward.
- Advice on architecture or payments: Architecture and payments-infrastructure advice for founders and engineering teams, grounded in systems that are running in production.

## Working with him

The usual shape is a founder with a platform to build, or a live system that
needs someone to own the whole of it. A note goes directly to him; a half-hour
conversation follows; if he is the right person he says how he would build it
and what it would take, and if he is not, he says who might be. For larger
builds he brings a team through Diamond Hook.

## Links

- [Home](https://dylanpulver.com)
- [LinkedIn](https://www.linkedin.com/in/dylanryanpulver/)
- [GitHub](https://github.com/dylanpulver)
- [SoundCloud](https://soundcloud.com/dylan-pulver)

## Contact

Email: dylan@diamondhook.com