The AI app builder for hobbyists is the one that is fine with you abandoning the project
I want to build a habit tracker with a streak graph...
Most AI app builders are tuned for the founder use case: sign up, start a project, return on Tuesday, ship by Friday, scale on Monday. That shape punishes hobbyists, because hobby projects have a different distribution. Most of them get abandoned. A few become serious. The tool should not assume forward motion. mk0r is what happens when you design the loop around the abandoned case instead.
Direct answer, verified May 14 2026
mk0r. No account, a Linux sandbox boots in about 2.5 seconds, every prompt becomes a git commit you can rewind, the agent verifies its own output in a real Chromium, and the sandbox auto-disposes after one hour so abandoned projects do not haunt your inbox.
All of the above is verifiable in the open-source repo at github.com/m13v/appmaker. The one-hour timer is at src/core/e2b.ts line 33. The per-prompt commits and revert helpers are at lines 1895 and 1951. The browser self-verification rules are at src/core/vm-claude-md.ts lines 278 to 283.
A Saturday with mk0r, told as a timeline
This is not a feature tour. It is what an actual hobby session looks like, including the part where you walk away and the part where the tool is fine with that.
1:42 PM — open mk0r.com, type one sentence
No account screen, no email field, no plan picker. The cursor sits in a text box. Type 'a habit tracker with daily streaks and a graph that shows the last 30 days.' Hit return.
Behind the scenes, a pre-warmed E2B sandbox attaches itself to your browser session in about 2.5 seconds. Vite is already running on port 5173. Chromium is already up on display :99. None of that is your problem.
1:43 PM — watch the file tree appear
The agent writes App.tsx, then components/Tracker.tsx, then components/StreakGraph.tsx, then types/habit.ts. Each file streams in line by line. The preview iframe on the right reloads as soon as Vite picks up the new files.
The agent commits to git after each meaningful change, so by the time you stop reading the first file, you already have a rewind point. The commit message names what changed.
1:46 PM — agent looks at its own work
Before saying 'done,' the agent navigates the in-sandbox Chromium to localhost:5173, takes a DOM snapshot, reads browser_console_messages. The streak graph is rendering as a blank SVG because the test data is empty. The agent sees that and adds a seven-day seed.
This is the part no other AI app builder does. Every shipped change has been verified in a real browser by the model itself. You are not the QA team.
1:51 PM — first 'wait, can it also...'
You ask for habit categories. The agent adds a tags field to the type, a select to the form, and color-codes the bars on the graph. Another commit lands. Total time so far: nine minutes.
The iteration loop is short because there is no save-build-deploy step. The sandbox is the build, and the preview is the deploy.
2:14 PM — bad idea, rewind
You ask the agent to add login. Five minutes later there is a half-broken auth flow you do not want, because actually you just wanted to email yourself a weekly summary. Open the history panel, click the commit before 'add auth.' Done. Five minutes erased.
revertToSha in src/core/e2b.ts at line 1951 creates a new commit that reverts to the target sha. Your linear history stays linear. Nothing is destroyed, but the working tree matches the moment before the bad idea.
3:38 PM — distracted, close the tab
You decide to go for a walk. You leave the tab open or you do not, it does not matter. The sandbox times itself out after one hour of inactivity. The git history persists in Firestore. The private GitHub repo is sitting at m13v/mk0r-<your-session-slug>.
E2B_TIMEOUT_MS = 3,600,000 in src/core/e2b.ts line 33. When the timer expires, the VM is gone. No idle billing, no abandoned-tab guilt, no cleanup to remember next week.
Next Saturday — maybe you come back, maybe you do not
If you reopen the session URL, mk0r restores the snapshot, replays the git history, and you continue. If you never reopen it, nothing has been left on for anyone to clean up. Both outcomes are first-class.
This is the part of the design that is actually for hobbyists. Software made for founders punishes you for not returning. Software made for hobbyists treats not returning as a normal, expected outcome.
The closed verification loop, in one diagram
The thing most hobbyist articles never mention is the part where the agent looks at the page itself. Chromium is running headfully inside the same sandbox as your app. The agent has a Playwright server attached to it over Chrome DevTools Protocol. Before every turn finishes, it does the loop below.
Per-turn agent verification
you ship a prompt
'add a streak graph'
agent edits files in /app/src
real TypeScript on disk
Vite HMR reloads the preview
via wss on port 5173
agent opens Chromium itself
Playwright MCP over CDP at 127.0.0.1:9222
agent reads the rendered DOM
and the console messages
agent fixes or hands back
no completion claim until the screen matches intent
The rule that drives it is one short paragraph in src/core/vm-claude-md.ts: do not report completion until the browser shows the expected result. The blank-page failure mode of one-shot AI code generation gets caught before you ever see it.
What the git history of an actual session looks like
Every prompt is one commit. Every undo is a fresh commit that reverts the working tree. The history is linear and readable, the way a careful human developer would keep it, except no human had to remember to type git commit.
Notice the third entry. The agent built an auth flow on turn 5, you rewound it on turn 6, and the working tree on turn 7 matches the state from turn 4. The commit you reverted is still in the log, marked as reverted. You can fish it back out later if you change your mind.
“The Linux sandbox running your app times itself out after exactly one hour. Anything you forget about cleans itself up.”
src/core/e2b.ts line 33 — E2B_TIMEOUT_MS = 3_600_000
Why the abandonment-first design changes which projects you start
The hidden cost of every project-starter tool is the future cost of cleaning up after the projects you abandon. The Heroku app you never deployed. The Vercel project that still pings you about build minutes. The Firebase project tied to a Google account you forgot you used. The Mailchimp audience that hit the cap because of a launch you did not finish.
Hobbyists feel this cost more than founders, because hobbyists start more things and finish a lower fraction of them. Founders accept the cleanup tax as the cost of doing business. Hobbyists start fewer projects to avoid the tax. That is the real damage: good hobby ideas die before they get tried, because the trying comes with a cleanup tail.
When the tool itself promises to clean up after you, the math changes. You start the bad ideas. You start the joke ideas. You start the ideas you would never start if every attempt added one more line to a list of things you owe future-you. A meaningful chunk of the apps actually shipped on mk0r exist because the friction floor was lower than the friction floor of opening a terminal.
When mk0r is the right shape for the project
Honest scoping. The hobbyist sweet spot covers a lot, but it does not cover everything. The two lists below tell you whether to start here or somewhere else.
Good fit
- You have a small idea and the words to describe it.
- You want to see something rendered before you decide whether to invest.
- You are fine reading what the AI wrote and asking for tweaks.
- You are happy with mobile-first HTML, CSS, JS, or Vite + React.
- You accept that you might not finish, and you do not want that to cost you anything.
Outgrew this
- You need a native iOS or Android binary on the App Store.
- You need a real-time multi-user state machine, like Figma's.
- You need a payment flow that goes live to real customers this week.
- You want a visual editor where you drag boxes around.
- You want a product manager dashboard, not a single text box.
If the second list describes your idea, you are not really building a hobby project anymore. You are building a product. Use Cursor, Replit Agent, or Bolt and accept the project dashboard.
A short note on the open-source repo
mk0r is an open-source app at github.com/m13v/appmaker. The exact file paths referenced in this guide (src/core/e2b.ts, src/core/vm-claude-md.ts, src/core/service-provisioning.ts) are live in the repo so you can read what the agent reads. If you want to host your own instance for a tighter hobbyist loop, bring your own E2B template, Anthropic API key, and Neon/Resend/GitHub credentials. If you just want to build something this afternoon, mk0r.com works without any of that.
Frequently asked questions
What does 'built for projects you'll abandon' actually mean in the code?
Three things, all verifiable in the open-source repo at github.com/m13v/appmaker. First, src/core/e2b.ts line 33 sets E2B_TIMEOUT_MS to 3,600,000 milliseconds (one hour). The Linux sandbox running your app kills itself after that, so an abandoned session does not keep a VM warm or charge a meter. Second, every prompt becomes a real git commit via commitTurn() at line 1895. You can rewind any change with revertToSha() at line 1951, which means experimentation has no cost. Third, no signup. There is no account that fills up with half-finished apps, no dashboard you avoid because it makes you feel guilty about the seven unfinished projects.
Why does the one hour sandbox timer matter for hobby projects specifically?
Hobby projects have a known distribution: most get abandoned within a week, a few become serious. If the tooling assumes every project is the serious case, every abandoned project becomes a tab you forgot to close, a free tier you keep meaning to clean up, an audience in Mailchimp that hits the cap because of a Saturday experiment from two years ago. mk0r flips the default. The expensive resources (the VM, the live preview, the Playwright session) clean themselves up. The cheap resources you might want later (the git history in Firestore, the private GitHub repo, the Neon database) persist. The hobbyist pattern (try fast, walk away, maybe come back) maps to that shape exactly.
Where does my code go if I do want to keep it?
Every session gets a private GitHub repo created via the GitHub API in src/core/service-provisioning.ts. The repo name is mk0r-<twelve-char-session-slug>, created under m13v, and the repo URL is written to /app/.env inside the sandbox so the agent knows where to push. The code itself is real Vite + React + TypeScript + Tailwind in /app. If you abandon the project, the repo just sits there. If you want it for yourself later, you fork it. You are not stuck inside a no-code editor.
How is this different from Replit, v0, Bolt, or Lovable?
Those products are excellent at the founder use case: build, iterate, ship, scale. They each ask you to sign up, give you a project dashboard, charge a meter, and assume forward motion. mk0r is built for the use case where forward motion is not the goal. No signup gate. No project dashboard. The session is ephemeral by default. The git history is per-turn instead of per-feature. You can come back to a session via its URL or you can never come back; the product behaves the same in both cases.
Can the agent actually tell whether the thing it built works?
Yes, that is the most underrated piece. Chromium runs headfully inside the sandbox on an Xvfb display, with its DevTools port on 9222. A Playwright MCP server is attached over CDP. The agent's instructions at src/core/vm-claude-md.ts lines 278 to 283 say after every UI change: navigate to http://localhost:5173 via Playwright, take a DOM snapshot, check browser_console_messages for runtime errors, verify the component is actually imported into App.tsx, and do not report completion until the browser shows the expected result. So if the agent ships a broken import and the screen is blank, it sees that, fixes it, and tries again, all before handing the turn back to you. You stop being the QA team for vibe coding.
What kinds of hobby projects actually work in this shape?
Anything that fits a single-page web app with a small backend, which turns out to be a lot. Recent things people built on mk0r: a personal habit tracker that stores rows in the per-session Neon Postgres, a flashcard quiz with active recall scheduling, a meme generator that hits an open source image API, a desktop automation demo that hits a local agent, a name pronunciation drill, a pictionary words app for a Friday night party, a QR code generator. Anything that needs an iPhone-only native API, a real-time multi-user state machine, or a complex billing flow will outgrow this shape; those are not hobby projects anymore, they are products.
Is the code actually mine? Can I read what the AI wrote?
Every file is real TypeScript on disk in /app. You can open the in-VM terminal, run cat src/App.tsx, and see exactly what was written. Every prompt is a commit you can git log and git diff. If you connect the private GitHub repo created at session start, you can clone the source from your laptop and keep iterating in Cursor or VS Code without mk0r at all. The point of the product is to remove friction at the start, not to lock you in at the end.
Do I need to know any code to use this?
No, but a hobbyist who knows even a little HTML or JavaScript gets more out of it than a pure non-developer would, because they can read what the AI wrote, spot the part they want to change, and ask for a precise tweak instead of restarting from scratch. The product happily generates from one sentence with no follow-up, but the people who stick around tend to be the ones who enjoy the loop of asking, looking, asking again.
What is the catch with the open-source repo?
The hosted product runs paid infrastructure: E2B sandboxes, Anthropic API calls for Claude, Neon Postgres projects, Resend audiences, GitHub repos under m13v. The source at github.com/m13v/appmaker is AGPL-style and runnable locally, but you supply your own credentials for every external service. For a hobbyist tinkering on weekends, mk0r.com is the easy path. For a hobbyist who wants to host their own and own the whole stack, the source is there.
Want to talk about a hobby project that wants to become real?
Fifteen minutes with the person who built the abandonment-first loop. Useful if the idea has outgrown the sandbox and you are not sure whether to keep going.
Related
More on what makes mk0r different
AI App Builder, No Signup: What's Actually Running
Six exposed ports, a real Chromium with Playwright, a Vite dev server, a Neon Postgres, a Resend key, and a private GitHub repo. All for an anonymous visitor.
AI App Builder with Backend: The First-Turn Test
Postgres, an email key, an analytics tag, and a private repo live in /app/.env before your first message, so the agent can persist things on turn one.
The Weekend Project Single-File HTML Playbook
One file. No build step. No hosting drama. Eight ideas you can finish before Sunday dinner.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.