Last week we tried something we had been telling people was possible. We connected an AI coding assistant to our platform, gave it one paragraph describing a book club app, and stepped back.
This is what happened, including the parts that did not work.
The setup
Supero is a hosted backend for web apps. It provides the parts every app needs and few people enjoy writing: sign-in and access rules, with a database and an admin panel behind them. It also has an MCP server, which is how an assistant such as Claude Code or Cursor can talk to it directly.
The brief was one paragraph: members propose books and vote on next month's read, then RSVP to the monthly meeting. An organiser schedules the meetings. A member can change only their own vote.
We used Claude Code with a key that can build into one project and nothing else. Nothing was installed on the machine, and we wrote no code.
What the assistant did
It made 46 tool calls. It began by asking the platform who it was and which project it was allowed to build into, then read the build spec, which the platform serves live so that it always matches what the platform will accept that day. It turned the paragraph into a plan of records and screens, with a role for each kind of user. It fetched a reference app to copy patterns from. Then it wrote seven files and asked the platform to validate them. When they passed, it published a version and deployed it.
Validation and publishing both passed first time, in one to three seconds each. Nine minutes after the first call there was a URL.
Then we looked at the app
The deploy status said "running". The built-in test said "healthy". The home page said "No book selected for this month yet."
That was wrong. The starter data included a selected book. We asked the assistant to read the logs, and there it was: 8 of the app's 27 starter records had been refused by our own API, each with a permission error, while the records next to them went through. The setup step had printed a warning box saying the app was incomplete and should not be treated as a successful deploy. Then it exited normally, and every tool reported success.
A second deploy filled the gaps. Sixteen minutes after the first call we had an app we had clicked through, screen by screen: voting with a live tally, RSVPs that stuck, data that survived a reload.
We also found that the app's one automation never ran. The spec told the assistant to include a workflow. The deploy could not register it, said so in a log line, and carried on.
What we got wrong, plainly
Two faults, both ours, neither the assistant's.
First, a cache. When an app's access rules were written, one of our servers kept answering from the old rules for up to five minutes, so any request that happened to land there was refused while the request beside it, sent a moment later to a different server, went straight through. That is why the failures looked random.
Second, the workflow registration used the wrong identity inside the deployed app, one that is deliberately not allowed to touch service settings.
Under both sat a third problem, and it is the one worth remembering, because it is the reason two real faults could sit in plain sight behind a green status: every success signal we had checked that the app was up, and not one of them checked that what the app declared had actually been created.
What we fixed
Both faults were fixed within a day. We then wiped the test project and deployed the same app twice more. All 27 starter records were created both times. The workflow ran about five seconds after a member sent an RSVP. Deploys took about two and a half minutes.
Two things are still not right, and we are saying so. One of the checking tools still prints an out-of-date warning about workflows. And the status tool still reports only that the app started, so for now you should open the app and look.
What the assistant got right and wrong
Right: the access rules. A member can change their own vote and nobody else's. It stored each vote as its own record so the tally needs no extra lookups, which we had not asked for.
Wrong: voting never closes, though the brief implied rounds. A member cannot withdraw a vote, only change it. The first version greeted the user as "member" instead of by name.
None of that is hidden. The app is in a public repo with its source and a list of seven things it does not do yet.
Why we are publishing this
Because that list is the point. We have opened a repo for people who want to build this way. It has a step-by-step guide to a first app and 31 project briefs across 16 areas. It also has the book club app, with its known gaps listed and five of them open as issues. Within a day of opening them, someone we have never met claimed one.
You do not need to ask before building a brief, and several people can build the same one. The free plan covers three projects and asks for no card, though what it gives you is preview deployments that expire after thirty minutes. A URL that stays up is a paid plan. The apps you build are yours, under the MIT licence. The platform underneath is a hosted service, not open source. We would rather say that here than have you find out later.
Three things we would tell another team trying this:
- Read the logs of your first real run yourself. Our dashboards were green the whole time.
- Publish the gaps. A list of what does not work is an invitation; a polished demo is not.
- Count one run as one run. Sixteen minutes is what happened to us once, after one redeploy. It is not a benchmark.
Repo: https://github.com/supero-platform/supero-mcp
First app, step by step: https://github.com/supero-platform/supero-mcp/blob/main/docs/first-app.md
The book club app and its gaps: https://github.com/supero-platform/supero-mcp/tree/main/apps/community/book-club
Top comments (0)