Own product
Next.js
TypeScript
PostgreSQL
Drizzle ORM
Clerk
Directory
Godot

Godot Foundry — I Built a Marketplace, Then Took the Payments Out

My own product: a directory of Godot assets that links out to where they are sold. It was a marketplace with Stripe Connect payouts, and the more useful half of the story is why that is coming back out.

Godot Foundry, browsing the Godot asset directory

Godot Foundry is my own product. Nobody commissioned it and there was no brief: I saw a gap and built into it. As of September 2026 it is a directory — it lists assets for the Godot game engine and links out to wherever each one is actually sold, on other people’s sites. It got there by being a marketplace first, and then having the payments taken back out. That second half is the part worth reading.

The gap, and the shape I got wrong

Unlike Unity and Unreal, Godot has no dedicated commercial marketplace for premium assets: the official library carries free resources only, and everything else is scattered across Gumroad and itch.io pages with no quality signal and no common place to look. The gap is real. What I got wrong was the shape of the answer. I read “there is no marketplace” as “build a marketplace”, when what the community was actually short of was a way to find what already existed.

What I built

A complete multi-sided platform on Next.js and TypeScript, with PostgreSQL and Drizzle ORM behind it and Stripe Connect for multi-party payments. It served three user types: buyers browsing and purchasing, creators running a shop, and administrators moderating content and processing payouts. Everything in this section is written in the past tense, because that is what it is.

Creator onboarding, which is where a marketplace is won or lost

Supply comes before demand. If there is nothing to buy, nobody comes back, so the piece I spent the most time on was the creator side. Creators applied with a portfolio and sample work; once approved they got a dashboard with rich text editing, multi-image galleries, version changelogs, engine-version compatibility, variant pricing and an FAQ editor, plus Stripe Connect Express onboarding for direct payouts with a configurable platform fee. Which fields are required, how long approval takes, how the dashboard greets someone on day one — each of those is a conversion decision rather than a UX nicety. I still think that is the right way to look at it. I also still could not make the supply side materialise.

Moderation and the trust layer

An admin panel handled creator applications, product moderation through a state machine — draft, pending review, published, rejected, archived — review moderation, user management, payout processing with minimum thresholds, and platform settings, with an audit log behind every administrative action. Around it: Clerk for authentication, so credentials never touched my own infrastructure; locked-down HTTP headers and a strict Content Security Policy; sanitisation of every piece of creator-submitted HTML before it renders, so no listing could drop a script into a product page; Upstash Redis rate limiting on anything touching money or account state; and Sentry watching errors in production. None of that shows up on the homepage. On anything handling multi-party payments it is the product, and it is the part of this build I would lift onto a client project tomorrow.

The payments work, in the past tense

Stripe destination charges: the buyer paid the platform, the platform took its fee, and the creator received the balance directly, with Stripe carrying identity verification and tax reporting across dozens of countries. Licence keys were generated and delivered on each sale. Around that sat wishlists, a review system with helpfulness voting and creator replies, analytics snapshots and dashboards, an affiliate system with generated referral codes, and featured slots that expired on a schedule. Every piece of it worked as built. I am not publishing creator, listing or revenue figures beyond the one below, because nothing else about them is measured well enough to show you.

Why the payments are coming out

The supply side never arrived. Three listings existed, and I could see no path to the hundred it would take before a buyer had a reason to come back. A marketplace with three listings is not a marketplace; it is a shop. And being the merchant of record for a catalogue that thin buys you tax obligations, refund handling and support duty, with none of the volume or network effect that is supposed to pay for them. So the listings have been deleted and the payments layer is being removed. A directory does the useful half of the job without any of that: it lists what exists and sends people to where it is sold.

I am not going to dress that up

It was not the plan all along. I built the expensive half of a marketplace, launched it, and then decided the product was the wrong shape for the market and took that half back out. Almost nobody publishes this part, which is exactly why it is here. If you are hiring someone to build a platform, the willingness to unbuild something is the behaviour you want in them, and it is a great deal cheaper to demonstrate on my own money than on yours.

Where it stands

A live directory that points people at Godot assets sold elsewhere, and a marketplace and payments stack that I designed, built, ran and retired. Knowing when a product should not become a merchant of record — and being willing to take it out again once it is already built — is worth more on a client engagement than knowing how to wire Stripe Connect up in the first place.

Admin view of the creator revenue split, from the marketplace build

Need this built under your brand?

I work white-label with design studios: your client stays yours, I build behind you, and they never know I exist.