Show HN: One prompt generates an app with its own database
10 comments
·September 18, 2025ch4s3
Some of there are pretty cools, trying to see if it can run a multiplayer doom.
ch4s3
And it works! https://www.manyminiapps.com/?c=da20213e-6832-4cd8-ac73-7669...
Albeit slowly.
stopachka
Oo cool idea! We don't limit the input size, so you could add more context. I wonder if giving it some docs on Instant's presence [1] could help it do the right thing with Doom. Ideally movements should be ephemeral rather than stored in the DB, and the system prompt we have doesn't say too much about that.
ch4s3
Here's my prompt
>Build a simple lofi black and white multiplayer doom clone where players drop in near each other in a procedural generated forest world. The graphics should be 2d in a 3d world. Players enter their name before joining. The DB tracks players names, scores, deaths, total play time. When a players is shot too many times and dies they randomly respawn. Players should spawn within visual range of each other. add some harmless non-players animals that roam around. generate some forest background noise to play. players should make a little sound when they walk that other players can hear. players should be able to hide behind trees. Try to make it fun.
It basically worked. https://www.manyminiapps.com/?c=da20213e-6832-4cd8-ac73-7669...
Hey HN, manyminiapps is the world first massively multiplayer online mini app builder (MMOMA)
*Here’s what it does:*
You load the page. You write 1 prompt and you get a mini app back in under 2 minutes. There’s no sign up, and you can see what everyone’s creating in real-time!
Each mini app comes with it’s own database and backend, so you can build shareable apps that save data.
*What’s different*
There are a lot of app builders that promise you’ll build production software for others. But we think true production software can take a long time to get right. Even if you don’t need to program there’s a lot of work involved.
What if we turned the promise around? Instead of “you vibe code software companies”, it’s “you build fun software for yourself”.
If you cut the problem right, LLMs as they are today can already deliver personal software. manyminiapps is meant to be an experiment to demonstrate this.
You may wonder: do you really need personal software? We’re not 100% sure, but it’s definitely an interesting question. Using manyminiapps so far has been surprising! We thought our friends would just try to build the common todo app, but instead we found them building wedding planners, chord progression helpers, inspiration lists, and retro games.
*How it works*
Instead of spinning up VMs or separate instances per app, we built a multi-tenant graph database on top of 1 large Postgres instance.
All databases live under 1 table, on an EAV table (entity, attribute, value). This makes it so creating an “app” is as light as creating a new row.
If you have heard of EAV tables before, you may know that most Postgres experts will tell you not to use them. Postgres needs to know statistics in order to make efficient query plans. But when you use EAV tables, Postgres can no longer get good statistics. This is usually a bad idea.
But we thought it was worth solving to get a multi-tenant relational database. To solve this problem we started saving our own statistics in a custom table. We use count-min sketches to keep stats about each app’s columns. When a user writes a query, we figure out the indexes to use and get pg_hint_plan to tell Postgres what to do.
*What we’ve learned so far*
We’ve tried both GPT 5, Claude Opus, and Claude Sonnet for LLM providers.
GPT 5 followed the instructions the best amongst the models. Even if you told it a completely nonsensical prompt (like “absda”, it would follow the system prompt and make an app for you. But GPT 5 was also the “most lazy”. The apps that came out tended to feel too simple, with little UI detail.
Both Claude Opus and Sonnet were less good at following instructions. Even when we told them to return just the code, they wanted to returned markdown blocks. But, after parsing through those blocks, the resulting apps felt much better.
To our surprise, we didn’t notice a difference in quality from Opus and Sonnet. Both models did well, with perhaps Sonnet following instructions more closely.
To get good results we iterated on prompts. We initially tried giving point-by-point instructions, but found that a prompt with a full example tended to do better. Here’s what we landed on:
https://gist.github.com/stopachka/a6b07e1e6daeb85fa7c9555d8f...
Let us know what you think, and hope you have fun : )