You run the business.I build the software.
Three platforms in productionMore than ten years shipping software233 fixes merged into 193 open-source projects
Founders bring me an idea and get a working product: the payments, the accounts, the apps, the admin, the deploys, built and run by one person who answers for all of it. Companies bring me a live system nobody fully understands any more, and I take it over. Three platforms are in production today, each built end to end and still running.
Each one is the whole product.
Schema, money movement, security policies, the apps, the admin console, the deploys, the store listing. Each one, the whole thing.
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.
In production since 2025. Co-founder. I built the engineering and I run it.
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.
Live on iOS, Android and web. Built for a client; live payments and live Shopify confirmed May 2026.
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.
Built March 2025 to July 2026 for one gym. No tests and no CI, said plainly.
Follow the signal through each platform.
Every stage is a decision made in the code, with what it solved and what it cost. Select a stage, or use the arrow keys. Each anatomy is also a page: GoldVault, Glitz and MicroGym.
Every row re-read against its repository on 4 September 2026. The receipts show where each number comes from.
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.
Checkout
Someone types an amount into a form. Everything after this depends on the platform checking the number it is about to charge, not the number it was handed.
- The problem
- The client declares the deposit amount. Risk and velocity thresholds are evaluated on that number, and the card is charged in full. A small declared amount would duck every threshold.
- The decision
- Risk and velocity evaluate the figure that becomes the card charge, not the declared split beside it. Both arrive from the browser; only one of them is what the card is charged. The declared amount is treated as untrusted input like everything else that arrives from a browser.
- What it cost
- Nothing moved. One variable changed and the ordering did not: the check still runs before the processor is called, on the amount the processor will be asked to charge. The cost was the version that shipped first, where a small declared amount ducked every threshold, and the commit that fixed it says so.
- 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
Strangers read my code and merged it.
Everything else on this page is my own account of my own work. This is not. An open-source maintainer accepts a change only when it is right, and 193 projects have accepted one of mine: Homebrew, Celery, Symfony, Pillow among them. 233 merged changes, each one linked from the full list, and the list refreshes itself every day.
- 193
- separate projects whose maintainers accepted a change from me, none of them mine. Receipts for every number on this page.
- 233
- merged changes across them, each one linked to its diff
In other people’s words.
The decisions, at full length.
The anatomy's decisions at full length: what went wrong, what it cost, and what the fix had to survive.
Engineering and taste.
Half of what goes wrong in a product is engineering. The other half is whether anyone wants it. Both are answered at the same desk.
The analytical half
A Master of Mathematical Finance from the University of Toronto, a BA in Applied Mathematics from Johns Hopkins, a first job on the engineering team at Coinsquare, then a decade of fintech and automation. The habit it left: the ledger is in Postgres functions, the trade-off is written next to the code, and every number here comes out of a repository.
The creative half
I write and record music. In high school I studied jazz guitar through Ravinia’s scholars programme in Chicago, with Bobby Broom and Willie Pickens. The same instinct designs the products: the illustration system on a partner’s site, the interface a trainer runs a room from, the drawing at the top of this page. Engineering decides whether a thing works. Taste decides whether anyone wants it.
- StudioApollo Twin X into a pair of HS8s. Guitar first, everything else after.
- CollectorGraded cards since childhood. Grails, never sold.
Principal engineer at a US automation startup, building browser and workflow automation for accounting. Before that, the management side of an edge AI inference platform running GPU infrastructure in Canada, and a decade of fintech before either. The platforms above carry my name on the whole of it.
The short answers.
What people ask after they find this page, answered the way I would on a call.
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?
On the engineering, yes, by design. The bugs that cost the most live at the handoffs between people, and a build with no handoffs does not have them. Design, brand and growth come from the Diamond Hook team when a build needs them, and I stay accountable for the whole.
Can you take over a codebase you did not write?
I have read 193 open-source codebases I had never opened before and had a fix merged into each one, 233 pull requests so far, 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.
How does a build run?
On a fixed scope of work with a price and a date, contracted through my consulting company and invoiced by phase, so you can stop after any phase. The repository and the infrastructure are in your company's name from the first day, so what you pay for is yours whether or not we work together again.
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 193 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.
Tell me what you are building.
A founder with a platform to build, or a live system that needs one owner. When a build needs design, brand or growth, I bring in the Diamond Hook team.
- 01
You send a note. It reaches me directly.
- 02
We talk for half an hour about what it is and where it is stuck.
- 03
If I am the right person, I say how I would build it and what it would take. If I am not, I say who might be.
Rather talk first? Book 30 minutes and skip the form.