Open source AI app builders vs closed platforms: the lock-in fight is about output, not the IDE.

The category is closed. Stop looking for the open one.

I checked. The AI app builders an indie hacker would actually consider in 2026 are almost entirely closed-source IDEs. Lovable, Bolt, v0, Replit Agent, Cursor Agent, Base44, Emergent, Framer AI, Softr, Glide, and Bubble all run their IDE as a hosted closed-source service. Some have public repos for SDKs or model wrappers. None of them ship the actual product you use as a forkable codebase you can run locally. There is bolt.diy as a community fork of an earlier Bolt prototype, and a fistful of MIT-licensed CLI scaffolders that generate React from a prompt, but those are hobby projects, not products you can rely on to keep your data and credits.

mk0r is in the same bucket. The repository at github.com/m13v/appmaker is private as of 2026-05-13, and there is no LICENSE file. The team has talked about opening the in-VM scripts and the CLI under MIT eventually, but neither has happened yet. Anyone telling you mk0r is open source today is wrong, including a previous version of one of our own pages that referenced an MIT LICENSE that never existed. We fixed that page; we're writing this one to set the record straight on the broader question too.

The category being closed isn't a moral failing. It's a consequence of what these products actually have to do: provision real sandboxes, broker LLM credits, sign deploys, hold customer data. None of that is free, so the IDE itself stays behind a paywall and a private repo. Pretending otherwise on a comparison page is a tell that the writer hasn't actually shipped a category product.

The lock-in fight that actually matters

If "open source the IDE" isn't real for this category, then what is? Three concrete tests, in order of how often they bite an indie hacker who is six weeks into a project they want to keep.

These three are the dimensions every indie hacker should be checking before they commit. Most comparison articles list "has GitHub export" as one bullet and move on. That misses the more important question: when you export, what do you get? A custom DSL that compiles into the platform's runtime is technically "exportable" and practically a trap. A vanilla Vite project is just a Vite project.

On the second test, every popular AI builder claims it. Few actually pass it cleanly. GitHub sync, when it works, is the smoothest version: a real commit history on a repo you own. When it doesn't work, you discover that the platform only syncs published builds, not the editing checkpoints, or that the secrets are not in the repo, or that the integration packages are pinned to versions the platform hosts. The mk0r answer is a CLI that reads any file in the live sandbox by absolute path, not a syncing daemon. Less elegant, harder to lose data through.

The boring stack is the feature

The scaffold mk0r writes into every fresh sandbox is in src/core/vm-scripts.ts. The relevant chunk lives at lines 1782 to 1796 and reads like this: a vite.config.ts with @vitejs/plugin-react and @tailwindcss/vite, host bound to 0.0.0.0, port 5173, allowedHosts true, HMR on the WSS port. That is the exact configuration npm create vite@latest --template react-ts produces for you on the command line, with the Tailwind plugin added.

The only mk0r-specific file in the scaffold is src/mk0r-bridge.ts, a thirty-line module that posts HMR lifecycle events to window.parent so the iframe preview can skip a hard reload when Vite repainted in place. Delete it and the app runs identically; only the preview reload speed in the hosted dashboard changes. Nothing about your code depends on it.

This is deliberate. Other AI app builders win short-term by piling on platform-bound integrations (their auth, their DB client, their forms package). It demos better in a Loom video. It locks the codebase into the platform's runtime. mk0r's bet is that you would rather inherit a boring Vite project that runs anywhere than a platform-flavored one with smoother integrations. If the bet is wrong for your use case, Lovable + Supabase or Base44 are concrete alternatives, and you should switch.

Getting your code out, in seven commands

The portability story is a small REST API at /api/projects/[id]/files, plus the mk0rCLI that wraps it. Personal API keys live at mk0r.com/account/api-keys (one-click create, shown once). You can talk to the API with curl alone, or use the CLI wrapper for ergonomics. The whole "move my code somewhere else" loop is the same shape as scp from a remote box. Read the project list, cat the relevant files, cp the trees you want to keep, install locally.

That last block is the entire portability story for mk0r. There is no proprietary archive, no platform-only build step, no "export to ZIP" button that returns a different file tree than the live sandbox. The files on your laptop after mk0r cp are byte-for-byte the files the in-VM Vite dev server was serving. The server-side handler is src/app/api/projects/[id]/files/route.ts, which streams base64 over JSON with a 1.5 MB cap per inline read.

From there: any Vite host. Vercel via vercel deploy. Cloudflare Pages with the static output. Cloud Run with a static-site Dockerfile. Netlify drag-and-drop. An old Linode with nginx. None of those require mk0r to be alive when your users visit.

The honest comparison

A grid that gives Lovable credit where it is due. Lovable is what most people land on if they want managed convenience and are happy with a platform relationship. On the dimensions that matter for "own your output," mk0r and Lovable are both viable choices, with different bets.

Counterargument: why GitHub sync is still a real edge for Lovable

The honest version of this page admits where the closed-IDE-with-portable-output framing has a weak spot. Lovable's native GitHub sync is genuinely smoother than mk0r's "run cp in a shell" story. If you are the kind of indie hacker who wants every edit to flow into a real Git history without thinking about it, Lovable wins on that ergonomic axis today. mk0r's answer is "script it," which is a different tradeoff (you control the commit cadence, but you have to set it up).

Two reasons to still prefer mk0r's approach. First, file-level access via mk0r cat <projectId>:/app/<any-path>is a superset of GitHub sync. You can read non-tracked files, secrets, build artifacts, log files, anything in the sandbox. Lovable's sync only sees what they decide to put in your repo. Second, the files you pull are the same files the live preview is running. There is no "published build" layer between your editor and the artifact. When Lovable's sync misses an edit (it has, ask anyone who has used it past the first hour), you discover the gap in production.

So: if GitHub sync is your day-one must-have, take Lovable. If you want raw file access to the actual sandbox and are fine running a sync script you wrote in twenty minutes, take mk0r. Either is defensible; the wrong answer is the AI app builder whose "export" only ships a published bundle.

Where mk0r's closed-IDE side still locks you in

Three places this framing breaks. Naming them so you can decide before you spend the next month inside.

• The hosted preview URL. https://<vmId>.mk0r.com proxies to the in-VM Vite dev server. It is great for sharing a phone link to a friend mid-build. It is not a deploy target. If your sandbox sleeps or your subscription lapses, the URL stops responding. The fix is to pull files and deploy them somewhere stable. That is a real workflow, not a one-click button.
• Custom-domain deploys. Today the deploy-to-custom-domain path in src/app/api/publish/route.ts is a manual notification: it sends an email to the team behind the product, gated behind mk0r Pro. Self-serve domain deploys are not live yet. If you need an automated deploy pipeline from inside the IDE, mk0r is not the right tool today.
• Native GitHub sync. As above. The CLI gives you a sync primitive; there is no "connect to GitHub" toggle in the dashboard. If the difference matters to you, that is a real con and Lovable is the cleaner pick.

The take, in one paragraph

If you are an indie hacker afraid of AI app builder lock-in, stop looking for the open-source IDE. There almost isn't one. Pick the closed-source tool that is the most careful about the output it generates. Read what stack the generated app is in. Check if there is a way to read every file in the project. Verify that the code runs without the platform's runtime. mk0r's pitch is to be honest about being closed-source upstream and then go aggressively boring on the downstream: vanilla Vite, vanilla React, vanilla TS, vanilla Tailwind, an npm CLI that reads any file. If you ever decide to leave, the leaving takes twenty minutes and one bash loop. That is the form of trust that actually holds.