Jotform AI App Builder vs mk0r: forms-as-app, or real source?
Jotform's AI builds an app inside Jotform. The output is a Progressive Web App glued together from Jotform forms and widgets, hosted on Jotform's runtime, capped by Jotform's submission limits. mk0r's AI writes plain React + TypeScript into a real Vite project running on a 4 vCPU Linux sandbox. They share a label and almost nothing else.
Jotform AI App Builder is a no-code tool that turns a natural language prompt into a Jotform-hosted PWA composed of forms, widgets, and approval flows. Free Starter plan caps you at 5 forms and 100 monthly submissions; paid tiers start around $34/month billed annually. The app is not exportable as source.
Verified against jotform.com/ai/app-generator and jotform.com/pricing.
The thesis: same label, different categories
Most reviews of Jotform's AI App Builder, including Jotform's own marketing, say the same thing: chat with the AI, describe an app, get a working app. That description hides the part that decides whether the tool fits you. Jotform's AI assembles a configuration of Jotform primitives (forms, widgets, approval workflows) and stores that configuration in Jotform's database. Jotform's runtime renders it. You edit it inside Jotform's no-code interface. There is no source code at any point in the loop.
That is the right shape if your app is fundamentally a form. A client intake. An approval queue. A signup flow that hands data off to a CRM. The 800+ templates and 70+ widgets exist because those workflows recur across thousands of small businesses, and Jotform has spent more than a decade building a primitives library for them.
mk0r is built around a different question. What if the AI wrote actual React, into a real project, that you could open and read and modify and host anywhere? The answer to that question is not a competitor to Jotform. It is a different category of tool.
What “an app” means in each tool
The clearest way to see the gap is to walk what each tool produces, side by side.
Jotform: prompt → assembled PWA
- 1
Prompt
Describe the app: name, what it should look like, which forms to include.
- 2
AI assembles widgets
Picks from 800+ templates and 70+ widgets (maps, e-signatures, approval flows, payment fields).
- 3
No-code editor
Refine fonts, colors, layout, copy, integrations. The app stays inside Jotform's editor.
- 4
Publish to PWA
App goes live on a Jotform-hosted PWA URL. Submissions count against your plan's monthly cap.
mk0r: prompt → real React project in a sandbox
- 1
Prompt
Describe the app in one sentence. No signup, no plan picker.
- 2
Sandbox boots
E2B template mk0r-app-builder, 4 vCPU, 4096 MB. Vite dev server on 5173. Real Chromium for self-testing.
- 3
Agent writes code
Plain React + TypeScript files at /app. Tailwind v4 for styling. The agent loads its own output in Playwright to verify it.
- 4
Iterate or export
Keep prompting in the same VM, or pull the source and host the app anywhere standard React + Vite runs.
Jotform's last step is “publish to a hosted PWA”. mk0r's last step is “keep iterating, or pull the source.” That is not a marketing distinction. It is the architectural choice the two products are built around.
“The runtime is the product. Whatever the AI generates, it generates in the shape the runtime can render.”
The honest read on any AI app builder
The anchor fact: what is actually running on mk0r's side
When you open mk0r.com and start typing, here is what the sandbox is actually doing. Every fact below is checkable in the public mk0r repo at github.com/m13v/appmaker.
- E2B sandbox template name
mk0r-app-builder, template id2yi5lxazr1abcs2ew6h8, 4 vCPU, 4096 MB. Source:docker/e2b/e2b.toml. - Pre-scaffolded Vite + React + TypeScript + Tailwind CSS v4 project at
/app, dev server on port 5173 with HMR. Source:docker/e2b/e2b.Dockerfile. @playwright/mcp@0.0.70running against a Debian-packaged Chromium. The agent uses it to load its own output and verify what actually rendered.@agentclientprotocol/claude-agent-acp@0.25.0hosts Claude inside the VM. Bridge listens internally and is fronted by a reverse proxy on port 3000.- Xvfb + x11vnc + websockify give you a live screencast of the running app while the agent works.
You will not find numbers like these in a Jotform comparison page because Jotform's AI App Builder does not have a runtime exposed to you. You do not see ports. You do not see a Chromium. You see Jotform's editor, which is the right abstraction for that product but a closed one.
How a single prompt becomes real code on mk0r
The flow below is what one prompt looks like end to end. Every edge here is a real network call inside the VM, not a logical abstraction.
One prompt, end to end
Your prompt
A single sentence describing the app you want.
Agent in a sandbox
Claude runs inside the VM via @agentclientprotocol/claude-agent-acp@0.25.0.
Real React source
Files are written to /app/src on a live Vite + React + TS + Tailwind v4 project.
Self-test loop
@playwright/mcp@0.0.70 opens the running app in Chromium. The agent reads what actually rendered.
Live preview
Port 3000 proxy fronts Vite (5173), MCP (3001), and the ACP bridge (3002). You watch it build.
The self-test loop is the part that is hardest to bolt onto a forms platform. To self-test, the agent has to be able to render the app it wrote. Inside a real browser. With a real DOM. mk0r runs Chromium in the same sandbox so this is one hop. A forms-and-widgets editor does not have a separate browser to test against because the editor itself is the target.
Want to see this run on a real prompt?
Fifteen minutes. Bring an app idea. We open mk0r in a browser, watch the sandbox boot, and end with a working React + TS project you can take with you.
Side by side
| Feature | Jotform AI App Builder | mk0r |
|---|---|---|
| Output category | Jotform-hosted PWA (forms + widgets) | Real Vite + React + TypeScript project |
| Where the app runs | Jotform's runtime, on Jotform's domain | Your sandbox, exportable to any host |
| Account required to start | Yes | No |
| Free-tier usage cap | 5 forms, 100 monthly submissions | No submission cap, no form cap |
| Code export | Submission data only (CSV, Excel, PDF) | Full source from /app, portable |
| Agent self-tests the build | No | Yes, via @playwright/mcp@0.0.70 in the VM |
| Best fit | Form-shaped business workflows, intake, approvals | Anything that is not fundamentally a form |
None of this is a knock on Jotform. It is the right tool for forms-shaped business apps. It is the wrong tool if what you want is React source you can host anywhere.
When Jotform is the right answer
If your idea reduces to “collect data, route it, do something with the results,” Jotform's AI is going to outrun mk0r every time. The 800-template library and the widget catalog are decade-deep. Submissions, payments, e-signatures, conditional logic, integrations: all of that works out of the box, exactly the way you would want it to. You do not want an AI writing that from scratch in React when the platform answer already exists.
The trade is that everything has to fit Jotform's shape. If your idea drifts off the form-and-widget grid, the friction shows up fast. That is when the conversation switches from “Jotform vs mk0r” to “Jotform or real code?”
When mk0r is the right answer
You want to prototype fast, you do not want to create another account, and you want the output to be code you can read and host wherever you host things now. Or your app is genuinely not a form. A small game. A custom calculator with a weird UI. A demo that needs animation. A throwaway prototype to put in front of three users tomorrow morning.
The minimum viable mk0r session is: open the site, type a sentence, watch the sandbox boot, watch the agent write code against a live Vite server while a real Chromium loads it. No plan picker. No submission cap. No editor screen between you and the running app.
Frequently asked questions
What does Jotform AI App Builder actually generate?
A Jotform-hosted Progressive Web App (PWA) composed of Jotform forms, widgets (maps, e-signatures, payment fields, approval flows), and a custom theme. The output is not source code. It is a record in Jotform's database that Jotform's runtime renders for end users on a jotform.com or Jotform-app subdomain. You configure it in Jotform's no-code editor; you do not download a project or push it to your own host.
Do I need a Jotform account, and what are the limits?
Yes, you need a Jotform account to save and share an app you generate. The free Starter plan caps you at 5 forms total, 100 monthly form submissions, and roughly 100 MB of storage, with Jotform branding on the rendered forms. Paid plans (Bronze through Enterprise) raise those caps and remove the branding. Pricing starts around $34/month billed annually as of May 2026.
How is mk0r different in one sentence?
Jotform's AI generates a config that Jotform's runtime renders. mk0r's AI writes plain React + TypeScript files into a real Vite project that lives in a Linux sandbox you control, with no signup, no submission counter, and no platform-shaped data model gating what the app can be.
What is actually running on mk0r's side when I describe an app?
An E2B sandbox (template name 'mk0r-app-builder', template id '2yi5lxazr1abcs2ew6h8') with 4 vCPU and 4096 MB RAM. Vite dev server runs on port 5173 with HMR. Chromium plus @playwright/mcp@0.0.70 give the agent a real browser to test what it just wrote. @agentclientprotocol/claude-agent-acp@0.25.0 hosts the agent itself. A reverse proxy on port 3000 fronts everything. All of this is verifiable in docker/e2b/e2b.toml and docker/e2b/e2b.Dockerfile in the public mk0r repo.
Is mk0r the right tool if I really do want a form app?
Sometimes yes, sometimes no. If your idea is fundamentally 'collect submissions, route them through approvals, send results to a CRM', Jotform's primitives are purpose-built for that and you will get there faster on Jotform than asking an AI to scaffold the same workflow in React from scratch. Use mk0r when the app you want is not a form, when you want real source code you can host anywhere, or when you do not want a per-submission usage cap on something you are still prototyping.
Can I export the app Jotform's AI generated?
Submissions data exports as CSV, Excel, PDF, or via integrations and the Jotform API. The app shell itself, the form definitions, the widget configs, the workflow, does not export as a standalone codebase. If you outgrow Jotform you do not move the app; you rebuild on a new platform and migrate the submission history. mk0r's output is the opposite: a plain Vite + React + TypeScript project at /app, no proprietary runtime to migrate away from.
Why is the comparison framed as 'two different categories'?
Because they answer different questions. 'Jotform AI App Builder' answers 'can I describe a form-shaped business app and let AI assemble it from Jotform's primitives?' 'mk0r' answers 'can I describe an arbitrary mobile-first app and have AI write the actual React + TypeScript for it in a sandbox I can poke at?' The user intent overlaps for prompts like 'a simple app that takes some input and shows a result', but it diverges hard once you want code, exports, or a non-form shape.
Does mk0r save my work, given there is no signup?
Each first-time visitor gets a random UUID stored in localStorage. That key is the session identity for the sandbox; come back from the same browser and you reattach to the same project. There is an optional Google sign-in for syncing across devices, but you can use mk0r end-to-end without ever creating an account. Jotform requires an account before you can save anything.
Describe an app in one sentence. Get a real React + TypeScript project running in a sandbox. No signup, no submission cap.
Try mk0r