Prompt to app releases, May 2026: a commit-level log from inside one tool

Why a release log instead of a ranking

A ranking tells you what an editor read on a launch page. A release log tells you what a maintainer decided was worth typing into a commit message at 11 PM. The two converge eventually, but in the short window of a single month they tell very different stories. The category was busy in May 2026: more autonomy for the in-app agent, less friction at the user's entry, and more honest billing gates that fire when a real cost begins. We wrote the log instead of the ranking because the log is the piece nobody else is going to write about us, and writing it forces us to be specific.

Today is May 9. Nine days into the month. The log is short on purpose. We will keep adding to it through the rest of May, week by week. If you bookmark this page and come back on June 1, the shape will be the same and the items will be more numerous.

Week of May 5: scheduling lands

The biggest change of the week was the scheduler. A prompt-to-app tool that can build a daily-digest UI but cannot actually run anything daily is a strange shape: the agent generates a route, the route compiles, and then it sits there. On May 5 we wired a full scheduling primitive in. The agent now has a tool it can call to register a cron job, and Cloud Scheduler does the firing.

The architecture is small enough to draw on a napkin: a JSON-RPC MCP server inside the VM talks to a Next.js API route on mk0r.com, which talks to Cloud Scheduler, which calls back into another API route that runs the job in the user's VM sandbox.

Where to read it

The MCP server is docker/e2b/files/opt/scheduler-mcp.js (263 lines). It reads /run/mk0r-session.json to get the session key for the project, and posts every tool call to /api/agent/schedules on mk0r.com. The runner that actually executes a job inside a user sandbox lives at src/lib/scheduler-runner.ts (103 lines). The agent prompt is told to use the new MCP at commit 78abf0d5 in src/core/vm-claude-md.ts.

Week of May 7: anon turn gate, paywall flip, mobile gating

Three changes in the same week, all about the boundary between free and paid and between anonymous and signed in. Read in order: build is free, iterate is free, publishing to a custom domain is paid; an anonymous user gets a generous handful of turns before the sign-in step is asked for; nothing about the mobile preview is allowed to render before it is actually ready.

The previous gate was billing-shaped. A 21-day free trial that asked for a card up front. We removed it on May 7. The current gate is value-shaped: an anonymous user gets enough turns to see the agent do its thing, and only then is asked to sign in to keep going. The number of turns moved from 2 to 6 in one day after staging telemetry showed the smaller number was interrupting the first iteration cycle.

Week of May 8: lazy provisioning

The eager provisioning path created a Neon database and a Resend audience for every session, including anonymous ones that may never come back. That was a lot of free-tier capacity going to sessions that did not need it. The provisioning MCP at docker/e2b/files/opt/provisioning-mcp.js (279 lines) lets the agent provision on demand. The refactor in src/core/freestyle.ts (commit c954413f) defers the call until the running task actually needs a database or an email sender. The agent can still get them; it just has to ask. The new endpoint is src/app/api/agent/provision/route.ts.

The full release log, May 1 to May 9

Every shipped item with the file you can open and the commit you can blame. Bento because each item carries weight, not because the page needed a grid.

What we tried and reverted

Two threads of churn deserve naming because they are the part a release log usually hides. The Firebase auth flow churned all day on May 8: popup, then redirect, then redirect with proxy rewrites, then setting authDomain to the current host (which triggered redirect_uri_mismatch from Google), then reverting authDomain to the canonical Firebase host, then ending the day on popup again. The lesson, written into project memory after the fact, is to keep authDomain on firebaseapp.com regardless of which host the app is served from. The other thread is the anonymous turn gate going from 2 to 6 in 24 hours. We could have gone slower, but the cost of the wrong number was visible in staging traffic the same morning we shipped it, so we shipped the new number the next morning.

If a release log only shows the wins, it is not really a log. Both reverts are in git log and both are reflected in the file headers of src/firebase/auth-provider.tsx today.

How this fits the broader category in May 2026

The pattern across prompt-to-app tools this month is roughly the same shape, even if the specifics vary. More autonomy at the agent layer (more MCP-style tools the agent can call, instead of more chat boilerplate). Less friction at the entry (fewer signup walls in front of the first build). Tighter mobile preview behavior (do not show the user a broken iframe). And honest billing gates that fire when a real cost begins, not at the front door.

We will not pretend to know exactly which competitor shipped what on which day. We do know the category-level direction because we read the release notes and play with the products ourselves. If you want a sourced map of the wider category, the two best aggregators we use are an LLM-release tracker at llm-stats.com and a vendor-release tracker at releasebot.io. Neither of those is mk0r-specific, and both update faster than any single tool's changelog.

Things this log will probably contain by May 31

We are bad at predicting our own roadmap, so this is short. Realistic candidates for the next three weeks: a saved-prompts primitive so the agent can recall earlier turns without rebuilding context; a per-app analytics surface (PostHog is already wired, the UI is not); the second iteration of the scheduler to support pause and resume; better handling of the slow first paint on the mobile preview when Vite is still booting; and a lot more typing into the publishing flow. The entries above will land here with their commit references when they ship, or they will not land at all and that will be its own data point.