Base44 vs StackBlitz Bolt (2026)

The reach is stated on a dedicated first-party product page. Superagents connect to Google Calendar, Gmail, Drive, Slack, Discord, X, CRMs and task managers, and the vendor closes the list with "plus anything that has an API or MCP". That last clause is the one that matters, because it makes the catalog a floor rather than a ceiling: coverage is bounded by what a customer's systems expose rather than by what Base44 has built. The MCP clause counts here and not on extensibility: an agent reaching out to MCP servers is the vendor's product consuming third-party tools. The two first-party MCP servers Base44 publishes run the other direction and count on extensibility. Both directions being present is unusual, and they are kept separate. Skills are a second extension route: up to ten attach per agent, mixing app skills created inside an app with workspace skills shared across the workspace, so capability units are reusable across agents. The community integrations catalog with a Create Integration flow and per-integration approval status, the enterprise controls over which connectors are available and whether credentials are shared or per-user, and the Wix distribution surfaces all stand as described above. Disclosure: the Agentic Index runs on Base44; this cell rests solely on base44.com/superagents, the public developer documentation and the Wix App Market listing.

Eight built-in MCP connectors plus any remote MCP server, each action toggled separately, alongside first-party integrations across design, version control, hosting, payments, data, mobile publishing and authentication.

A documented project lifecycle runs from prompt to published app across many files in an in-browser runtime, with Plan Mode as a separate planning phase, skills carrying reusable workflows and a Prompt Library.

Work reaches Bolt through the chatbox, fed by prompts, files, designs, templates or a Lovable import, with real-time collaboration; no scheduled, webhook or event-driven trigger is documented.

A design system generated from the customer's material is stored, managed and kept in sync as its sources change, alongside knowledge held at account, workspace and project scope.

Memory is the product's premise, and its controls are documented. The Superagents page states it plainly: "Every conversation, every preference, every goal. Your Superagent picks up where it left off and gets more useful the longer you work with it." Picking up where it left off is the state limb; getting more useful over time is the accumulation limb, and the vendor makes the claim on both the launch announcement and the product page. The documentation adds the controls: the owner turns memory on or off and scopes it as separated, within each conversation, or shared across all conversations; under Personalization the user can review what the Superagent has learned about them and delete memories they no longer want it to use; and the agent changes how it uses memory when the owner asks in chat. What remains undocumented is a retention period. The built-in database provides durable application state independently of agent memory. Disclosure: the Agentic Index runs on Base44; this cell is graded from Base44's public pages only.

Projects, backups, version history, project knowledge and design systems persist, but nothing the agent learns accumulates; skills and saved prompts stay as the customer wrote them.

The Full rests on Base44's own approval steps. The Superagent asks for the owner's approval before sending a change to an app, naming the app it is about to change, and before installing a skill, answerable Yes or No in WhatsApp; the product changelog also records the AI chat asking for approval before writing files to a connected GitHub repository. Each is Base44 pausing before a consequential write inside its own surface, not a gate the customer already owns such as GitHub branch protection. Bounding sits around those gates: per-agent access definition with sandboxed execution and granular entity permissions, per-agent permission toggles with Update data and Delete data advised only where the role needs them, connector-level blocking across apps, Superagents and in-app agents, and a workspace-level switch disabling Superagents entirely. The vendor states an agent "only accesses what you explicitly allow" and is "sandboxed, permissions-based and managed by Base44", with no local servers, no Docker and no open ports.

Plan Mode is an optional review step and connector actions, team roles and repository access can be restricted, but Build Mode applies changes with no documented approval step.

SOC 2 Type 2 with a trust profile at trust.bolt.new, encryption, monitoring and annual penetration tests, plus team access management and provisioning on Teams and SSO and audit logs on Enterprise.

Version history, GitHub commit sync, hosting analytics and database logs record the project, but no agent run trace or tool-call record is documented and no organization audit log appears in the documentation.

BYOK deployment runs Bolt inside the customer's own AWS or Azure tenant with full infrastructure isolation, development executes client-side in the browser, and published apps can sit on Bolt Cloud, Netlify, Expo or anywhere through GitHub export.

