I build the entire platform.Every layer, one pair of hands.
3 platforms in production10,989 GitHub contributions, year to 4 Sep 202695 fixes merged into 76 open-source projects
Every platform has seams: where the schema meets the payments, where the policies meet the app. The costly bugs live in the seams, between people. I take the whole path, so every seam has one owner. Three platforms are in production that way: payments infrastructure, a marketplace on mobile and the web, and a live-operations tool that runs a room full of people.
Each one is the whole product.
Schema, money-movement functions, security policies, the apps, the admin console, the emails, the cron, the CI, the monitoring, the store submission, the marketing site. Not a slice of each. All of each.
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 that was actually made in the code, with what it solved and what it cost. This is the part a senior engineer reads. Select a stage, or use the arrow keys. Each anatomy is also a page of its own: GoldVault, Glitz and MicroGym.
Every row re-read against its repository on 4 September 2026. The receipts show where each number comes from and what the re-read changed.
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
The merchant's customer starts a deposit or a cash-out.
- 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
The ledger.
2,203 commits and about 302,000 lines across the three platforms alone, March 2025 to August 2026, counted on 4 September 2026. The rest is smaller, and finished. The receipts say how each number was counted.
| Year | Name | What | Stack | Status |
|---|---|---|---|---|
| 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 |
Fixes in tools other people depend on.
76 codebases I had never opened before, and a fix merged into each one: 95 pull requests in 18 days, 18 August to 4 September 2026, from Pillow and Homebrew to Celery and Symfony. Most started from reading the source rather than an issue tracker. That is what taking over someone else's platform looks like, and every change is linked from the full list.
- brew
- react-hook-form
- claude-code-router
- pnpm
- raylib
- mise
- github-mcp-server
- symfony
- skills
- nx
- postcss
- celery
- keepassxc
- claude-hud
- planning-with-files
- testify
- commitlint
- goreleaser
- pipecat
- Pillow
- pipx
- scapy
- llm
- sqlglot
- 10,989
- contributions on GitHub in the year to 4 September 2026, most in private repositories
- 2,250
- in calendar 2025
- 95
- merged changes in 76 repositories that are not mine. Receipts for every number on this page.
The decisions, at full length.
The anatomy's decisions written out properly: what went wrong, what it cost, and what the fix had to survive. For the reader who wants to check my work.
What one owner buys you.
Half of what goes wrong in a product is engineering. The other half is whether anyone wants to use it. Both halves are answered at the same desk.
The analytical half
A Master of Mathematical Finance from the University of Toronto and a BA in Applied Mathematics from Johns Hopkins. First job on the engineering team at Coinsquare, at the time the largest cryptocurrency exchange in Canada, then a decade of fintech and automation. It shows up as a habit: the ledger is in Postgres functions, the trade-off is written next to the code, and every number on this page comes out of a repository.
The creative half
I write and record music, and have since before I wrote software. Search my name and the songwriter is what you find first. 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.
- DailyRuns to the gym and trains there. Bands when travelling.
Principal engineer at a US automation startup, building browser and workflow automation for accounting. Engineer on an edge AI inference platform running GPU infrastructure in Canada. The platforms above are the same work with my name on the whole of it.
The short answers.
What people ask after they find this page, answered the way I would answer 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?
- 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 4 September 2026 I read 76 open-source codebases I had never opened and had a fix merged into each one: 95 pull requests in 18 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 seventy-six 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@dylanpulver.com. Both come straight to me, nobody screens them, and I reply within two business days.
Tell me what you are building.
The usual shape is a founder with a platform to build, or a live system that needs someone to own the whole of it. For larger builds I bring a team through Diamond Hook.
- 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.
