Base44 vs Lovable (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.

The catalog runs to roughly ninety individually documented integrations spanning CRM, data warehouses, ecommerce, payments, accounting, communications, HR, security scanning, analytics, storage and CMS, which is breadth across classes rather than depth in one. The design detail worth carrying is the three connection types. A connector can be attached as an app connector, a chat connector, or an app user connector where each end user of the published app connects their own account. That last one means a built app can act on behalf of its individual users rather than through one shared service credential, a materially better security posture than a single shared token. Not every connector supports every type, and each catalog page states which it supports. Beyond the catalog, an any-API route and a create-connector path cover anything unlisted, and custom MCP servers plus MCP registries make the tool surface open-ended.

Build mode, previously called Agent mode, takes ownership of execution end to end: it understands intent, explores the codebase for context, applies changes across files, and resolves issues that appear during development, with visible tasks showing progress. Paired with Plan mode for decisions, that is a two-phase multi-step system rather than single-shot generation. Subagents are documented as their own feature, so work delegates rather than running in one context, and cross-project referencing lets one project draw on another, so composition works between projects. Skills carry reusable instructions, and code mode and an editor expose the generated files for hand editing. Drafts and project history give the iteration loop somewhere to stand.

Project monitoring has Lovable check a project on a schedule, daily or weekly at a chosen time and optionally only after a minimum number of edits, reviewing the app code for broken functionality and recent visitor errors, then alerting by email and surfacing findings to fix in the project chat. That is a scheduled wake of the builder agent. Other routes in are the web chat, a Slack app, mobile and desktop apps, a Telegram route, the Lovable API and the Lovable MCP server. Monitoring is in beta, on Pro, Business and Enterprise.

Knowledge is persistent text instructions, not a document store. Workspace knowledge holds shared rules across every project such as coding standards, preferred libraries and naming conventions; project knowledge adds application purpose, database schema, architecture decisions and domain terminology. It is always included in context, which Lovable contrasts with Skills, which load on demand. Workspace knowledge is described as a text field. The limit is stated in Lovable's own FAQ: project and workspace knowledge plus the code and components are the primary context sources, and the reference material does not describe reading instruction files from the repository or external sources. There is no ingestion of customer documents and no retrieval over a corpus; this is closer to a durable system prompt than to grounding on a knowledge base. Design systems are a second structure but ground style rather than knowledge: any project can be designated a design system and others connect to inherit its components and styles, with immediate propagation and precedence ordering when several are connected, though Lovable notes they are not versioned.

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.

Lovable's state plainly persists: projects are durable objects with their own history, drafts persist unfinished work, project chat persists, and a Knowledge feature holds configuration that outlives any single conversation. Cross-project referencing makes state addressable between projects. What holds it at Partial is that none of it accumulates. Build mode explores the codebase for context at the start of each task rather than carrying learning forward, and skills are authored by the customer and stay as written; nothing is documented as the agent updating its own instructions after a correction. Durable state, yes; memory that compounds, no.

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 investigates the project and writes a plan the user reviews, edits and approves before any code is written, and Lovable states Plan mode never modifies code. It is one of three modes the user picks, and Build mode implements changes directly, so the approval sits in an optional mode rather than in the build path; project monitoring findings are fixed only when the user asks. Workspace admin controls, integration admin controls, groups and project visibility settings constrain who can do what.

The controls documented here govern Lovable itself, not only the app it builds: a trust center, SAML single sign-on, SCIM provisioning, two-factor authentication, workspace identity with identity reuse across workspaces, groups and people-level access control, integration admin controls, and Enterprise audit logs. Enterprise materials describe centralized identity, granular access controls and workspace-wide security oversight as the point of the plan. A data opt-out is documented as a Business capability, which matters because the training-data question is the one enterprise buyers ask first about an AI code generator, and it is answered as a setting rather than a policy statement. Secrets and build secrets are handled separately so credentials do not sit in generated code. Security scanning of the generated application, through a security center, security insights, sensitive-data scanning, scheduled Deep scans and Aikido and Wiz integrations, secures the output and counts toward testing. SOC 2 and ISO 27001 are consistent with the published trust center, but the certificates themselves have not been read.

Lovable audit-logs the platform itself, recording actions taken by workspace members. A change shipped on 24 August 2026 added client attribution, so each entry records whether an action came from Web, Desktop, iOS or Android, and the log filters by client or by member; entries before that date read as Unknown. That sits alongside project monitoring, logs, project usage and analytics, and security insights, so both the platform and the built app are observable. Audit logs are an Enterprise capability. What is still absent is a trace of the agent's own reasoning within a build: visible tasks show progress but not why a choice was made.

This is real residency, not disclosure. A default hosting region is chosen from Americas, Europe or Asia Pacific; on Business and Enterprise workspaces an admin can set a required region for every new project, and members then cannot choose otherwise, which is the enforcement half; and country-specific regions including Germany, Japan and United States East are available on Enterprise by request. Enterprise materials describe this as regional code hosting. One operational detail will catch people: the setting applies only to new projects, and existing projects keep the region they were created in, so a workspace that adopts a residency policy late does not relocate what it has already built. Beyond region choice the output is unconstrained: Lovable Cloud hosts with custom, verified and transferable domains, two-way GitHub sync gives the customer the codebase, and external deployment and hosting-ownership guidance covers taking the app elsewhere entirely.

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.

Design templates are documented as a Business capability, alongside a managed registry, a remix path for forking an existing project as a starting point, a prompting library, skills carrying reusable instructions, and design systems supplying the customer's own components. What Lovable ships ready-made is a set of design templates and a registry; the substantial reusable assets are ones the customer or the community builds. Remix is the closest to adopting a packaged asset, since forking a working project is adopting rather than assembling, but it depends on there being projects to fork.

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.

Lovable exposes no model selection anywhere in a documentation inventory of roughly two hundred pages, and an inventory that complete makes the silence meaningful. The near-misses do not count. Fireworks, Replicate, Perplexity and Gemini Enterprise appear as integrations, and an AI feature page sits among the Cloud backend pages; those give the application being built access to models, which is the opposite of what this axis measures. This is a product position rather than an oversight: Lovable is opinionated about the builder and open about what the built app can reach. A buyer with a model-approval policy will care.

Both directions are documented. Outbound, Lovable itself is callable from outside through a documented Lovable API and a Lovable MCP server. A third route is unusual: agent integrations turn the customer's published app into an MCP server for ChatGPT, Claude and other assistants, with configurable tools, sign-in and permissions. Lovable's framing is clear: people use an app by clicking buttons and moving through screens, an assistant cannot click, so it needs a list of actions instead. That extends the output rather than the platform, so it supports rather than carries the grade. Also documented: custom MCP servers, MCP registries, a create-connector path, an any-API route, and two-way GitHub and GitLab sync so the codebase leaves without lock-in.

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.

Browser testing has the platform interact with the customer's application in a real browser running in a virtual environment, clicking buttons, filling forms, navigating pages and verifying behavior with screenshots across different screen sizes. It returns a verdict: a Details view shows the steps taken and summarizes what worked and what did not, and the documented pattern is reproduce, fix, then verify. Where test and live environments are enabled it runs against the project preview in the test environment, so the evaluation happens before the change reaches anyone. A criterion applied by Lovable's mechanism to the customer's artifact ahead of release is Full.

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.

Browser testing is not computer use. Exercising the application just generated inside a browser to check that it works is verification of Lovable's own output; this axis counts only an agent operating third-party software that offers no programmatic interface. The preview toolbar and preview pages are the same thing viewed by a person. The Firecrawl and Apify integrations retrieve web content over HTTP, which is scraping rather than computer use. Everything Lovable's agent touches externally, it touches through a documented connector, an API or an MCP server. Nothing in a two-hundred-page documentation inventory describes navigating or operating an external application.