The gallery is at base44.com/templates and describes itself as an App Templates and Pre Made Apps Marketplace: "Browse 100+ ready-made app templates and design layouts built by the Base44 community. Pick an app template, customize it with AI, and launch today." It is categorized, with dedicated pages for community and creative tools among others, so it is browsable in the sense the bar asks for rather than a flat list. The clone flow is documented in the vendor's own blog and describes adoption rather than inspiration: browse the available templates and look for apps that share similar workflows, then clone one and ask Base44 to modify it. The worked example takes a project management template for an event app because its task assignment flow fits. That is take-and-adapt, which is what this axis measures. Skills are a second packaged asset class. The agent documentation states up to ten skills attach per agent, mixing app skills created inside a specific app with workspace skills shared across the workspace. Workspace-shared reusable capability units are packaged assets adopted across agents, which is the pack shape at a finer grain than whole applications. The product's premise is generation, not templates, and both are true: generation being primary does not withhold the grade when a hundred-plus adoptable artifacts are published alongside it. One limit: these are application templates and reusable skills rather than prebuilt Superagents. No library of ready-made agents to adopt was found, and generation remains the only documented route to a Superagent.

A vendor Templates catalog of named, previewable working templates opens in Bolt with one click, alongside team templates, built-in prompts and skills.

The agent documentation sets out the control directly: "Under AI model, select the model that powers your agent. Keep Automatic selected for fast, cost-effective responses, or choose a model from Google Gemini, OpenAI GPT, or Anthropic Claude for more advanced reasoning." Three named frontier providers, chosen by the customer, set per agent, and "you can switch models at any time if your needs change." The cost transparency is the part worth carrying. The documentation publishes credit consumption per model tier, naming the Automatic default as based on Gemini 3.1 Flash Lite at around three credits per message, Gemini 3 Flash for stronger reasoning at moderate increase, and higher-end models such as GPT-5.6 Sol for complex analysis at more credits. Publishing the price of each choice at the point of choosing is what makes selection an operable decision rather than a dropdown. Automatic as a default, not as a ceiling, is the right shape: vendor routing is available for people who do not want to decide, and explicit selection is available for people who do. One disputed point, on a different surface. Users on the vendor's public feedback forum report that model selection was removed from the builder chat, the coding surface that writes the app, leaving it on automatic only. That is a forum report rather than documentation, and it is a distinct surface from the agent model setting documented here. Worth knowing if a buyer asks which model writes their code as opposed to which model runs their agent.

Bolt Forge lets the customer pick among open-source models from several makers on individual Pro plans, in research preview to 14 October 2026, while the Standard and Max agents choose models behind the scenes.

GitHub sync with full codebase export, outbound MCP connectors and the open-source bolt.diy fork, but no API, SDK or first-party MCP server for driving Bolt itself is documented.

A real iteration loop for the artifact being built, and no evaluation of the agent. The artifact half has strengthened: the changelog records that "when the AI tests your app, the screenshots it takes now appear in the AI chat as a gallery. Click any screenshot to see it full size, including for tests that did not pass." So the platform runs its own tests against a generated app, records pass and fail, and shows visual evidence of both. That is a readable result about the customer's own work. It stays at Partial because the bar asks for a result the customer can read and compare about the agent's behavior, and two things are missing. Comparison: nothing retains a test set, records expected outputs, or establishes whether this version behaves better than the last. And subject: these tests exercise the generated application, not the Superagent. The agent is the autonomous artifact running on schedules and real events against live systems, and nothing rehearses it against test inputs before it does. That is real measurement of the wrong object, on a platform that builds two different kinds of artifact and tests only one of them. The gap matters more here than the grade conveys, and it is worth a buyer's attention: model selection is switchable per agent and skills attach up to ten per agent, so behavior has several dimensions a builder can change, with no regression check across any of them. The two-way GitHub export remains the customer-controlled testing route, letting a team run their own scanners over generated code.

A project security check finds and fixes security problems, with live preview, backups, branches and troubleshooting guides, but no test generation, regression suite or scoring of one build against another.

A platform-shipped browser the agent operates, in two forms. In the cloud, a Superagent works on the web from chat with no setup, in a browser the user can watch through a Live Browser view and expand or close while the agent keeps working; browser actions and data extractions are metered per action, and failed actions are free. On the user's own machine, the first-party Superagent by Base44 Chrome extension lets the agent open tabs, click, type and read pages in the user's Chrome, inside its own tab group under Chrome's control banner and with the user's signed-in sessions, falling back to the cloud browser when Chrome is not connected. Private network addresses are blocked. Disclosure: the Agentic Index runs on Base44; this cell is graded from Base44's public pages only.

Builds run in an in-browser Node runtime and the live preview shows the agent's own app; no operation of third-party software through its interface is documented.