Stream.gg

Building a game in Unreal Engine throws off a great deal of work that never ships: environment assets, character rigs, shader setups, gameplay systems built for one project and shelved when it changed direction. A market for finished assets exists. Nothing existed for the stage before finished, where a developer is still building and the people who want to see the work completed have no way to help pay for it.

That is a gap in the financial relationship, not in the tooling. A backer who wants a particular feature built has no mechanism to fund it. A developer with a half-built system and an audience has no way to turn that interest into the time to finish. Both sides want the same thing and cannot transact.

Stream.gg was built to test whether a different model, closer to Kickstarter for game assets than to an asset store, had real demand. Developers share in-progress Unreal projects. Backers contribute money to the specific features or milestones they want to see built.

The founder's constraint was explicit: six weeks to an MVP that could go in front of real developers and real backers. Not a demo and not a clickable prototype, but a working marketplace where a developer could list a project, a backer could contribute actual money, and the transaction would be real. If the mechanics worked and people used them, the concept would attract investment. If they did not, the founder wanted to know before spending more.

Six weeks rules out almost everything. The build was cut to the loop that would produce evidence: project listing, backer contribution, milestone-based payment release, project updates. Every request outside that loop was written down and deferred. The discipline was not about speed for its own sake; it was about making sure the thing being tested was the model, not the polish.

A developer creates a project listing with a description, screenshots, a funding goal and a breakdown of backing tiers, each tied to what it opens up: a specific feature, an asset pack, access to early builds. Backers browse live projects, choose a tier and contribute through Stripe.

Contributions do not go straight to the developer. They are held and released when a milestone is confirmed, or refunded if the project misses its funding goal by the deadline. Developers post progress updates to the project page, visible to every backer. Backers are notified when an update lands and when a project they back reaches a milestone.

Each side has a view of its own. The developer profile shows active and completed projects, total backers and funding history, which is the reputation a future backer will judge. The backer dashboard shows every backed project, the tier on each and the pending milestone dates, so a backer always knows what they are waiting on.

The simplest payment flow releases funds the moment someone backs. It is what a tip jar does, and it is what many early marketplaces do because it removes the hard part. It was rejected because it removes the point.

A backer paying for a specific feature needs some assurance the feature will be built. Immediate payout offers none, and without it the model collapses into donation with extra steps. Milestone-gated release ties the developer's access to money to demonstrable progress: reach the milestone, get the release. It is what makes the backing relationship a relationship rather than a gift.

The cost is real. Holding funds, confirming milestones, handling refunds when a goal is missed, and keeping both parties informed adds complexity to the payment flow that a six-week build could ill afford. It was kept anyway, because a marketplace that validated demand for donations would have validated the wrong thing.

A developer lists a project with a goal, tiers and a first set of screenshots. Backers find it, choose the tier that gets them the feature they care about, and pay. Their money is held. The developer builds, posts updates and marks the first milestone; backers see it in their notifications and on their dashboards.

When the milestone is confirmed, the corresponding funds release to the developer. If the project misses its goal by the deadline, every contribution refunds without anyone chasing. Neither side tracks who has paid what, when the next milestone falls due or whether a refund is owed. The platform holds the state, and the two dashboards read from it.

For the founder, the daily work was watching the numbers rather than operating the marketplace. That was the whole idea: a loop that runs itself well enough to tell you whether it should exist.

The marketplace was live with real transactions inside the six-week window. Developers listed projects, backers contributed, and the milestone release flow ran correctly from the first cycle. The MVP produced what it was built to produce: evidence, in the form of specific developers and specific backers willing to use the model with real money.

That evidence was enough to support the next round of funding conversations for the Mexico-based founding team. The concept survived the six-week test, and the foundation it left behind, a listing model, a held-and-released payment flow on Stripe and a notification loop between developer and backer, is the part of the product that does not have to be built twice.