Base44: no-code application, website and agent building from a description
Status: Active | Last tested: 2026-09-27 (Base44, as its product, pricing, documentation and legal pages described it on that date) | Re-check: trigger-based (max 6 months)
Active: the tool is current and recommended.
Reviewed as documented at base44.com in September 2026. The platform sells one subscription that covers several distinct jobs: building apps and websites from a description, running AI agents inside those apps, and an assistant called a Superagent that works outside them, over messaging channels and a browser extension. All of them are in scope here, and the contract terms that connect them are the reason this review spends as much length on the documents as on the interface.
Base44 scores 5.0 out of 10 on the U365 CI-First Review, which is CI-First Positive, with a Humics-Risky protection badge at -2 / +3 and a Medium AI Imposture Risk carrying Skill Illusion High. A person with a clear process and no engineering background gets a working application the same day, with a database, a login and an address, and the same subscription covers websites and an outbound assistant.
For detailed explanations of the CI-First evaluation terms used in this review, including the Humics Protection Badge and the AI Imposture Risk levels, see the Glossary at the end of this post.
In this Tool Review
Status and Re-check
Status: Active | Last tested: 2026-09-27 (Base44, as its product, pricing, documentation and legal pages described it on that date) | Re-check: trigger-based (max 6 months)
Active: the tool is current and recommended.
For detailed explanations of the CI-First evaluation terms used in this review, including the Humics Protection Badge and the AI Imposture Risk levels, see the Glossary at the end of this post.
Re-check triggers:
Publication of an independent measurement of generated-app quality. No third party has published a repeatable measurement of how far an app built on Base44 gets before a human developer must take over, or how often a finished app survives real use. The Quality sub-score rests on editorial hands-on assessments, on the vendor's own security scanning and on what users report. A benchmark, a completion study or a named enterprise result would move the Quality reasoning.
A change to the training position on the plans most readers buy. The documentation states that the exclusion from AI model training is built into the Enterprise plan, that on every other plan workspace data can be used to train AI models, and that there is no opt-out setting. Any change, in either direction, is a re-check.
A change to the licence over what you build and what you upload. The terms take a perpetual, irrevocable, worldwide, sub-licensable licence over Customer Data and Generated Output, and a separate clause permits the vendor to use any version of your data in its own marketing. An amendment to either clause changes the adoption calculus set out in Section 7c below.
A change to the refund, renewal or chargeback terms, or a published credit unit price. Today the fees are non-cancelable and non-refundable, renewal is automatic unless switched off, a chargeback is treated as a breach that can block the account, and no page states what one credit costs. A published rate card, or an overage bill, would change the Time and Quantity reasoning.
A change to the default app visibility, or to the authentication answer. The documented default for site-like apps is public without sign-in, and the platform's own help page states that authentication tokens are stored in the browser's local storage with HttpOnly storage not currently available. Either moving would change the Limits section and Section 7c of this review.
A change to the surfaces where the Superagent acts under your identity. The Slack user connector is documented as replying in your name, the browser extension works in sites you are already signed in to, and a trusted caller can use every tool the agent has. A narrower default, or a wider one, changes the Social Authenticity reasoning.
A certification change or a material security incident. The security pages state SOC 2 Type II and ISO 27001, and the platform carries a 2025 authentication-bypass disclosure that was fixed quickly. A change to the certification, or a new incident, belongs in the procurement file rather than in a footnote.
A change to the credit mechanics. Credits expire at the end of each cycle, integration actions cannot be priced before they run, and the vendor's own documentation describes the published per-action figures as estimates. Roll-over, cost preview or top-ups would change the setup advice.
The Base44 name, one brand and two entities, stated before the review begins
A reader who buys this product signs a contract with one company name, reads a privacy policy issued by another, and sees a third in the footer. The distinction belongs at the top of the review.
Name | What it is | Relationship to this review |
Base44 | The product reviewed here: a no-code platform that builds apps, websites and AI agents from a description, with the Superagent assistant running alongside them. The working surfaces are app.base44.com and base44.com | The subject of this review |
Wix.com Ltd. | The company named in the terms of service as the one that operates the Base44-branded services. The product was acquired on 18 June 2025 and the terms now name Wix.com Ltd. as the contracting party, with New York law and JAMS arbitration | The contracting party. A reader comparing the site against a purchase order should use the entity in the terms |
Base44, Inc. | The entity that issues the privacy policy, with a compliance contact address at base44.com | The same group under a second name. The privacy policy and the terms therefore carry different issuers |
The parent's own product line | Wix also sells website building, payments and business tools under its own brand, and the Base44 payment features are governed by the Wix Payments terms that the Base44 terms incorporate by reference | Relevant to a buyer who already holds a Wix agreement, because some of the terms a Base44 app inherits are Wix's rather than Base44's |
Two consequences follow. First, the contract position, the data position and the payments position are spread across documents issued by more than one entity, and this review quotes each one with the surface it came from rather than treating them as a single set. Second, the platform is owned by a larger, listed company, which changes the solvency question that a pre-acquisition Base44 would have raised and does not change the contract terms at all.
Tool Snapshot
Base44
Tagline: The homepage presents the product as the place where you "Build your own apps, websites, products and AI agents on Base44 using your own words," and describes the stack as complete before you start: "Ship something real with vibe coding, without touching a server, wiring up a payment provider, or configuring a database. It's all already there."
Category: No-code application and agent platform. A browser builder that turns a description into a full-stack application with its own database, authentication and hosting, plus a website surface, an in-app AI agent layer, an outbound assistant called a Superagent, and a developer path through an SDK, a CLI and a GitHub sync.
Primary use cases:
Building an internal tool or dashboard that would otherwise be a spreadsheet, from a written description, without a development queue.
Producing a working prototype of a product idea so that feedback is about the workflow rather than about a mockup.
Publishing a website or a campaign microsite with a form, a domain and analytics attached.
Adding an AI agent inside an app that can read and write records, call tools and answer users from your own material.
Running a personal assistant outside the platform, over WhatsApp, Telegram, iMessage or Slack, that watches inboxes, calendars and connected tools and acts on them.
Pricing summary: Freemium with a permanent free tier and four paid tiers, billed annually or monthly. The vendor leads with annual figures and states a 20 percent saving on annual billing. Free: $0, 25 message credits and 100 integration credits per month, up to five apps. Starter: $16 per month billed annually, or $20 month to month, 100 message credits and 2,000 integration credits. Builder: $40 or $50, 250 and 10,000 credits. Pro: $80 or $100, 500 and 20,000 credits. Elite: $160 or $200, 1,200 and 50,000 credits. Message credits meter the AI build conversation; integration credits meter what a running app does, including emails, image and video generation, LLM calls and workflow steps. Enterprise pricing is quoted and includes the training exclusion, data residency, SSO enforcement and audit logs. Prices and credit allowances read from the pricing page and the vendor's own pricing article on 2026-09-27.
Official links:
Website: https://base44.com/
Application: https://app.base44.com/
Pricing: https://base44.com/pricing
Documentation: https://docs.base44.com/
Product changelog: https://base44.com/changelog
Enterprise page: https://base44.com/enterprise
Security and trust: https://base44.com/security
Terms of Service: https://base44.com/terms-of-service
Privacy Policy: https://base44.com/privacy-policy
Data Processing Addendum: https://base44.com/dpa
Responsible Use Policy: https://base44.com/responsible-use
Community: https://discord.com/invite/ThpYPZpVts
Agent platform fields:
Build inputs: a natural-language description written in the chat, an existing URL to start from, a Figma or GitHub import, a document or screenshot, voice input, and app templates from the community library.
Build outputs: a published web application or website on a platform subdomain or a connected custom domain, an app-store submission path that packages the published app inside a native web view with the downloadable files on the Builder plan and above, an exported code repository, and an installable data model with its own authentication and access rules.
Agent surfaces: AI agents inside an app, with guidelines, tools, connectors, skills and an optional memory store; and the Superagent, which works across the platform's own chat, WhatsApp, Telegram, iMessage, Slack and LINE, and through a browser extension.
Developer path: a JavaScript SDK, a command-line interface, two-way GitHub sync on the Builder plan and above, a documented project structure that can be cloned and run locally, and a backend service that the vendor currently labels beta and free.
Machine access: a Base44 MCP server at app.base44.com/mcp for Builder plan and above, which exposes project creation and editing to an external AI assistant, and an App MCP surface that lets an assistant work with a published app's data and agents.
Access model: browser only. There is no desktop application and no self-hosted deployment of the builder.
At a Glance Dashboard
Field | Value |
Category | No-code application and agent platform |
CI-First Benefit Score | 5.0 / 10 (CI-First Positive) |
Sub-scores | Time 6 / Quantity 6 / Quality 5 / Skill 3 |
CI-First Profile | Primary: Co-Worker and Assistant (level 2). Secondary: Analyst and Tester (level 4) on the security, analytics and search surfaces, and Co-Creator and Thought Partner (level 1) narrowly, on design options |
Collaboration Mode | Centaur (Imposture Risk Medium with Skill Illusion High) |
Humics Protection | Humics-Risky (-2 / +3) |
AI Imposture Risk | Medium overall, with Skill Illusion High |
Status | Active |
Last tested | 2026-09-27 |
Access | Browser application, with a documented SDK, CLI, MCP server and GitHub sync |
Entry price | Free tier, then $16 per month billed annually, or $20 month to month |
Contracting entity | Wix.com Ltd., per the terms of service |
Training position | Excluded on Enterprise; on every other plan workspace data can be used to train AI models, with no opt-out setting |
The Problem
The tools an institution actually needs are small. A tracker for applications, a form that routes a request, a dashboard that shows a placement rate, a page for a cohort. The work is clear and the queue is the problem: nobody in the queue writes code for a living, so a two-day tool waits six weeks, and the person who needed it has usually built a spreadsheet by then that nobody else can maintain.
That gap is real and it is why this category exists. Three specific problems sit inside it, and they are the ones a tool of this class claims to solve.
The first is the cost of the first version. Building a small tool has a fixed cost that does not scale down: someone has to set up a database, decide the authorisation model, build a form, wire an email, and deploy it somewhere with a certificate. The interesting part of the work, which is the process itself, is a small fraction of the effort. Tools that remove the fixed cost change which ideas get built at all, because a two-day tool becomes an afternoon and the answer to "should we build this" stops being a budget question.
The second is the cost of being wrong. Most first versions are wrong in ways only use reveals: the approval step nobody uses, the field that should have been a list, the report that is needed on Fridays. A prototype that can be changed in ten minutes gets corrected twenty times and ends up right. A specification that gets corrected twenty times gets abandoned. This is the strongest argument for the category and it is not a claim about code quality at all.
The third is the one nobody measures, and it is where this review spends its length. A generated application looks finished the moment it renders. Whether the access rules actually hold, whether two people can reach data they should not, whether anything is being sent out without a trace, and whether the person who built it can tell the difference between working software and software that merely runs, are questions the interface does not answer. The person best positioned to benefit from an application builder is usually the person least equipped to evaluate what it produced, and the platform's own marketing does not say so. That gap, between a finished-looking artefact and a finished piece of work, is the risk the framework in this review is designed to make visible.
The Outcome
The concrete outcome is that a person with a clear process and no engineering background can have a working tool on the same day, with a database, a login and an address, and can change it in conversation rather than in a ticket.
What that means in practice, stated as finished work rather than as features. A programme office tracking placements in a spreadsheet has a form, a status field and a weekly view by the afternoon. A team that wants to test a service before committing a term to it puts a real workflow in front of five people and reads what happened, rather than presenting slides and reading opinions. A marketing team ships a campaign page with a working form and a connected domain without touching a build pipeline. A support function turns a written FAQ into an assistant that answers from the written material and hands the unresolved cases to a person.
What a reader does not get, and this is where the honest accounting starts. The design output is serviceable rather than distinctive, so anything where the look is the product stays in a designer's hands. The build is metered in credits that are consumed by iteration, including iteration that repairs what the previous iteration broke, and the monthly allowance expires. The platform holds the backend, so what you own is the code rather than the running system, and the documented export path moves the code and not the database. What a running app does on your behalf is charged per action and is not previewable in advance, so its cost is discovered in the usage page rather than on the pricing page. And on every plan below Enterprise, the vendor's own documentation states that your workspace data can be used to train AI models, with no opt-in and no opt-out to switch.
That combination is what the score reflects: a genuine capability that removes a real bottleneck, with a quality ceiling that nobody independent has measured, a commercial layer that charges iteration, and a data position that a buyer should read before the first upload rather than after.
Who Should Use Base44
Base44 fits a person with a process they can describe and a tool they cannot otherwise get built. It is not a development team and it does not claim to be one.
Strong fit:
An operations or programme team with a spreadsheet that has outgrown itself. This is the product's strongest case and the one its own marketing leads with. The tracker, the roster, the intake form and the dashboard all sit in the same shape: a handful of records, two roles, one approval step and a weekly view. The value is that the tool exists this week, and it is that simple.
A team that needs to test a service before it commits to building one. The prototype is the deliverable and the feedback is about the workflow. Here the platform's speed converts directly into better decisions, because a design can be corrected in ten minutes and a slide deck cannot.
A marketing or communications team publishing campaign pages and microsites. A landing page with a form, a domain and analytics is a standard operation, and having it in the same subscription as the internal tooling is the honest reason to choose this over a separate website product.
A person or team that wants an assistant rather than an application. The Superagent is a different job from the builder, and it is priced the same way. A solo operator who wants an inbox triaged overnight, a weekly summary pulled from connected tools, or a follow-up sent to a new lead within minutes is the reader the assistant is built for, and the platform's own examples are drawn from exactly those tasks.
A team with a developer available for review, but no developer available for building. This is the configuration in which the product scores at its best. The builder produces the first version; the developer reads the access rules, the data model and the exported code and approves them. The pairing converts an afternoon of building into an afternoon of building plus an hour of review, which is a good trade.
Weak fit, stated plainly:
Anything where the interface is the product. The generated design is competent and not distinctive, and the platform's own answer is a design agent rather than a claim of parity with design-first tools. A brand site, a portfolio or a public-facing product page should be built where the visual work can be authored.
Any application that handles money, regulated decisions or personal data without a reviewer. The vendor's own terms state that generated output should not be used in high-risk domains and that the customer is responsible for reviewing all of it before use. A payments page, a scoring tool, a health intake form or anything making a decision about a person is a build that needs a person who can read the code, and without one it is a build the platform does not warn you away from either.
A team that needs to leave with the whole system. The code exports and the terms say you own it. The backend does not: the database, the authentication, the file storage and the integrations stay on the platform's infrastructure, the export path documents the code and not the data, and a deleted app releases its domains, integrations and automations for good. A team whose requirement is a system it can run entirely in its own environment is choosing the wrong class of tool.
An institution whose data cannot be used to train a third party's models. On the published documentation, the training exclusion is Enterprise-only, it is automatic there, and there is no opt-out on any other plan. A reader for whom that single clause is decisive should price Enterprise or walk away, and should not conclude from the security page that the default is safe, because the security page and the support documentation describe different plans in the same breath.
Anyone whose workflow is a local repository and a container. The builder is browser-only. There is a CLI, a local development mode for the backend service and a two-way GitHub sync, and the primary workflow is still the platform's preview loop.
Two honesty conditions on the strong fit. The first is that the cost of iteration is the cost of the tool. A build that goes smoothly is cheap and a build that fights you is not, and the vendor's own documentation states plainly that the credits for an action are computed after the action runs. Budget in currency, measure one real iteration, and treat the published allowance as an opening position rather than a ceiling. The second is that the review step is not optional and is not a feature of the product. Nothing in the interface stops a broken access rule from being published, and the security scan the platform provides is a starting point rather than an approval gate. A named person who reads the access rules before anything user-facing goes live is the condition that makes this adoption a good one.
U365 Fellow categories:
Learner type | Difficulty | Typical ROI | Career path |
Students (Bachelor, Master) | Beginner | A course project, a portfolio tool or a placement tracker exists without a development queue, and the free tier is enough to learn what the platform does. The measurable gain is speed to a working artefact | Technology and business pathways where an internal tool can be described, built and defended; design pathways where a supplied interface is evaluated rather than authored |
Professionals (career upskilling) | Beginner to Intermediate | The strongest return in the review: a process that currently lives in a spreadsheet becomes a tool, and the discipline the platform forces (writing the requirement, naming the reviewer, reading the access rules) transfers to every tool decision afterwards | Operations, programme management, product and marketing roles, plus the commercial literacy of reading a metered supplier contract and a data-processing position before signing |
Everyone (lifelong learners) | Beginner | A low entry point for hands-on exposure to what "no code" actually means: the description is the hard part, the review is the hard part, and the generation is the easy part | General digital literacy, with a specific gain in judging a generated artefact rather than in producing one |
Institute alignment:
UIT (Technology, AI, Data Science): High (primary). A software cohort can stand up a real application, export the code, read the data model and the access rules, and review them as an assessed artefact. The platform also publishes its own security guidance, which makes it a usable case study in what a no-code stack protects and what it leaves to the builder.
UIB (Business Management, Entrepreneurship): High. Idea validation stops being a document and becomes a working tool a customer or an internal user can try. The credit model is itself a teaching object: a variable cost that scales with iteration, on a supplier whose contract position must be read before it is committed to.
UIC (Digital Communication, Marketing): Medium. Campaign pages, microsites and forms with a connected domain are the institute's core operations, and the platform performs them competently. The limit is visual craft: the generated page is a starting point and the writing, the imagery and the brand voice are still the practitioner's.
UID (Digital Design, UX/UI): Low to Medium. The composition is performed by the platform, and what remains for a design cohort is evaluation rather than authorship: putting two generated flows in front of users, judging what survives contact with real use, and naming the point at which a preset design system stops carrying the intent. That is a real reading exercise and it is not a design capability, and the row is stated that way.
Skill level required: Beginner. Writing a description, choosing a plan and publishing require no technical knowledge. Reading the access rules the generated application carries does, and that is the requirement this review keeps returning to.
Prerequisites: A process you can describe in writing, including who may see and change each kind of record. A decision about where the data may live and who may train on it, made before the first upload. And, for anything other than a personal experiment, a named reviewer who can read the generated access rules.
Typical time to first result: Under fifteen minutes for a first working screen. The vendor's own blog puts a first usable app at an afternoon, and its customer story, published on the homepage, describes about a week from idea to an end-to-end product.
Typical time to competence: An afternoon to run the build loop well. Weeks to run the workflow safely, because the competency is not in the tool. Writing a requirement a machine can execute, setting a credit budget and holding to it, and reading an access model are the parts that take practice, and none of them is taught by the interface.
U365 Institutes Alignment
Base44 sits on the build layer of digital work: it turns a described process into an artefact with a database, a login and an address. The alignment below rates what a U365 institute could take from it as a working instrument and as an object of study. The primary home is clear and the three other readings are real.
Institute | Rating | Why | The limit that holds the row |
UIT (Technology, AI, Data Science) | High (primary) | A cohort can stand up a real application, export the code, and review the data model, the access rules and the generated functions as an assessed artefact rather than as a scenario. The platform also publishes what it does and does not protect, which makes it a usable case in reading a security posture: a scan that checks third-party dependencies, insecure patterns, exposed secrets, missing login checks and weak data access rules, and a documented default that site-like apps are public unless the builder changes it. The developer path is real: an SDK, a CLI, a documented project structure, a two-way GitHub sync and a local backend development mode are all published, so a software cohort can work in the same repository the platform does | The tool builds no engineering knowledge by itself. What a cohort assesses is the Fellow's review of a supplied artefact, and reading generated access rules is the competency that has to be taught separately. Where the interface is the product, the platform's design output is competent rather than distinctive, and a design-led project should be built where the visual work can be authored. Nothing here is assessable as modelling: the platform names the model providers in its subprocessor directory and publishes no architecture, parameter count or benchmark of its own |
UIB (Business Management, Entrepreneurship) | High | Two commercial competencies are genuinely exercised and both are costable. The first is idea validation against a working artefact rather than a document: a venture can be put in front of a real user in an afternoon, which changes the quality of the decision rather than the speed of the writing. The second is metered-supplier appraisal: message credits meter the build and integration credits meter what a live app does, the vendor's own documentation states the per-action figures are estimates computed after the action runs, credits expire at the end of each cycle, and the fees are non-cancelable and non-refundable. Converting that into a cost per working release, and defending it against a measured burn rather than against the published allowance, is the appraisal a purchase decision requires | The tool teaches no management, finance or entrepreneurship content of its own. A word-start search over all 79 published programme descriptions in the Online Programs catalogue on 2026-09-27 returned zero matches for metered, usage-based, unit economics, procurement, supplier, rate card, invoice and total cost, so the appraisal is a costed exercise rather than a published discipline. The nearest published anchors are Business Analysis Professional and Financial Analysis Specialist, both of which publish other work. No credential is claimed here |
UIC (Digital Communication, Marketing) | Medium | The institute's core operations are within reach of the platform: a campaign page or microsite with a working form and a connected domain, a landing page with analytics, and an assistant that answers from written material. The judgement a practitioner supplies is real and survives the removal of the tool: the audience case, the message, the register, the imagery and the decision about what a reader is told. The platform performs the assembly competently and the communication decisions remain with the practitioner | The tool supplies no standard, critique or measurement for the copy, the imagery or the brand voice, and its design output is a starting point rather than a finished page. A communication cohort using it for portfolio work should expect to do the visual and editorial work on top of the generated structure, and the platform will not tell them how far the generated version falls short |
UID (Digital Design, UX/UI) | Low to Medium | The competency that survives is evaluation rather than authorship: a design cohort can put two generated flows for one task in front of real users, judge which elements survived contact with use, and name the point at which a preset design system stops carrying the intent. With a design system configured once at workspace level and applied across apps, there is also a real reading exercise in how a constrained system behaves at scale | The platform performs the composition. A design cohort authors no layout, defends no typographic decision and builds no component, and the artefact under assessment is the generator's rather than the Fellow's. The row is rated as evaluation contact with a supplied interface and it is stated that way rather than as a design capability |
U365 methods, not an institute (UNOP, ULM, LIPS, CARE and the UP-Context Method) | Applicable | The methods layer is relevant in one specific way and it is worth naming. This platform creates two things that have to be governed somewhere: a build requirement and a set of permissions. Deciding what the tool may see, what it may change without asking, and who reviews the result before it reaches a user is a standing decision, and it belongs in a written rule rather than in a setting. That rule and its review record belong in LIPS rather than in the platform, and the UP-Context method supplies the boundary the default workflow leaves out | The platform holds the application, the data and the agent's own notes, and it also holds durable instruction the institution did not author: the agent skills and the memory an in-app agent carries, and the notes the assistant keeps and updates. It keeps no register of who approved what, and it writes no standing instruction of the user's own making. A team that does not keep that record elsewhere has no record |
The sentence that holds across all four rows. Base44 removes a build requirement and supplies no standard, critique or measurement for judging what it built. The teaching value is in the judgements the tool makes unavoidable and gives no help with, which is why the primary institute is UIT and why the recommendation to a technology cohort is a real one rather than a courtesy.
Relevance is not a credential, and the two diverge on this tool. A rating says a cohort has something to learn by reading or using the product. A credential says U365 assesses that competency and issues something for it. On this tool the first is true at all four institutes and the second is true at none.
Tool to Skill to Credential
No published U365 credential assesses any of the four competencies this tool exercises. That is the finding, and it is not a catalogue defect. It is a statement about what this class of tool does: it removes a production requirement rather than teaching production, and U365 credentials assess what a Fellow can do rather than what a tool can do for them. The Skill sub-score of 3 records the same thing from the scoring side, and Skill Illusion High records it from the risk side.
Every row therefore does two things. It names the nearest published programme a Fellow could enrol in, and it states what that programme does not publish. An adjacent anchor is useful to a Fellow who wants the neighbouring skill. An adjacent anchor is not a credential claim, and none is presented as an assessment home for the competency in the row.
The programmes below were read from the published Online Programs catalogue on 2026-09-27 (86 records, 79 published), each as a published programme with its own description and module list.
Tool skill | U365 competency | Credential | Institute |
Writing a process description precise enough to be built from: the records, their fields, the roles, the approval step and what each role may not do | Requirement specification and process definition | No published U365 programme assesses application requirement specification. A word-start search over all 79 published programme descriptions returned zero matches for specification, user story and acceptance criteria. The nearest published anchor is Business Analysis Professional (60 days, published), which carries Business Analysis Foundations, Agile Requirements, Business Bebefits Realization, Project Manager Collaboration, Business Process Modeling, Leadership Foundations and Communication skills, with the module spellings reproduced as the catalogue publishes them. That is requirements analysis inside a business-analysis pathway rather than specification of an application build. Adjacent anchor, not an assessment home | UIB (Business Management, Entrepreneurship), no credential mapped |
Reading a generated access model and deciding whether two roles can reach data they should not: the access rules, what is left to the platform's defaults, and what a scan does not catch | Access-model review and permission design | No published U365 programme assesses application access-model review. The term search returned zero matches for row-level, access control and code review, and one for web security inside Software Developer (60 days, published), which carries Fundamentals, Databases, HTML, CSS, Javascript, Python, Java, C#, SQL Programming and Web Security. That is secure-development contact inside a developer pathway rather than review of a supplied access model. The nearest adjacent anchors are Software Developer and Full-Stack Web Developer (60 days, published), which publish application construction rather than the review of one. Adjacent anchors, not assessment homes | UIT (Technology, AI, Data Science), no credential mapped |
Converting a credit-based platform into a cost per working release, including the iterations that repair earlier iterations, and deciding a tier from a measured burn | Usage-based cost appraisal on a metered service | No published U365 programme assesses a metered or usage-based pricing outcome, and it is the same gap recorded for localisation services in this series. The term search returned zero matches for metered, usage-based, unit economics, procurement, supplier, rate card, invoice and total cost. The nearest published anchor is Financial Analysis Specialist (30 days, published), which carries Corporate Financial Statement, Financial Modeling, Forcasting Financial Statements, and Data, and Economic Modeling with Stata, with the module spellings reproduced as the catalogue publishes them, which is the analysis of a company's own statements rather than the appraisal of a supplier's rate card. Adjacent anchor, not an assessment home | UIB (Business Management, Entrepreneurship), no credential mapped |
Deciding what a platform's assistant may send, change and delete under your identity, and writing that boundary down before it acts | Agent delegation boundaries and disclosure rule authorship | No published U365 programme assesses agent delegation boundaries or synthetic-media disclosure. The term search returned zero matches for disclosure, attribution, provenance, watermark and likeness. The nearest published anchor is AI Creator Professional (30 days, published), which carries Opportunities, Issues, and Ethics inside a generative-image pathway, which is ethics contact within image tooling rather than a delegation or disclosure regime. Recorded here as a curriculum gap |
Where relevance is present but uncredentialed, this review says so rather than leaving it silent. Four competencies are mapped above, every one names a verified published anchor and states what that anchor does not publish, and none is presented as an assessment home. Two further competencies this platform exercises, supervising an assistant that keeps its own notes, and running a security review on a supplied application, are recorded as gaps with no adjacent anchor named at all, because naming a plausible programme would assert something the catalogue does not carry. The access levels are stated as the catalogue publishes them. University 365 has three academic access levels, DISCOVERY, INSIDER and SUPERHUMAN. Specialised diplomas and certificates carry Basic, Foundation and Expert levels: DISCOVERY Fellows can enrol in Basic-level programmes only, INSIDER Fellows in Basic and Foundation programmes, and SUPERHUMAN Fellows in all of them. University degree programmes carry a single Expert level and are open to SUPERHUMAN Fellows only. No per-programme access level is asserted, because the catalogue does not expose one, no credit transfer between programmes is asserted, and no micro-credential component title is asserted anywhere in this table. None of the four anchors stacks into a degree, so no degree consequence arises from it.
How Base44 Works
The platform is a browser builder with one account, two credit meters and several surfaces that draw on them at different rates. The published workflow is consistent and it is worth setting out plainly, because the billing and the data behaviour both follow from it.
Step 1. Describe, or start from something. A description goes into the chat, or the build starts from an existing URL, a Figma frame, a GitHub repository or a community template. Plan mode lets the assistant propose a structure before generating it, and the prompt library carries ready-made prompts for common steps such as logins, workflows, payments and polish.
Step 2. The platform builds the stack. A data model, a visual editor, a preview, authentication and hosting arrive together. Manual visual edits, such as dragging elements or changing text directly in the editor, consume no credits; the AI conversation does. Branches let a change be tried without disturbing the published version, comment threads attach feedback to an element and can be sent to the AI chat, and a canvas view shows every page at once.
Step 3. Publish, and decide who can reach it. The app publishes to a platform address or a connected custom domain, and visibility is a separate decision with three documented levels: public without sign-in, private by invitation, or workspace-only. The platform's own documentation states that site-like apps are automatically set to public without requiring login, and that private apps are available on paid plans only. The terms put the responsibility for that decision on the customer in plain language, and the same terms add that default configurations may not suit an intended use.
Step 4. Add an agent, if the app needs one. An in-app agent carries guidelines, a model choice, context files, tools that scope what data it can read or change, OAuth connectors that let app users attach their own accounts, skills that hold reusable instructions, and an optional memory store with a scope choice between per-person and shared. The platform publishes a security scan for every app, which checks third-party dependencies, insecure patterns, exposed secrets, missing login checks and weak data access rules, rates each finding and offers an AI fix.
Step 5. Keep it running, or take it out. A published app runs on the platform's infrastructure, and what it does is metered: an email, an uploaded file, an image, a generated video, an LLM call and a workflow step each carry a published approximate cost. The code can be synchronised to GitHub on the Builder plan and above, cloned locally, run against a local backend, and deployed elsewhere; the database, the authentication and the storage are not part of that movement.
The Superagent, which is a different surface. Alongside the builder, the platform ships an assistant that works outside the application: in the platform's own chat, over WhatsApp, Telegram, iMessage, Slack and LINE, by telephone, and through a Chrome extension that acts inside pages you are already signed in to. It carries its own settings for data updates, deletions, connector rules, memory and access, and the platform documents that a trusted caller can use every tool the agent has and therefore act as you.
Inputs: a written description or a script, an existing URL, a Figma design, a GitHub repository, a document, an image or a screenshot, a voice description, and a target domain. For the assistant: messages from its own chat or a connected channel, files and images, and connected calendar, mail and workspace services.
Outputs: a published web application or website on a platform subdomain or a custom domain, app-store submission files that wrap the published application inside a native web view, a data model with access rules, exported source code, in-app agents with their configuration files, and, on the assistant surface, sent messages, records changed in connected tools, generated documents and notes it keeps for you.
Technology. The platform does not publish its own model architecture, and it names the model suppliers in its subprocessor directory instead: OpenAI and Anthropic for API calls to a language model, Google Cloud for analytics, Mongo for storage, Render for server services, SendGrid for email, Datadog and Langfuse for logging, and Wix.com Ltd. as the group entity. The builder exposes a model choice, and the agent surface prices models relative to an Automatic default, with the strongest named models costing several times more per message than the default. The company acquired the product in June 2025 and reports that it continues to operate as a distinct product; the platform's monthly pricing has held since the acquisition while the credit mechanics have become more granular.
The credit model, stated as the vendor publishes it. Two meters run in parallel and neither rolls over. Message credits meter the build conversation, and the documentation is explicit that there is no fixed amount per message: short focused prompts cost less, broad prompts that touch several pages cost more, and the credits are computed after the action runs. Published ranges are about half a credit for a simple visual or text change, about one credit for a small feature, about two for a complex module and three to four for an app-wide change, and plan mode, which turns a conversation into a structured plan before anything is built, is documented as costing a fraction of a credit per message while the first build that follows it uses about one credit. Integration credits meter what a running app does, at about one credit per email on the default domain and two on a custom domain, about one per file upload, one per generated image, five per second of generated video, about one per fifty characters of speech, about one per LLM call on the automatic setting against about five on a mid-tier model and about fifteen on a frontier model, about one credit per hundred backend function invocations, and about a tenth of a credit per workflow step. The documentation states plainly that there is no way to preview an integration credit cost before running an action, that the figures are estimates, and that credit usage varies by workspace.
Where the data goes, as the published documents describe it. Applications and their data run on the vendor's infrastructure, with subprocessors named in a directory. Data residency can be set for an app's own data to the EU, UK or US on the higher plans, and the same documentation states that media files, account details and billing information remain in the United States regardless of that setting. The privacy policy is issued by Base44, Inc. and describes collection, legal bases, retention and the GDPR and CCPA rights a user holds, and it names no fixed retention period for app data beyond the general statement that information is kept as long as necessary for the purpose it was collected. The terms permit the vendor to use Customer Data and Generated Output to train its own software tools, and the support documentation states the plan-level position that matters most: on Enterprise the exclusion is built in and automatic, on all other plans the data can be used to train AI models, and there is no opt-out setting. Section 7c sets those documents side by side.
Getting Started with Base44
The interface is easy and the setup is not, because the decisions that determine whether the build is safe are made before the first prompt. This is the checklist that makes the difference.
A fifteen-minute checklist:
Write the process before you open the account. Minutes 1 to 4. The one workflow the tool must support end to end, the records it holds, the fields each record needs, the two roles that will touch it, and what each role may not do. If you cannot write those, the platform will invent them and you will not be able to tell whether the invention is good.
Decide the data position and the plan that supports it. Minutes 4 to 7. Read the support documentation on training and the security page together, note that the training exclusion is Enterprise-only and automatic there, note that data residency applies to app data and not to media or billing, and decide which plan that puts you on before any real data is uploaded.
Register and build one small thing on the free tier. Minutes 7 to 10. Twenty-five message credits is enough to see how the conversation behaves and what a generated screen looks like. Use a process whose worst case is a wasted afternoon.
Set the visibility and the access rules deliberately. Minutes 10 to 12. Site-like apps default to public without sign-in, private apps require a paid plan, and the access rules are where a generated app most often fails. Change the default, then read every rule the platform proposed.
Run the security scan and read the findings. Minutes 12 to 14. It checks dependencies, insecure patterns, exposed secrets, missing login checks and data access rules, and it rates each finding. Treat a clean scan as a starting point and not as an approval.
Name the reviewer and set the budget. Minute 15. One named person who reads the access rules and the exported code before anything user-facing is published, and a decision about how many credits an iteration may cost before you stop and change approach.
What to do before you start, if you are doing this on behalf of an institution:
Confirm what the platform will hold. An application built for internal use carries the institution's own data, and the terms state that no specially protected category of data, such as health information or payment card data, may be shared with the platform without a prior written agreement.
Confirm the training position for the plan you are buying, from the support documentation rather than the security page, and record the answer in the procurement file.
Confirm the exit path before the first build. Connect GitHub early, clone the repository once, and see whether it runs. The code leaves; the database, the authentication and the storage do not.
Decide where the build record lives. The platform keeps the application and the data. It does not keep the requirement, the reviewer's name or the decision about what the agent may change on its own. ---
Real Workflows
Three workflows, each one a job U365 actually has. Each carries the prompt pattern to use, the human step that cannot be delegated, and a verification checklist to run before the result is trusted.
Workflow 1: The internal tracker that replaces a spreadsheet
What it is. A programme office tracks applications, placements, partner contacts or equipment in a spreadsheet with two users, one approval step and a weekly report nobody enjoys producing. The goal is a working tool, not a project.
Steps. Upload or describe the current spreadsheet structure so the platform can see the fields you actually use. State the two roles and what each may not do. Ask for the approval step by name and describe what changes when a record is approved. Ask for the weekly view as a saved filter rather than as an email. Publish to a workspace-only visibility unless the users are outside the institution.
Time budget. Two to three hours for the first working version, including the review step and one round of corrections. Revisions after real use are the normal case and should be budgeted.
Sample prompt.
Build an internal tool for a U365 programme office. Records: applications with applicant name, programme, intake date, status, owner, notes. Two roles: an office member who creates and edits records, and a programme lead who approves or rejects them. An application starts as submitted, can move to under review, then to approved or rejected, and only the programme lead may approve. Show a weekly view of everything submitted in the last seven days, grouped by programme. Do not allow a member to delete a record or to change a status to approved. Publish it to workspace members only.Where the human step sits. The access rules. Nothing in the generated output tells you whether the member role can reach the approval action by a crafted request, and the two roles only matter if the rule holds. Read the rules in the exported code, or have somebody who can read them do it, before the second role is given an account.
Connects to: UIT infrastructure practice, and Business Analysis Professional as the nearest published anchor for requirement definition.
VERIFICATION CHECKLIST for Workflow 1:
☐ Multi-Model Check: run the requirement paragraph through a second assistant and compare the field list and the role rules it produces with the ones the platform built. Differences usually mark a rule you stated loosely.
☐ External Source: check the generated app against the spreadsheet it replaces, record by record, and confirm nothing was dropped in the move.
☐ Human Review: somebody who can read the generated access rules signs off before the second role is created, and somebody who owns the process signs off before the tool is announced.
☐ CI-First Test: can the office explain which record states exist, who may move a record between them, and where each rule is enforced, without opening the platform?
Workflow 2: A working prototype for a service nobody has tested yet
What it is. A programme or service design needs to be tested before a term is committed to it. The deliverable is not a document, it is something a handful of people can use for a week so the feedback is about the workflow rather than about the slides.
Steps. Write the workflow as a sequence of steps a user takes, not as a list of features. Ask for it to be labelled as a draft in the interface. Ask explicitly for no collection of personal data during the trial, which removes a whole data-protection question from a short experiment. Build the smallest version that reaches the end of the workflow. Publish it to the testers by invitation, and stop collecting on a date you set before the test begins.
Time budget. One afternoon to build and one week to run. The build is the cheap part and the debrief is the part that produces the value.
Sample prompt.
Prototype a workflow for a new U365 intake process, for a week-long test with five internal users. The workflow: a user starts an enquiry, answers four questions about what they want to study, sees a summary of what they answered, and submits it for review. Show a visible banner on every page saying this is a prototype and not a live service. Collect no personal data at all: use a made-up reference code instead of a name, and store nothing that identifies a person. Give me a list of the five testers' submissions at the end of the week.Where the human step sits. Reading the results. The tool builds the instrument and the instrument does not interpret anything. The debrief is the deliverable and the platform has no view on it.
Connects to: UIB programme validation practice, and the CARE cycle as the review discipline that governs what a prototype result is allowed to become.
VERIFICATION CHECKLIST for Workflow 2:
☐ Multi-Model Check: ask a second assistant to list the ways a test with five users could mislead you, and check the prototype does not itself create one of them.
☐ External Source: confirm with the people who own the current process that the prototype reflects the process as it actually runs, not as it is documented.
☐ Human Review: somebody who was not involved in building the prototype reads the results and states what the evidence does and does not support.
☐ CI-First Test: can you state what would have to be true in the results for the process to be wrong, and point to where in the results you would see it?
Workflow 3: A published page that collects something, and the review that has to happen first
What it is. A landing page, an intake form or a microsite for a cohort, an event or a campaign. It captures data, and something has to happen to that data. This is the workflow that carries the real risk, because it publishes.
Steps. Write the audience and the message, and state which institution name appears on the page. Build the page and the form, then decide the data question before publishing: what is collected, where it is stored, who can see it, and how long it is kept. Set the visibility deliberately, because the documented default for a site-like app is public without login. Test the submission path with a real submission and confirm the record arrives, the email sends and a human is notified. Run the security scan and read every finding.
Time budget. Two hours for a first version and an hour for the review, which is the step that turns a generated page into a published one.
Sample prompt.
Build a landing page for a U365 INSIDE lecture series with a registration form. The audience is professionals in France considering a part-time programme, the copy is in English, and the institution name on the page is University 365. The form collects name, email, country and one free-text question about what they want to learn. After submission: send a confirmation email to the person, notify one named address, and store the record so only me and one colleague can read it. Do not publish anything to search engines until I say so. Show me the access rule for who can read the submitted records before you publish.Where the human step sits. Two places, and neither is optional. The submission path, which has to be tested with a real submission rather than assumed, and the data decision, which is not a build decision. A page that collects personal data from prospective Fellows is a decision about the institution's data position, and the platform's own terms state that specially protected categories of data may not be shared with it without a prior written agreement.
Connects to: UIC campaign delivery practice, and the published Online Programs catalogue page for the programme the page refers to.
VERIFICATION CHECKLIST for Workflow 3:
☐ Multi-Model Check: have a second assistant read the published copy for claims the institution cannot support, and compare its list against yours.
☐ External Source: submit the form yourself from a different device and confirm the record, the email and the notification all arrive, then delete the test record.
☐ Human Review: the person accountable for the cohort reads the page before it is announced, and the person who owns the data position confirms what may be collected.
☐ CI-First Test: can you explain, without the platform open, what personal data this page collects, where it goes, who may read it and how it is deleted?
The verification rule that covers all three
The pattern is the same in each workflow and it is worth stating once, because it is the whole of this review's practical advice. Write the requirement before the first prompt, because the quality of the output tracks the clarity of the description more than anything else about the tool. Read the access rules before a second role, a real user or a published page exists, because that is the step the platform does not take and the one a scan cannot take for you. And keep the record of what was built, who reviewed it and what the platform is permitted to do somewhere you control, because the platform keeps the application and not the reasoning.
Strengths, Limits, and AI Imposture Risk
Strengths
The path from a description to a running application is complete, and that is the reason to use it. Front end, back end, database, authentication and hosting arrive together, and the vendor's own claim is that nothing has to be wired up first. Independent hands-on assessments of the product converge on the same point: a working application, with real data behind it, in an afternoon.
The free tier builds real apps rather than previews. Twenty-five message credits and a hundred integration credits a month, on a permanent tier rather than a trial, with a five-app cap and every core feature included. A reader can establish whether the generation suits them before any commitment.
There is a genuine route out of pure no-code. An SDK, a command-line interface, a documented project structure, a local backend development mode and a two-way GitHub sync on the Builder plan and above. The code can be cloned and run locally, and the vendor documents a migration path onto the platform rather than only off it.
The platform publishes its own limits, in the places where buyers look. The credits documentation states that the published figures are estimates, that no per-action cost can be previewed before it runs, and that credit usage is the source of truth. The security documentation states the plan-level training position, the token-storage answer and the limits of what the platform handles. A vendor that documents the boundaries of its own product is a better source than one that does not.
The security surface a builder is given is more than the category usually supplies. A per-app scan covering dependencies, insecure patterns, exposed secrets, missing login checks and weak data access rules, with severity ratings and an AI fix, plus access-rule recommendations as you build, workspace roles, optional two-factor authentication and enterprise-level controls including SSO enforcement, audit logs and per-member credit limits.
Design consistency is handled at workspace level. A design system configured once and applied across apps, plus a component library that rebuilds supplied components to match the app's theme. For an institution building several internal tools, one visual convention is a real benefit and it is delivered by configuration rather than by discipline.
Limits
No independent measurement of generated-app quality exists, and this is the finding that caps the score. There is no benchmark, no completion study and no third-party engineering assessment of how far an unaided build gets before a human must take over, or how often a finished app survives real use. What exists is editorial hands-on testing by publishers with affiliate arrangements, a panel of builders, and the vendor's own scan. A quality claim without a measurement is not a quality benefit.
The commercial layer charges iteration, and iteration is where the money goes. Credits are consumed by the AI conversation rather than by manual edits, the vendor states that a prompt which looks small can cost several credits because the system has to read the existing app and change it safely, the per-action figures are published as estimates computed after the fact, and the monthly allowance expires. Extra credits exist as promotional grants, gift cards and plan upgrades rather than as a published top-up with a stated unit price, so a project that outgrows its tier has a limited set of options and no published unit cost for any of them.
The fees are non-cancelable and non-refundable, and a chargeback is treated as a breach. The terms state that the fees are non-refundable, that renewal is automatic unless switched off, that a chargeback may disable or terminate the account and that the vendor will dispute it with the transaction records as evidence. Credits are separately stated to be non-refundable and to have no cash value, and credits consumed on output that does not meet expectations are not restored.
The licence over what you build and upload is broad, and one clause is broader than most in the category. The terms grant a perpetual, irrevocable, worldwide, royalty-free, fully paid, sub-licensable licence over Customer Data and Generated Output for the purpose of providing and improving the platform, including training the vendor's software tools, and a separate clause permits the vendor to use any version of your data in its own marketing and promotional activities without payment. Section 7c quotes both.
The training exclusion is Enterprise-only, and there is no opt-out below it. The support documentation states that on Enterprise the exclusion is automatic and that on all other plans workspace data can be used to train AI models, and it adds that there is no setting to find or switch on. The security page, read alone, gives the opposite impression, because it presents the exclusion as a data control without naming the plan it belongs to.
The platform holds the backend, so what you own is the code rather than the running system. Two-way GitHub sync moves source code, and the documentation states that after connecting GitHub you cannot revert to versions from before the connection because those versions are not in the repository. A deleted app releases its domains, integrations and automations and restoring it does not bring them back, and the data itself is not part of the export path.
The default for a site-like app is public without sign-in, and the terms put the responsibility on the builder. The documentation states the smart default, states that login is a separate setting, and the terms state that the customer is solely responsible for reviewing and configuring security settings, access controls and permissions, including settings that by default permit public access, and that default configurations may not be suitable for an intended use.
The authentication detail is documented and it is unusual. The platform's own security documentation states that authentication tokens are stored in the browser's local storage and that HttpOnly cookie storage is not currently available. That is disclosed, which is to the vendor's credit, and it is a design decision a security reviewer should see before an app holds anything worth protecting.
The assistant can act under your identity. The Slack user connector is documented as working through your own Slack account, replying using your name, and the browser extension is documented as working in the sites you are already signed in to. A trusted caller on the phone surface can use every tool the agent has, which the documentation says means they can act as you.
The design ceiling is real. Independent assessments place the generated visual quality below the design-first tools in the class, and the vendor's own answer is a design agent rather than a claim of parity. Where the interface is the product, this is the wrong tool.
The browser is the only builder. There is no desktop application and no self-hosted edition of the builder, and the developer path runs through the platform's repository connection. A team whose workflow is a local repository and a container will find the preview loop is where they work rather than where they check their work.
AI Imposture Risk
Trap | Rating | Evidence |
Time Illusion | Medium | The first version is genuinely fast: a described process becomes a working screen in minutes and a usable internal tool in an afternoon, which is a saving that no reasonable reader would dispute. The illusion sits in what follows. Iteration is charged, and the vendor's own documentation states that a prompt which looks like a quick tweak can still cost several credits because the system has to read the whole app and change it safely. Credits are computed after the action, no per-action cost can be previewed, the monthly allowance expires, and no published unit price exists for extra credits. A build that fights you therefore costs both the hours and the allowance, and the interface gives no warning in either currency. First-version savings are large; time and money to a finished application are materially longer than the first screen suggests |
Quantity Illusion | Medium | The platform makes it trivially easy to produce more surfaces than anybody will look after: another page, another app, another agent, another form. The specific mechanism is that every extra artefact carries its own access rules, its own data and its own review obligation, and none of that appears as a cost in the interface. An institution that ships five internal tools in a month has five sets of permissions to maintain, and the platform's scan tells nobody which of them is still correct six months later. The volume is real and the review capacity it implies has not grown with it, which is the Quantity Illusion in its ordinary form |
Skill Illusion | High | Two mechanisms, both documented. First, the product is sold on removing the requirement: the pitch is that you do not touch a server, wire a payment provider or configure a database, and no teaching surface, critique or measurement is supplied for the judgement the platform substitutes for. Second, and more specific, a generated application looks finished to the person who cannot read it. The interface presents a working screen, the security scan presents a clean report, and neither tells the builder whether the access rules hold, whether the data model is sound or whether the code would survive a review. The platform's own terms state that generated output should be treated as a mere suggestion, that the customer is responsible for reviewing all of it, and that it should not be used in high-risk domains, and those sentences sit in a document almost nobody reads. A builder with engineering judgement can see what arrived; a builder without it holds a published application, and a security report, and no way to tell whether either means what it appears to mean |
Overall AI Imposture Risk: Medium, with Skill Illusion High. Two traps are Medium and one is High, which the framework places at Medium overall because the Time and Quantity traps carry mitigations the user controls, while the Skill trap is created by the product's own design and is not resolved by it.
Framework v1.2 clause note
Three clauses of the CI-First framework, version 1.2, were assessed against this tool. Two return a null and one applies, and each outcome is recorded with its reasoning, because a null is a finding and a null reached without checking is worthless.
Clause 5.2.3-a, agent-authored procedural memory, with a Skill Illusion floor of no lower than Medium: APPLIES, and the Skill Illusion is recorded High. This clause governs a tool that creates or revises the user's skills, memory stores or standing instructions and reuses them in later sessions. The platform does so on two documented surfaces. The first is the agent layer inside an app: agent skills are reusable instructions that the agent selects, loads on demand and follows in later conversations, they can be created by describing what you want, they can be shared across a workspace, and an agent's memory stores facts across conversations with a scope chosen between per-person and shared. The second is the assistant surface: the Superagent keeps notes in a shared space, organises them by topic, links them to each other, updates them as it learns about your work, and draws on them in later sessions, and the platform documents that it can manage its own settings when asked. The clause's own conditions decide the level. The artefact is durable and reused. The revisions happen during use without a per-write human decision: nothing in the documented workflow asks the user to approve a note the assistant has written or a skill it has selected, and the memory writes happen as the work proceeds. And the third condition, whether the user has a routine practice of reading what was written, is met in the negative by design, because the notes are the agent's working state rather than a document the platform presents for review. That puts the clause at its High threshold, and the High Skill Illusion rating in this review rests on this mechanism alongside the two user-facing grounds given above. The operative consequence for a U365 reader is that a project accumulates written capability that nobody wrote, and the review step for that capability is a reading habit rather than a setting.
Clause 4.2-a, agent-mediated conversation: APPLIES on its first condition. Social Authenticity is rated -1. The clause states that agent-mediated conversation is not erosion by itself, that it measures the human's own communicative capability rather than the composition of the channel, and that erosion requires either agent-authored text presented as the person's own voice in a human-facing channel, or the substitution of agent interaction for human contact. The first condition is met, and the vendor's own documentation is the evidence. The Slack user connector is described as the setup to use when you want the agent to work through your Slack account, able to work with messages sent to you and to reply using your name. The assistant is connectable to WhatsApp, Telegram, iMessage, Slack and LINE, and it can be given goals and automations that send messages to other people. The browser extension is documented as acting in the sites you are already signed in to, while you watch what it is doing. Text composed by an agent and sent from your account, to recipients who have no way of knowing it was not you, is the clause's first condition almost exactly. Condition (b) is not met, because the product does not substitute agent interaction for human contact in the common case: it acts inside channels the user already has, and the user still talks to people. That is why the rating is -1 rather than a more severe reading, and it is why the Social Authenticity rating rests on this clause and is recorded with the mechanism rather than as an impression. A configuration that keeps the assistant inside the platform's own chat and away from connected messaging accounts does not touch this dimension at all.
Clause 7.5, team-level rooms: returns a null, and the reasoning is the interesting part. The clause governs a room shared by several named agents and the human, requires a profile attributed to each agent individually, requires Centaur as the default, and makes Cyborg unavailable for a room with more than one agent. The platform does run several agents in one place, and the distinction the clause turns on is the one the task states: a room where several named agents and a human share a channel, against one orchestrator running sub-agents inside a single execution. The Superagent's sub-agents are the second case. The documentation describes the assistant splitting a request into independent tasks that run in parallel, combining their work into a single response, and keeping any work already finished when you press stop. The human has no per-agent channel, the sub-agents are not persistent named participants and they do not address each other. A workspace where several people each run their own Superagent, and a Slack channel where several teams' assistants are invited by handle, come closer to the clause and still are not it: several people's assistants in one channel with several humans is a multi-party configuration the clause does not reach, because each assistant serves its own owner and each owner retains their own boundary. So clause 7.5 returns a null with its mechanism stated. The clause would apply if the platform exposed named persistent agents that a human and other agents could each address in a shared operational room, and that is the change to re-check for. ---
Section 7c: The licence over what you build, the training position, and the contract behind the promise, stated plainly
Four of the vendor's own documents decide whether a commercial deployment is safe, and each one is quotable. This section quotes the operative text, keeps allegation and finding distinct, changes no score, and states what the section does not do.
What you own, quoted from the terms. The position on the application itself is clear and better than the category's average. Terms section 5.3 states: "as between the Company and the Customer, to the extent such rights exist under applicable law, the Customer owns all rights, title and interest in the code and applications generated by the Platform ('Generated Output') resulting from prompts or Customer Data which Customer or Users on its behalf share with the Platform." A later clause in the same section adds: "As between you (or your Users) and Company, Company does not claim any ownership rights in the Generated Output to the extent that the Generated Output does not contain any pre-existing intellectual property owned by Company." Read alone, that is a strong position and it is the reason this platform is adoptable for institutional work at all.
What you grant, quoted from the same document. The licence sits one section earlier and it is considerably broader than the ownership sentence suggests. Terms section 4.2 states that the customer grants the vendor and its service providers "an irrevocable, non-exclusive, worldwide, royalty-free, perpetual, fully paid, sub-licensable right and license including to access, use, modify, translate, process, copy, download, store, distribute, display, upload, reproduce, adapt, perform, improve, enhance, disclose to third parties, publish and prepare derivative works of the Customer Data and the Generated Output, for the purpose of maintaining, providing and improving the Platform," and the same sentence lists what that includes: enforcement of the vendor's rights, compliance with legal process, storage in third-party cloud services and content networks, display adjustments, and, as item five, to "train Company software tools (e.g. artificial intelligence and machine learning models)." A separate paragraph headed Customer's Reference then states: "Customer hereby allows Company to use in perpetuity, worldwide and free of charge, any version of Customer Data (or any part thereof) for any of Company's marketing and promotional activities, online and/or offline," and the customer waives moral rights claims in relation to those uses.
Read the two together and the position resolves into something a buyer can act on. You own the code. You also grant a perpetual, irrevocable, sub-licensable licence over the same data and output, including for model training, and you permit the vendor to use any version of your material in its own marketing without payment. Ownership and licence are different things, and this review separates them because vendors blur them. An institution that puts client work, internal process documentation or learner data into the platform grants both.
The training position, and why the two documents a buyer is most likely to read do not carry it. The security page presents training as a data control: "Control where your data lives, who can access it and whether it trains AI models," with a Training data opt-out marked Enterprise. The support documentation states the position without the euphemism: "Whether Base44 can use your workspace data to train AI models depends on your plan. Enterprise: your data is not used to train AI models. The exclusion is built in and applies automatically as soon as your workspace is on Enterprise. All other plans: your data can be used to train AI models." It then adds, in an explicit note, "There is no opt-out setting to find or switch on. On Enterprise the exclusion is automatic and needs no action from you."
The consequence is specific and it belongs in a procurement file rather than in a footnote. On every plan below Enterprise, the platform's own documentation states that workspace data can be used to train AI models, including, as the same page puts it, "personal information that people submit through your app's forms," and the buyer has no setting to change. Against that, the data processing addendum takes the narrower position a business buyer expects: subprocessors "shall not process Personal Data, except for processing on an aggregated or anonymized basis, for any purpose other than providing the Services," with a seven-day objection window on new subprocessors and an annual audit right. All three statements are the vendor's own, and the plan you buy decides which of them governs your data.
The retention and residency position. The privacy policy, issued by Base44, Inc., states that information is retained "for as long as it is necessary based on the purpose it was collected for," and sets out the rights a user holds. The security documentation states the residency position precisely, including its limits: data residency applies to an app's own data and users, it "controls where your data is stored, not where it is processed," is rolling out gradually, and "media files uploaded to your app, your Base44 account details, and billing information remains stored in the US regardless of this setting." A media or learner-facing application in the European Union therefore needs that sentence read before the settings page is believed.
The money clauses, quoted. Terms section 10.1 states that "unless otherwise required by applicable law, the Fees are non-cancelable and non-refundable," and that a chargeback "will be considered as a breach of your payment obligations hereunder," that the account "may be blocked without the option to re-purchase or re-use it," and that the vendor "reserve our right to dispute any Chargeback received." Section 10.4 takes the same position on the usage meters and is unusually direct about what it covers: "You acknowledge that AI Credits may be consumed even when the Platform or any Generated Output does not meet your expectations or intended use, and/or when it contains errors, inaccuracies, omissions, bugs, hallucinations, interruptions or failures. Credits consumed in these circumstances will not be restored, re-credited, or refunded." The same section states that unused credits do not roll over, that they "automatically expire" at the end of each period, and that credits "are not money, deposits, stored value, or financial instruments; have no cash or monetary value; and are non-refundable." Section 11.2 states that a subscription renews automatically unless switched off, that the renewal is charged "with or without prior notice of the renewal," and that renewals are at the then-current price excluding any prior promotional discount.
This is a decision to make before purchase rather than a scandal, and the review states it that way. A reader can switch off auto-renewal, can read usage against the allowances, and can start on a monthly rather than an annual plan. What the clauses do not offer is recovery: a build that burns its allowance without producing usable work is a cost, and the contract says so in advance.
The liability and dispute position. Clause 13 of the terms excludes consequential and indirect damages and caps the vendor's aggregate liability at the greater of the fees paid in the twelve months before the claim or one hundred US dollars, and it names errors, inaccuracies and hallucinations in generated output among the excluded heads. Clause 15 of the terms requires individual arbitration under JAMS rules with a class-action waiver and a thirty-day opt-out window, and the governing law is New York with disputes heard in New York City.
What the vendor documents about its own security posture, and the one item a reviewer should weigh. The security page states SOC 2 Type II and ISO 27001 certification, AES-256 encryption at rest and TLS 1.2 in transit, a 24/7 security operation, a bug bounty programme, penetration testing, a named subprocessor directory and a disaster recovery commitment available to Enterprise customers under a service level agreement. The support documentation then states two things a security reviewer will want to see before an app holds anything worth protecting: "Base44 stores authentication tokens in the browser's localStorage. HttpOnly cookie storage is not currently available," and the app visibility default that a site-like application is public without sign-in unless the builder changes it. Both are disclosed, which is to the vendor's credit, and both are design decisions a builder should see before publishing.
A documented finding about the platform's security history, stated as a third-party report rather than as this review's assessment. In July 2025, security researchers at Wiz published a critical authentication-bypass finding on the platform: undocumented registration and email-verification endpoints accepted a non-secret application identifier alone, so an attacker could create a verified account on a private application, bypassing the platform's authentication controls including single sign-on. The researchers reported the issue to the vendor and to its parent company on 9 July 2025, the fix was verified on 10 July 2025, and the parent company stated that it found no evidence that the vulnerability had been exploited. The finding is recorded here because an institutional reviewer should know it happened, because the disclosure process and the fix timeline speak in the vendor's favour, and because the report's own generalisation applies to this whole category: applications built on a shared platform inherit the platform's security posture, which is why the review recommends the per-app scan and a named reviewer rather than trusting the platform layer alone. No score in this review changed because of this finding.
No score changed, and why. The CI-First Benefit Score measures benefit to the human net of overhead, and the Humics Protection Badge measures effect on three human capabilities. Neither is a supplier-conduct or contracting dimension, and this framework has no such dimension by design. The findings in this section belong in the adoption decision, in the negotiation and in the procurement file. They do not belong in the arithmetic.
What this section does not do. It does not give legal advice, and it does not assert that any clause is unlawful, unfair or unenforceable. Terms of this shape are common in the category. It does not resolve the training position, because resolving it means choosing a plan rather than reading a page. It quotes the vendor's documents against each other, names each finding with the surface it came from, states the decision each one puts in front of a reader, and stops there.
U365 Co-Intelligence Rating
CI-First Profile
Primary profile: Co-Worker and Assistant (level 2). The tool performs an execution task: it builds the application from a description and you direct and review it. You supply the requirement, the roles and the acceptance, and you accept, reject or correct the result. That is delegation with review, which the framework places at level 2.
Secondary profiles: Analyst and Tester (level 4), on the security scan, the analytics surface and the workspace search and monitoring surfaces, which surface problems the builder did not ask about: an exposed secret, a missing login check, a weak data access rule, a usage pattern. Co-Creator and Thought Partner (level 1), narrowly, on the design-options surface where the platform proposes alternatives and the user chooses between them.
Why level 2 and not level 1 as the primary. Level 1 would mean the human and the tool build on each other's thinking across the work. Base44 does not work that way: the direction is supplied by the user and the platform constructs. The design-options surface comes closest to co-creation and it is a proposal step inside a longer build rather than the working relationship.
What does not fit. Challenger and Devil's Advocate (level 5) does not apply. Nothing in the platform argues against your requirement, your data model or your decision to publish. The nearest thing it does is ask a clarifying question during plan mode, which is scoping rather than challenge. Coach and Tutor (level 3) does not apply either: the generated code is visible and a motivated learner can study it, and teaching is not a designed behaviour of the product. The security scan is the one surface that behaves like a reviewer, and it reviews the artefact rather than the reasoning.
Collaboration Mode
Recommended mode: Centaur.
Alternative mode: None recommended. Cyborg is not available here.
Mode rationale. Two independent grounds, and both belong on the record. Framework Section 7.2 assigns Centaur whenever the Imposture Risk is Medium or High, which it is here, because the overall risk is Medium with Skill Illusion High. The second ground is specific to this tool. Cyborg requires a tight interaction loop in which the human applies a stopping criterion inside the iteration, and this platform's build loop is deliberately coarse: the assistant reads the existing application, plans the change and applies it, and the human's decision point is the review of the result rather than a decision inside the loop. The controls that make the Centaur boundary real are therefore procedural rather than interactive. Write the requirement as a specification before the first prompt. Set a credit budget and treat it as a stopping criterion. Read the access rules before a second role exists. Publish nothing user-facing until a named person who can read the generated code has approved it. Keep the requirement, the reviewer's name and the permissions record where the institution keeps its decisions rather than in the platform. The division of labour is the whole point: you own the requirement and the acceptance, the platform owns the construction.
CI-First Benefit Score
Dimension | Score (0-10) | Rationale |
Time | 6 | Moderate savings, and they are structural rather than claimed. A described internal tool becomes a working application in an afternoon, a campaign page with a form and a domain exists without a build pipeline, and a revision happens in conversation rather than in a ticket. The score is 6 rather than higher because the overhead is real and documented: the AI conversation is the metered part, manual edits are not, the per-action credit figures are published as estimates computed after the action runs, no per-action cost can be previewed before it runs, the monthly allowance expires, and the review step that makes the output publishable is work the platform does not do for you. First-version savings are large and time to a finished, reviewed application is materially longer than the first working screen suggests |
Quantity | 6 | A genuine step change in the number of tools and pages a small team can produce in a month. One description becomes an application with a data model, a login and an address; the same subscription covers websites, microapps and an outbound assistant. Held at 6 rather than higher because the framework scores verified usable quantity, and the marginal unit is not free: every added app carries its own access rules and its own review, every iteration is charged, and nothing measures whether the additional volume was any good |
Quality | 5 | Moderate on the deterministic layer and unmeasured on the generated one, which is why the score lands mid-band rather than lower. The infrastructure a build inherits is genuinely solid: managed database, authentication, hosting, encryption, a security scan with severity ratings, and workspace-level design consistency. The generated application itself has no independent measurement of quality anywhere: editorial hands-on assessments converge on a working first version and diverge on what happens under real use, the design output is placed below the design-first tools, and the platform's own terms state that output "should not be used in high-risk domains" and that generated output "may also violate third party rights." Where the vendor publishes operational detail it is precise, and where it publishes a quality claim there is no measurement behind it |
Skill | 3 | Marginal, and scored conservatively on the evidence below. Two real learning surfaces exist: writing a requirement precise enough to build from, and reading an access model well enough to decide who may reach what. The score is 3 because the product's purpose is to remove the requirement rather than to teach it, no standard, critique or measurement is supplied for the judgement it substitutes for, the security scan reports findings rather than teaching review, and the durable artefacts the platform writes on the user's behalf, its agents' skills and its assistant's notes, are capability the user holds and did not author. A reader gains vocabulary, a working tool and a faster first version, and does not gain the ability to tell a correct application from one that merely runs |
CI-First Benefit Score: (6 + 6 + 5 + 3) / 4 = 5.0 / 10 (CI-First Positive)
Why this score is not higher, and why it is not lower
Why it is not higher. The step from Positive to Strong requires evidence that what the tool produces is good, and no such evidence exists: no benchmark, no completion study, no third-party engineering assessment of a generated application, from the vendor or from anyone else. The platform's own terms disclaim the accuracy, completeness, quality and intellectual-property position of generated output and advise against high-risk domains. The commercial layer charges iteration, computes the charge after the action, publishes no unit price for extra credits, and states that consumed credits are not restored. And the access model, which is what makes a small tool safe, is left to a builder who by definition cannot read it. A score above 6 would assert a quality and safety position the evidence does not support.
Why it is not lower. The capability is genuine and the arithmetic is honest. A person with a clear process and no engineering background gets a working tool the same day, with a database, a login and an address, and the free tier is enough to learn whether the generation suits them. The training-path, developer-path and export positions are published rather than hidden, the security scan is a real quality floor for this class, and the ownership position on generated code is stated in writing in the vendor's terms. On the framework's honest-user and common-case basis, and comparing against the queue an internal tool otherwise faces, that is a real recommendation with conditions attached, which is what the CI-First Positive band means.
Humics Protection Badge
Dimension | Rating | Rationale |
Creativity | 0 | Neutral. The platform can serve creative decisions: putting a process in front of real users surfaces what the process should be, and design options can widen a set of choices the builder had not considered. It can also replace the decision entirely, because accepting the first generated interface means no layout, no component and no interaction choice was ever made. The two effects balance, so the rating is neutral rather than protecting. The design ceiling belongs in the limits rather than in this rating |
Critical Thinking | -1 | Erodes, and the mechanism is specific to generated software. The output arrives looking finished, and the person best placed to benefit from the tool is the person least equipped to judge it: the security scan presents a clean report, the preview presents a working screen, and neither says whether the access rules hold or whether the data model is sound. The platform's disclaimers place the entire review obligation on the customer, in a document almost nobody reads, and the cost model rewards accepting the first working version rather than paying to redo it. The mitigation is cheap and available, which is why this is -1 rather than a more severe reading: read the access rules, run the scan, and put a named reviewer between the build and the user |
Social Authenticity | -1 | Erodes, and this rests on framework clause 4.2-a condition (a) rather than on the category. The platform's assistant can send messages from the user's own Slack account and reply using their name, act inside sites the user is already signed in to, and run automations that message other people, all documented. Text composed by software and sent under a person's name, to recipients with no way to know it was not them, is agent-authored text presented as the person's own voice in a human-facing channel, which is the clause's first condition. Condition (b) is not met, because the tool acts inside the user's existing human channels rather than substituting agent interaction for human contact, and a configuration that keeps the assistant inside the platform's own chat does not touch this dimension. The rating is -1 because the connected-channel configuration is a documented and promoted use, not an edge case |
Humics Protection Badge: Humics-Risky (-2 / +3)
Superhuman Usage Guidance
When to invite the tool:
Building an internal tool or dashboard from a process you can describe, with a named reviewer available for the access rules before a second person gets an account.
Producing a working prototype so that feedback is about the workflow rather than about a mockup, and running the prototype on data that identifies nobody.
Publishing a campaign page, a landing page or a microsite with a form, where the copy and the imagery remain yours and the assembly is the platform's.
Adding an agent inside an internal application, with its tools and connectors scoped to the data it actually needs.
Running a personal assistant for your own workload on work that is yours to delegate, in the platform's own chat, with the connected messaging accounts left off until you have written the rule about what it may send in your name.
The developer pairing: a builder who cannot read the code plus a reviewer who can, working on the same repository.
When to keep the tool out:
Anything payment-handling, or making or supporting an automated decision about a person, without a person who can read the code in the loop. The vendor's own terms advise against high-risk domains and the platform does not enforce the advice.
Any application holding learner, patient, financial or otherwise specially protected personal data, on any plan below Enterprise, unless the training position in Section 7c has been accepted in writing by the institution.
Client or third-party material you are not willing to license perpetually, worldwide and for model training, or to see used in the vendor's own promotional material.
A brand site, a portfolio or any page where the design is the product, until the design has been authored elsewhere.
Any build whose deadline assumes a first attempt succeeds and a fixed credit allowance covers the iteration.
Connected-channel messaging under your own name, until a written rule exists about what the assistant may send, to whom, and whether the recipient is told.
U365 method integration:
LIPS and CARE: the build record belongs in LIPS rather than in the platform. The requirement, the access-rule decision, the reviewer's name and the disclosure rule for the assistant's messages are the assets the institution keeps, and the platform keeps only the application. In the CARE cycle the platform supports Collect and Execute, and it should never be allowed to make the Review decision on your behalf, which is exactly what happens when a working preview is treated as accepted work.
UP-Context: the boundary this workflow needs is the one the default workflow omits. Write the build rule before the first prompt: what may be built, what data may go in, who reviews the access rules, what the assistant may send, and who signs off before publication. The prompt packs in Verdict and Next Steps turn that into working briefs.
ULM: primarily Career and Finance, and Quality of Life. The tool removes a recurring build burden and a queue, which is a Career and Finance question, and it returns time and removes a dependency on somebody else's schedule, which is a Quality of Life question. Character and Emotions is touched in one specific way: declining to publish an application whose access rules nobody has read is a discipline rather than a setting. Weak fit for Body and Health, Spirit and Mind, and Social and Love Relationships.
My Successful Life: put the review step on the cadence the team already runs on, and attach it to the moment a build is published rather than to a calendar date. The trigger to watch is publication, because that is the point at which a generated application becomes somebody else's problem, and in most teams it is the step with no name against it. ---
What Users Say
The platform is rated on five public surfaces, and the two that carry real volume answer differently on purpose. Averaging them would erase the reason they differ, so this review does not.
Aggregate Rating Table
Platform | Rating | Volume | What the cohort is rating |
Trustpilot | 2.8 out of 5 | 890 reviews | Paying customers, and the complaints are about money and reliability: credits consumed by repeated attempts, credits that cannot be used without changing plan, cancellation, and support reachability. The profile carries a paid-subscription badge and a note that the company has not invited reviews recently |
Product Hunt | 4.4 out of 5 | 41 reviews | Makers and early adopters rating the build experience. The praise is speed and the all-in-one setup; the recorded cons are thin documentation, support and credit limits |
G2 | 3.8 out of 5 | 4 reviews | A very thin base. The distribution is bimodal rather than clustered, with most of the sample at five stars and the rest at one |
Capterra | 3.3 out of 5 | 3 reviews | Thin as well, and the visible complaint is about billing and about features not delivering what the marketing implies |
Agent Verdict | 806 out of 1,000, A tier | 63 votes | A panel that built the same brief on several tools in this class. The recorded strengths are time to a working internal tool and the pre-wired stack; the weakness it names is code ownership and the narrow exits from the opinionated stack |
The spread is the finding. The same product holds 4.4 where people rate the build experience and 2.8 where they rate what they were charged and what happened when a build went wrong. That divergence is not noise: it is one product with a working core and a commercial layer that generates complaints, and both are real. The vendor's own documentation explains the mechanism without disputing it.
What Users Praise
Time to something that works. The most consistent praise across surfaces is that a described application exists quickly. The panel assessment records an inventory tool built end to end, including authentication and a notification, in about eleven minutes on the same brief where other tools in the class took longer, and Product Hunt reviewers repeatedly describe turning a prompt into a working app, dashboard or landing page on the first attempt.
The stack being wired already. Reviewers name the backend capabilities rather than the front end: a database, logins and APIs that exist without creating service accounts elsewhere. This is the same reason this review's Strengths section leads with completeness, and the praise is usually framed as not having to be technical to get there.
Publishing rather than prototyping. Users describe shipping an application and putting it in front of real people the same week. The store path is worth stating precisely because it is often described loosely: the mobile application is the published web application running inside a lightweight native wrapper, with content and design changes appearing without a new store submission, and the files needed for submission are generated from the editor on the Builder plan or above.
Design that looks acceptable without work. Reviewers who are not designers report that the generated interface is presentable without styling, which is consistent with the design limitation this review records: good enough by default, not distinctive.
Support, where it worked. Positive reviews that mention support describe it as responsive, and the vendor has replied to a large share of the negative reviews on Trustpilot, which is worth separating from the rating itself.
What Users Complain About
Credits consumed by attempts that fail or repeat. This is the single most consistent complaint in the corpus, and it matches the vendor's own documentation: credits are charged when the AI action runs, they are computed after the fact, there is no cost preview, and credits consumed on output that missed the mark are not restored. Reviewers describe the same feature being rebuilt several times, which is the iteration cost the contract states in advance.
The price ladder and the way it is presented. The monthly figures are roughly twenty-five percent above the annual ones, and reviews regularly quote the annual figure as the price. The plan that most builders outgrow is the first paid tier, and the jump to the next one that removes the main limitations is a factor of two and a half.
The gap between preview and production. Complaints cluster around generated applications that work in the preview and then behave unexpectedly under real use: layout regressions after an edit, features that do not survive the mobile build, and the discovery that a workflow needs logic the platform does not express.
Lock-in, stated in the reviewers' own terms. The exit is real for the code and narrower for everything else. Reviewers describe moving the repository out and still needing the platform for the database, the authentication and the integrations, and the documentation supports that reading: the export path carries source code, and a deleted app releases its domains, integrations and automations for good.
Support reachability. Where the complaint is not about credits it is about support: wait times, first responses that do not resolve the issue, and the sense that the answer arrives after the billing cycle has turned.
Documentation depth. Reviewers repeatedly describe the documentation as thin for anything beyond the basic build, and the platform has since published a full documentation set that covers substantially more, which is a change a reader should check against the date of the review they are reading.
Sentiment Summary
The pattern across all five surfaces is consistent once the cohorts are separated. People who built something that ran, and who had a specific small job in mind, are satisfied and rate it well. People who hit the credit meter while a build misbehaved rate it poorly and rate the money rather than the generation. Nobody in the corpus describes an engineering review of what was produced, and no public assessment measures whether a generated application is correct, which is exactly the evidence this review would most like to have and cannot find.
U365 Editorial Note
This review is written for the reader deciding whether to let a platform build institutional software, and the public record above points at the decision rather than settling it. The praise and the complaints are not in conflict: they describe a product whose first version is genuinely fast and whose iteration is genuinely expensive, with the expensive part arriving exactly when the build is not going well. The practical consequence is that the honest cost of this platform is a cost per working and reviewed release rather than a cost per plan, and a reader who measures that number on one real build before choosing a tier will not be surprised later. Where the sentiment record and this evaluation agree, the finding is strong and it is the same one on both sides: the platform does the building competently and supplies no judgement about whether what it built is fit to use.
Comparison and Alternatives
Five alternatives, each with the case for choosing it over Base44 and the case against. Every figure in the public-record column is the platform's own published rating and count, read on 2026-09-27, and it is included for one reason: in this category the public rating tracks the billing model as much as the product.
Tool | What it is | Public record, 2026-09-27 | Choose it over Base44 if | Stay with Base44 if |
Lovable | An AI application builder that generates a React and TypeScript codebase, configures an external database and syncs to a repository on every plan including the free one | Trustpilot 4.1 across roughly 1,700 reviews | You want the code and the database to be yours in a form you can hand to a developer and continue with somewhere else without a plan gate. Its repository sync and its external database configuration are the reason independent comparisons reach for it first when portability is the criterion | You want the stack wired for you, including authentication, payments and hosting, without creating accounts on other services, and you want an outbound assistant in the same subscription |
Bolt.new | A browser-based generator that produces a first screen extremely fast and is designed to hand the code onward | Trustpilot 1.4 across roughly 170 reviews | You want the fastest possible first version and you intend to finish the work somewhere else. It is the closest thing in this set to a pure prototyping instrument | You need the application to keep running, authenticated and connected, after the prototype is accepted, and you want an internal tool rather than a first draft |
Replit | A cloud development environment with an agent that builds and hosts applications inside it | Trustpilot 2.8 across roughly 1,500 reviews | You are a developer, or you have one, and you want an environment as well as a generator: a visible workspace, a real deployment model and a language and framework choice that is not constrained | You are not a developer and you want the description to be the interface. Replit's strength is the workspace, and the workspace is exactly what a non-technical builder does not want to meet |
Emergent | An agentic application builder that plans, generates, tests and deploys from a description, with a code export to a repository you control | Trustpilot 2.9 across roughly 620 reviews | You want an agent team that tests what it built, and you want the same shape as Base44 with a different balance of integrations, so that two quotes can be compared before committing | You want the website surface and the outbound assistant in the same subscription, the free tier that builds real apps without a card, and a workspace design system applied across several tools |
A developer, or a low-code platform with a licence | The conventional alternative: someone builds it, or a licensed platform hosts it under your own arrangement | Not applicable | The application touches money, personal data, regulated decisions or anybody's rights, or the institution needs the data to stay inside its own environment and its own contracts. This is the option the review's own Skill Illusion finding points at, and it remains the right answer where the question is whether the output is correct rather than whether it is cheap | The work is an internal tool, a prototype or a page, the data position in Section 7c has been accepted, and a reviewer is available for the access rules. A first pass on the platform with a named review step is a defensible pattern, and it is what the workflows describe |
What none of these alternatives changes. Every tool in this comparison shares the same two missing things: none of them publishes an independent measurement of what it produces, and none of them supplies the review step by default. Choosing between them is choosing a billing model, an exit path and a design ceiling, not choosing whether the review obligation exists. In this category the public rating is a better guide to the billing model than to the product, which is why this section carries more decision weight than a rating table usually should.
Verdict and Next Steps
Verdict: adopt it for internal tools, prototypes and pages, with a named reviewer on the access rules, and keep nothing regulated, payment-handling or learner-identifying in it until the data position is settled in writing.
Base44 scores 5.0 out of 10, which is CI-First Positive. That is a real recommendation rather than a consolation. A person with a clear process and no engineering background gets a working application the same day, with a database, a login and an address; the same subscription covers websites and an outbound assistant; the security scan gives a builder more than this class usually supplies; and the vendor publishes its own limits, its own subprocessors and the ownership position in writing. On the framework's honest-user and common-case basis, comparing against the queue an internal tool otherwise faces, that is worth adopting.
It is not scored higher for reasons that are specific rather than general. No independent measurement of generated-application quality exists anywhere, and the platform's own terms disclaim the accuracy, completeness and intellectual-property position of what it produces and advise against high-risk domains. The commercial layer charges iteration, computes the charge after the action, publishes its per-action figures as estimates, offers no cost preview and no published unit price for extra credits, and states that consumed credits are not restored. The access model, which is what makes a small tool safe, is left to a builder who may not be able to read it. And the contract carries a perpetual licence over your data and output including for model training, a separate permission to use your material in the vendor's own marketing, a training exclusion that applies only on Enterprise, and fees that are non-cancelable and non-refundable.
Next steps, in order.
Settle the data position before the first upload. Read the support documentation on model training and the data processing addendum together, decide whether the plan you are buying is the plan your data requires, and record the answer where the institution keeps its procurement decisions.
Write the requirement as a specification, and set a credit budget before generating. One workflow, the records and their fields, the two roles and what each may not do. Then treat the budget as a stopping criterion rather than a meter to watch, because credit consumption is calculated after the action runs.
Read the access rules before a second person gets an account. Change the visibility default, read every rule the platform proposed, and have somebody who can read the generated code confirm them. This is the step the platform does not take and the scan cannot take for you.
Connect the repository on day one and test the exit. Clone it, run it, and see whether it works outside the platform. The code leaves; the database, authentication and storage do not, and knowing that early changes what you are willing to build.
Put the review on the calendar as a named step. A build that reaches a user without a named reviewer is the failure mode this review spends its length on, and the platform will not flag it.
Re-check this review against the triggers at the top, and specifically when an independent measurement of generated-application quality appears, when the training position changes on the plans most readers buy, or when the licence over uploaded and generated material moves in either direction.
U.Copilot Integration
U.Copilot is the front door to the U365 tool library, available at https://www.university-365.com/ucopilot. Use it before you open the builder, because the requirement and the boundary are the parts of this workflow the platform cannot write for you and the parts that decide whether the build is safe to publish.
What to ask U.Copilot to do. Describe the process, the two roles and the data, and ask it to write the build rule before any prompt is written: what may be built on this platform, what data may go into it and what may not, who reviews the access rules, what the assistant may send under your name, and who signs off before publication. Ask it to turn the process into a specification with the records, the fields, the roles and the approval step. Ask it to design the review step, naming what the reviewer must check and what evidence a release needs. And ask it to place the build record, the consent position and the reviewer's name in your LIPS Digital Second Brain, so the decision sits with the application it governs.
U.Copilot prompt example.
Design a CI-First workflow for building [tool or page] on Base44 for [team or cohort]. Write the build rule first: what may be built on this platform, what data may be entered and what is excluded, who reviews the generated access rules before a second person gets an account, what the assistant may send in my name, and who signs off before publication. Then produce the requirement as a specification with the records, fields, roles and approval step. Then produce the reviewer's checklist, naming the evidence a release needs. Calculate the plan and the credit budget from a measured cost per working release rather than from the published allowance, and state which tier that implies. Connect the build rule, the reviewer's name and the permissions decision to my LIPS Digital Second Brain under [project], and tell me which parts of this workflow I must do myself.
SL-OS Integration
LIPS Digital Second Brain: the build rule, the requirement, the access-rule decision, the reviewer's name and the assistant's messaging rule belong in your LIPS under the project. The platform holds the application, its data and the assistant's own notes; LIPS holds the reasoning, which is what you need when a permission is questioned, a build is audited or an assistant's message is challenged.
ULM routines: primarily Career and Finance, and Quality of Life. The tool removes a build queue and a recurring dependency on somebody else's schedule, which is a Career and Finance question, and it returns the time the queue was consuming, which is a Quality of Life question. Character and Emotions is touched in one way: declining to publish an application whose access rules nobody has read is a discipline rather than a setting. Weak fit for Body and Health, Spirit and Mind, and Social and Love Relationships.
My Successful Life: put the review step on the cadence the team already runs on, and attach it to the moment a build is published rather than to a calendar date. The trigger to watch is publication, because that is the point at which a generated application starts holding somebody else's data, and in most teams it is the step with nobody's name against it.
UP-Context prompt packs
Three prompts, one per decision this workflow forces: the build rule written before the first prompt, the access review that has to happen before a second person gets an account, and the cost and data check before a tier is chosen. Each closes with the verification line, and each states where the record belongs, because this platform writes no standing instruction of the user's own making.
Prompt pack 1: The build rule, written before the first prompt
Context: The process is [describe the workflow]. The users are [roles and how many]. The data is [what will be recorded, and whether it identifies anyone]. The platform is Base44 on the [tier] plan. The institutional constraints are [what may not leave our environment, what may not be collected, who must approve]. The decision I have already made is [what is settled]. Role: AI as a build-rule author working to a written boundary. Profile: Act as a Co-Creator and Thought Partner. I own the rule and the final judgement; you test it against the risks. Task: Write the build rule for this project: what may be built on this platform, what data may be entered and what is excluded, who reviews the generated access rules before a second person gets an account, what the assistant may send in my name and to whom, and the one named person who signs off before publication. Then name every case the rule does not settle and say plainly which of them must be decided before the first prompt. Constraints: Never assert a legal or regulatory position as settled; where a market or a data category has a rule, tell me to verify it at source. Never write a rule that a reviewer cannot apply, because a rule nobody can run is not a rule. Distinguish between owning an artefact and licensing it, because the platform separates them. Output format: The rule as a numbered list, a table of data category, permitted or excluded, and the reason, the unresolved-cases list, and the human decision required before the first prompt. Memory: this platform writes no standing instruction of my own making, and its agents write their own. The approved rule belongs in my own project record and in my LIPS record. UP-Context verification: I read the rule back against the process before the first prompt, and I check that every data category in the table has a decision. I read the unresolved-cases list myself and settle each one in writing rather than leaving it to the build. Data safety: this pack carries no personal data. I do not paste a real applicant's record, a learner's details or a client's material into it, and I keep the build rule, the reviewer's name and the data decision in my own record rather than in the platform.Prompt pack 2: The access review, before a second person gets an account
Context: The application is [describe], built on Base44. The roles are [role A and what it may do, role B and what it may do]. The records it holds are [list]. The visibility setting is [public, private or workspace] and [whether login is required]. The reviewer is [name or role]. Role: AI as an access-model reviewer working to a written standard. Profile: Act as an Analyst and Tester, applying my standard rather than inventing one. Task: Produce the checklist the reviewer runs, in order: which records each role can reach read and write, which actions exist that a role should not be able to reach, where the platform's defaults are doing the enforcement rather than an explicit rule, what the app's own security scan reported and what it does not cover, and what would have to be true for a record to be visible to the wrong person. Then state what the reviewer must be able to read in the exported code, and say plainly where my own sign-off would not be sufficient. Constraints: Never tell me an application is safe without naming what was checked. Do not treat a clean scan as an approval, because it checks patterns and not intent. Use the platform's own documented limits, including that authentication tokens are stored in the browser and that private apps require a paid plan. Output format: A numbered reviewer checklist, the role-by-record permission table, the list of rules that rest on a platform default rather than an explicit rule, and one sentence on what I may and may not approve myself. Memory: the reviewer's name and the review outcome belong in my own project record and in the LIPS record, not in the platform. UP-Context verification: I walk the checklist myself on the first build before any later one, and I confirm the reviewer is a person who can read the generated access rules and not a pass over the interface. I name the rules I could not assess and I do not give a second person an account while they are unresolved. Data safety: this pack carries no personal data. I do not paste a live dataset, a signed consent record or another person's records into it, and I keep the access-rule decision and the reviewer's name with the release record rather than in the platform.Prompt pack 3: The cost and data check before choosing a tier
Context: I intend to build [describe] on Base44 for [team and users]. The plan I am considering is [tier] at [price] with [message credits and integration credits]. The build I have already measured cost [credits and hours] and the working release took [number] iterations. The data is [categories, including any personal data]. The intended use is [purpose], published to [audience], and [may or may not] be wrapped into a service we sell. Role: AI as a cost and data reviewer for a commercial decision. Profile: Act as an Analyst and Tester. I supply the measured numbers and the contract position; you apply them and flag what is unresolved. Task: For this workload, state what the terms grant the vendor over what I upload and what it generates, whether the training exclusion applies on the plan I am considering and what governs on the plans below it, what the measured cost per working release implies about the tier I should buy, how iteration and failed attempts change that number, and what the exit path actually moves. Then list every question the published record does not settle and the one that must be answered in writing before anything is uploaded. Constraints: Do not give legal advice and do not assert that any party acted improperly. Where the pricing page, the credits documentation and the terms describe the same arrangement differently, say which governs and say that they differ. Use my measured number rather than any advertised allowance, and treat the published per-action figures as the estimates the vendor says they are. Output format: A governing-document line, a licence line, a training line, a tier-coverage line, a measured cost per working release, an exit-path line, an unresolved-questions list, and the human decision required before upload. Memory: this platform writes no standing instruction of my own making; the approved position and the measured cost belong in my own working file and in the LIPS record. UP-Context verification: I read the terms and the credits documentation myself rather than accepting your summary, I confirm the training position on the plan I am buying from the vendor's own support documentation, and I record the answer where the institution keeps its procurement decisions. Data safety: this pack carries no personal data. I do not paste a contract, an invoice, a client name or a signed order into it, and I keep the contract position and the measured cost per working release in my own store.Status and Last Tested
Status: Active | Last tested: 2026-09-27 (Base44, as its product, pricing, documentation and legal pages described it on that date) | Re-check: trigger-based (max 6 months)
Active: the tool is current and recommended.
The re-check triggers listed at the top of this review are the conditions under which the assessment should be revisited. The most consequential of them is the second, because the training position is plan-dependent and the exclusion is automatic only on Enterprise: any change to it, in either direction, would move the adoption advice for the plans most readers actually buy. The third and fourth matter for a commercial deployment rather than for a course exercise, and both are the kind of clause that changes quietly.
Not applicable to this tool, stated rather than left silent. The clause note in Strengths, Limits, and AI Imposture Risk records what the framework's three v1.2 clauses return, and what each outcome means, including the two that apply. Where a reader expected a null, the reasoning is given rather than the outcome alone.
Migration Path
Not applicable. Base44 is Active. No Migration Path section is required for an Active tool, and none is included.
For completeness, the exit path that exists and that a U365 reader should treat as part of the adoption rather than as a contingency: the source code synchronises to a GitHub repository you control on the Builder plan and above, with a documented two-way workflow, and the vendor's terms state that you own the generated code. The exported stack is conventional, so the code itself moves. The three things that do not travel are the managed backend, which is the database, the authentication and the file storage; the assistant's own notes and the agents' memory, which live on the platform; and the credit balance, which expires at the end of each cycle and has no cash value. A reader planning an exit should therefore make it early and test it, which is the fourth item in the next-steps list above and the fourth item on the Getting Started checklist for an institutional build.
U365's Recommendations to Learn More
Official learning resources
The documentation home, which is the starting point for the whole help set and is substantially deeper than its reputation: https://docs.base44.com/
The quick start guide, for the first build and the editor: https://docs.base44.com/Getting-Started/Quick-start-guide
The prompt guide and the prompt library, which are the two documents that most change what a first build produces: https://docs.base44.com/Getting-Started/Prompt-guide and https://docs.base44.com/Getting-Started/Prompt-library
The credits documentation, for what each action costs, the statement that the figures are estimates, and the no-preview rule: https://docs.base44.com/Account-and-billing/Credits
The privacy and security page, for the plan-level training position, the data residency limits and the token-storage answer: https://docs.base44.com/Community-and-support/Privacy-and-security
The security overview, for the app security model, the visibility options and the per-app scan: https://docs.base44.com/Setting-up-your-app/security-overview
Managing access, for the visibility levels, roles and invitations: https://docs.base44.com/Setting-up-your-app/Managing-access
Setting up an AI agent, for guidelines, tools, connectors, skills and memory: https://docs.base44.com/Building-your-app/AI-agents-for-apps
The Superagent pages, for the assistant's channels, security settings, workflows and sub-agents: https://docs.base44.com/superagents/creating-a-superagent and https://docs.base44.com/superagents/customizing-your-superagent
The Base44 MCP server, which exposes project creation and editing to an external assistant: https://docs.base44.com/developers/backend/overview/mcp-server
The GitHub integration guide, which documents the sync, the local setup and the recovery behaviour: https://docs.base44.com/developers/app-code/local-development/github
The pricing page, read next to the credits documentation because the first states the allowance and the second explains what consumes it: https://base44.com/pricing
The vendor's own pricing article, which is the clearest statement of the annual and monthly figures in one table: https://base44.com/blog/how-much-does-base44-cost
The terms of service, and specifically sections 4.2 and 5.3 on the licence you grant and the ownership you keep, section 10.4 on AI credits and the plan limits, section 11.2 on renewal and section 13 on liability, all quoted in Section 7c: https://base44.com/terms-of-service
The privacy policy, issued by Base44, Inc., for the collection, retention and rights position: https://base44.com/privacy-policy
The data processing addendum, for the subprocessor rules, the objection window and the audit right: https://base44.com/dpa
The Responsible Use Policy, which sets the restrictions that apply to what you build with it: https://base44.com/responsible-use
The security and trust page, for the certifications, the encryption position and the subprocessor directory: https://base44.com/security
The enterprise page, for the governance controls an institutional buyer will be asked about: https://base44.com/enterprise
The product changelog, which is unusually detailed and is the fastest way to see what shipped this month: https://base44.com/changelog
Video tutorials and channels
Two third-party walkthroughs are listed below. Both are third-party material rather than vendor material, and both are listed for how the build loop is organised rather than for how the output performs on your process.
A hands-on review and tutorial that builds a working application on screen and shows the editor, the publishing step and the pricing: https://www.youtube.com/watch?v=_WPnF5ZdpZ0
A builder's assessment after maintaining several applications, which is worth watching for where the platform's limits appear in practice rather than in a demo: https://www.youtube.com/watch?v=l3HuOWJCC8o
Base44 Review + Base44 Tutorial - How to Build No-Code Apps in 2026 by Cybernews (Published Jun 9, 2026, 43:54)
Is Base44 Worth It? Base44 Review and Tutorial by George Vlasyev (Published May 7, 2026, 8:24)
Watch both for how the interface is organised and how a build is steered, not for how it will behave on your own requirement. Neither is a vendor-produced film, and neither substitutes for building one small real thing on the free tier.
Written tutorials and deep-dive articles
An independent hands-on assessment that built several applications and reports the editor, the publishing path, the pricing tiers and the security certifications: https://tech.co/ai/vibe-coding/base44-review
An independent test that built a small application, a web application and a marketplace-style site, and reports where the generated output needed work: https://cybernews.com/ai-tools/base44-review
A research-based assessment by a competing platform that states its own conflict and is precise about the managed-backend limitation and the export scope: https://www.jetadmin.io/blog/base44-review
An assessment of what changed after the acquisition, with the contractual changes and the pricing shifts dated to their sources: https://www.base44devs.com/blog/base44-after-wix-acquisition-what-changed
A panel assessment that builds the same brief on several tools in this class and records the per-axis scores, including code ownership as the weakest axis: https://www.agent-verdict.com/tool/base44
The 2025 security research write-up on the authentication-bypass finding, which is the document behind the security history recorded in Section 7c: https://www.wiz.io/blog/critical-vulnerability-base44
Community and social
Dedicated Base44 channels
The vendor's Discord community, linked from the documentation home, where build questions and credit-model discussion are most concentrated: https://discord.com/invite/ThpYPZpVts
The vendor's YouTube channel, which carries product walkthroughs and release videos: https://www.youtube.com/@base44
The vendor's X account, whose own description reads "Create fully-functional apps in minutes. If you can describe it, you can build it.": https://x.com/Base44
The builder partner network, documented as a route to hiring help, which is worth knowing before a build that needs more than the platform can express: https://docs.base44.com/Getting-Started/Hiring-a-partner
The public feedback board, where feature requests and the roadmap conversation live: https://feedback.base44.com/
The Trustpilot profile, where the billing complaints are concentrated and where the vendor has replied to a large share of them: https://www.trustpilot.com/review/base44.com
The Product Hunt page, where each release line has launched and where the review cluster with the highest average for this product sits: https://www.producthunt.com/products/base44
Resources on Base44
Resources on X
The vendor's own account is the first channel to add, because a change to the credit rules, the training position or the licence over your content would be announced there before it reached a documentation page. Verified 2026-09-27: the account is @Base44, linked from the vendor's own site footer, with the description quoted above. For this category the accounts worth following alongside it are the practitioner and analyst accounts that publish comparative work, and the competitor accounts named in the comparison section above, so that any capability claim in this review can be checked against a measurement rather than against a marketing page.
Dedicated X channels
CI-First Evaluation Summary Card
Field | Value |
Tool | Base44 (Wix.com Ltd.) |
Category | No-code application and agent platform |
Version reviewed | Base44, as documented at base44.com in September 2026 |
Status | Active |
Last tested | 2026-09-27 |
CI-First Profile | Primary: Co-Worker and Assistant (level 2). Secondary: Analyst and Tester (level 4) on the security, analytics and search surfaces, Co-Creator and Thought Partner (level 1) narrowly on design options |
Collaboration Mode | Centaur (Imposture Risk Medium with Skill Illusion High; the build loop runs across minutes with the human's decision point at the review of the result rather than inside the iteration, so there is no stopping criterion for Cyborg to apply) |
CI-First Benefit Score | 5.0 / 10 (CI-First Positive) |
Time | 6, moderate savings on first-version work, reduced by per-iteration credit charging computed after the action, expiring allowances and no cost preview |
Quantity | 6, a real step change in the number of tools, pages and agent surfaces a small team can produce, held down because every added surface carries its own access rules and no measurement exists of whether the volume was good |
Quality | 5, solid and inherited on the infrastructure layer, unmeasured on the generated layer, with the vendor's own terms advising against high-risk domains |
Skill | 3, a real learning surface in requirement writing and access-rule review, and no standard, critique or measurement supplied for the judgement the platform substitutes for |
Humics Protection Badge | Humics-Risky (-2 / +3) |
Creativity | 0 Neutral: design options can widen a set of choices and the first generated interface can replace the decision entirely |
Critical Thinking | -1 Erodes: output arrives looking finished, the scan presents a clean report, the review obligation sits in a document few read, and the cost model rewards accepting the first working version |
Social Authenticity | -1 Erodes under clause 4.2-a condition (a): the assistant can send messages from your own Slack account using your name and act in sessions you are signed in to, while a configuration that keeps it inside the platform's own chat leaves the dimension untouched |
AI Imposture Risk | Medium overall |
Time Illusion | Medium: first versions are genuinely fast, iteration is charged after the fact with no preview and no published unit price, and the allowance expires |
Quantity Illusion | Medium: surfaces, apps and agents are cheap to produce, every one carries its own permissions and review obligation, and nothing measures whether the volume was good |
Skill Illusion | High: the product is sold on removing the requirement with no teaching, critique or measurement supplied, and a generated application looks finished to the person least able to read it |
Clause 5.2.3-a | APPLIES. Agents inside an app carry skills and memory, and the assistant keeps its own notes and can manage its own settings. The artefacts outlive the task, the revisions happen during use with no per-write decision, and nothing presents them for review. Skill Illusion is recorded High |
Clause 4.2-a | APPLIES on condition (a). The assistant is documented as replying through your own Slack account using your name and acting in sessions you are signed in to, which is agent-authored text presented as your own voice in a human-facing channel. Condition (b) is not met, which is why the rating is -1 rather than more severe |
Clause 7.5 | Null. The assistant's sub-agents run inside one orchestrator's execution with no per-agent channel and no persistent named agents, so there is no room of named agents. Centaur is derived from framework 7.2 and from the tool's own coarse loop rather than from this clause |
Section 7c findings | You own the generated code, and you grant a perpetual, irrevocable, worldwide, sub-licensable licence over Customer Data and Generated Output including for model training, plus permission to use any version of your material in the vendor's own marketing; the training exclusion is automatic on Enterprise and absent below it with no opt-out; fees are non-cancelable and non-refundable and a chargeback is treated as a breach; credits expire and consumed credits are not restored; data residency covers app data and not media, account or billing data. No score changed |
Superhuman usage | Invite for internal tools, prototypes, pages and forms, an in-app agent scoped to the data it needs, and the developer pairing of a builder plus a reviewer. Keep out for payment handling and decisions about people without a reviewer, specially protected personal data below Enterprise, client material you will not license perpetually, and connected-channel messaging under your name before a written rule exists |
Over-delegation warning | The failure mode is a set of published applications nobody can read, holding data whose permissions nobody decided, with a clean security report standing in for a review. If you cannot name the person who read the access rules on the last tool you shipped, and say where the permission decision is written down, the platform has your signature and you are no longer signing anything |
Verification checklists | Per workflow, in Real Workflows: multi-model check, external source, human review, CI-First test |
U365 methods | LIPS holds the build rule, the requirement, the reviewer's name and the assistant's messaging rule, not the platform. ULM: primarily Career and Finance, and Quality of Life, with Character and Emotions touched through the standing decision about what may be published unread. UP-Context writes the requirement and the review step. SL-OS: the build review as a recurring intake, decision record in OneNote or SharePoint. UNOP: moderate and conditional, because a generated tool supplements a learning workflow rather than replacing the material a Fellow is learning |
Re-check triggers | An independent measurement of generated-app quality; a change to the training position on the non-Enterprise plans; a change to the licence over uploaded and generated material, including the marketing-use clause; a change to the refund, renewal or chargeback terms or a published credit unit price; a change to the default app visibility or the authentication answer; a change to the surfaces where the assistant acts under your identity; a certification change or a material security incident; a change to the credit mechanics such as roll-over or cost preview |
Glossary
CI-First
Co-Intelligence First. The U365 principle that the question is not whether to use AI, but whether using it leaves you more capable than working without it. Every score in this review is an attempt to answer that question for this tool, net of the time, judgment and oversight the tool requires.
CI-First Benefit Score
The average of four dimensions, each scored 0 to 10: Time, Quantity, Quality, and Knowledge and Skill. It answers whether using the tool makes Co-Intelligence more profitable than Human Intelligence alone. Bands: 0 to 2.0 CI-First Negative, 2.1 to 4.0 CI-First Neutral, 4.1 to 6.0 CI-First Positive, 6.1 to 8.0 CI-First Strong, 8.1 to 10.0 CI-First Transformative. The score accounts for the overhead of prompting, supervising and verifying, not just the benefit the tool produces. Base44 scores 5.0.
Time Benefit
How much time the tool saves against doing the same work alone, net of prompting, configuring, reading and correcting. For Base44 this is 6: a described internal tool becomes a working application in an afternoon, and the metered iteration, the expiring allowance and the review step return part of the saving.
Quantity Benefit
How much more usable output you produce in the same time. Base44 is 6: one description becomes an application, a website, a form and an agent surface, and every added surface carries its own permissions and its own review.
Quality Benefit
Whether the output is better than you would produce alone, verified and durable. Base44 is 5: the infrastructure a build inherits is solid and the generated application itself has no independent measurement on any surface, which caps the score at the middle of the range rather than below it.
Knowledge and Skill Benefit
Whether the tool builds lasting capability in you, or substitutes for it. Base44 is 3: writing a requirement precise enough to build from and reading an access model are real disciplines, and the platform supplies no standard, critique or measurement for the judgement it replaces.
CI-First Profile
The role the AI plays in your working relationship. (level 1) Co-Creator and Thought Partner, (level 2) Co-Worker and Assistant, (level 3) Coach and Tutor, (level 4) Analyst and Tester, (level 5) Challenger and Devil's Advocate. Assigning a profile before giving the AI a task is a core CI-First discipline. Base44 is primarily a Co-Worker and Assistant (level 2), with Analyst and Tester (level 4) on the security and analytics surfaces and Co-Creator and Thought Partner (level 1) narrowly on design options.
Collaboration Mode
How the work is divided between you and the AI. Centaur is a clear division of labour: you hold the requirement and the acceptance and the AI holds the construction, and you review before anything is used. Cyborg is continuous rapid iteration inside one piece of work, with no clear boundary about who did what, and it requires a stopping criterion you apply yourself. Base44 is Centaur, because the Imposture Risk is Medium with Skill Illusion High and because the build loop runs across minutes with the human's decision point at the review of the result rather than inside the iteration.
Humics
The three human capabilities Pascal Bornet's Humics framework identifies as the ones AI can either strengthen or erode: Creativity, Critical Thinking, and Social Authenticity. The question this review applies is whether sustained use makes you stronger or contributes to AI Obesity.
Humics Protection Badge
A rating of whether a tool protects, leaves neutral, or erodes those three capabilities. Each is scored +1, 0, or -1, and the sum gives the badge. +2 to +3 is Humics-Friendly, -1 to +1 is Humics-Neutral, -2 to -3 is Humics-Risky. Base44 is Humics-Risky at -2 / +3: Creativity neutral, Critical Thinking eroded, Social Authenticity eroded.
AI Imposture Risk
The likelihood that a tool traps you in one of three illusions. The Time Illusion is the appearance of saving time when net time is lost. The Quantity Illusion is high volume that looks good but does not survive inspection. The Skill Illusion is the appearance of competence in you while the underlying skill is absent or eroding. Each trap is rated Low, Medium, or High with cited evidence. Base44 is Medium overall, with Skill Illusion High, Time Illusion Medium and Quantity Illusion Medium.
Centaur
The collaboration mode in which you and the AI hold clearly separated roles: you set the requirement, define the boundary and review the output, and the AI performs the construction. Base44's Centaur boundary is procedural rather than technical: write the requirement as a specification, set a credit budget, read the access rules before a second person gets an account, and keep the requirement and the reviewer's name outside the platform.
Agent-authored procedural memory
Standing instructions, skills or memory stores that an AI system writes on a user's behalf and then reuses in later sessions, as distinct from text the human authored. It is a Skill Illusion vector in its own right under framework clause 5.2.3-a, because the user holds a documented capability they did not write, and the artefact outlives the task that produced it. Clause 5.2.3-a sets Skill Illusion at no lower than Medium for any tool that writes such memory, and at High where the agent can revise it during use with no per-write human decision. Base44 applies on two surfaces, the skills and memory an in-app agent carries and the notes the assistant keeps and updates, and the Skill Illusion is recorded High.
Metered build platform
The commercial mechanism this review spends its length on. Two meters run in parallel and neither rolls over: message credits meter the build conversation and integration credits meter what a running application does. Credits are computed after an action runs, no per-action cost can be previewed, the published figures are the vendor's own estimates, the allowance expires at the end of each cycle, and the contract states that credits consumed on output that missed the mark are not restored. The practical consequence is that the published allowance describes attempts rather than finished work.
User Sentiment
The aggregated public opinion from review platforms, community forums and directories. It is reported separately from the CI-First score because crowd sentiment can contradict a rigorous evaluation. Where the two agree, the finding is stronger. Where they diverge, the divergence is worth explaining. For Base44 the two surfaces carrying volume answer differently on purpose: 4.4 on Product Hunt across 41 reviews from people rating the build experience, and 2.8 on Trustpilot across 890 reviews from paying customers rating the billing and reliability relationship. Averaging them would erase the reason they differ, so this review does not.
Review Status
Review Status records the current standing of the tool at the time of the last test. Active: the tool is current and recommended. Active (updated): recently re-checked and the content was refreshed. Changed: a re-check trigger fired and an update is pending, so read the review with that in mind. Risky: the tool has significant unresolved issues, or it has been clearly surpassed by newer alternatives. Use it with caution and read the Limits section. Stale: this review has not been re-checked in over 6 months, so treat details such as pricing and features as unverified. Retired: the tool still works but is no longer recommended. Deprecated: the tool has been shut down or fundamentally changed. Retired and Deprecated posts include a Migration Path section. Base44 is Active.
Last tested and Re-check
Last tested is the date on which the vendor's own published surfaces were read for this review, and it is the anchor for everything that follows: pricing, credit rules, the training position, the access defaults and the contractual terms were read on 2026-09-27. Re-check triggers are the specific events that would require the assessment to be revisited before the six-month limit, and they are listed at the top of this review. The most consequential is the second, the plan-dependent training position, because it decides what the platform may learn from a build that holds institutional data.
Sources
Vendor primary sources
The product homepage, for the product framing, the four headline claims and the customer story: https://base44.com/
The pricing page, for the plan ladder, the annual and monthly figures and the two credit allowances per tier: https://base44.com/pricing
The vendor's own pricing article, for the annual and monthly prices and the credit table in one place: https://base44.com/blog/how-much-does-base44-cost
The application, for the working surfaces: https://app.base44.com/
The documentation home and its index, for the structure of the whole help set: https://docs.base44.com/
The quick start guide, for the first build and the editor: https://docs.base44.com/Getting-Started/Quick-start-guide
The prompt guide and prompt library, for how a description becomes a build: https://docs.base44.com/Getting-Started/Prompt-guide and https://docs.base44.com/Getting-Started/Prompt-library
The credits documentation, for the two meters, the per-action estimates, the no-preview rule and the expiry position, quoted in How Base44 Works: https://docs.base44.com/Account-and-billing/Credits
The billing and plans documentation, for upgrades, payment behaviour and gift cards: https://docs.base44.com/Account-and-billing/Billing-and-plans
The privacy and security page, for the plan-level training position, the data residency limits and the token-storage answer, quoted in Section 7c: https://docs.base44.com/Community-and-support/Privacy-and-security
The security overview, for the app security model, the visibility options and the scan: https://docs.base44.com/Setting-up-your-app/security-overview
Managing access, for the visibility levels, roles and invitations, quoted in How Base44 Works and in Getting Started with Base44: https://docs.base44.com/Setting-up-your-app/Managing-access
Setting up an AI agent, for guidelines, tools, connectors, skills and memory: https://docs.base44.com/Building-your-app/AI-agents-for-apps
The agent skills documentation, for how an agent selects and loads a skill and how skills are defined: https://docs.base44.com/developers/backend/resources/agents/agent-skills
Creating and customizing a Superagent, for channels, memory, security settings and self-management: https://docs.base44.com/superagents/creating-a-superagent and https://docs.base44.com/superagents/customizing-your-superagent
Taking notes with the Superagent, for the shared notes space and how it is maintained: https://docs.base44.com/superagents/taking-notes
Browsing with the Superagent, for the extension's behaviour in signed-in sessions: https://docs.base44.com/superagents/browser-control
Working with sub-agents, for the parallel execution model: https://docs.base44.com/superagents/subagents
The Base44 MCP server, for the external-assistant surface and its plan requirement: https://docs.base44.com/developers/backend/overview/mcp-server
The GitHub integration guide, for the sync behaviour, the local setup and the version-history limit: https://docs.base44.com/developers/app-code/local-development/github
The product changelog, for what shipped in the months before this review: https://base44.com/changelog
The terms of service, last updated 22 June 2026, and specifically sections 4.1 to 4.3 on Customer Data and the licence, 5.3 to 5.4 on Generated Output and its nature, 6 on restricted use, 10.1 to 10.6 on fees, chargebacks and AI credits, 11 on term and renewal, 13 on liability, 14 on indemnification and 15 on arbitration, all quoted in Section 7c: https://base44.com/terms-of-service
The privacy policy, last updated 10 September 2026, issued by Base44, Inc., for the collection, retention and rights position: https://base44.com/privacy-policy
The data processing addendum, for the subprocessor rules, the objection window, the audit right and the cross-border transfer mechanisms, quoted in Section 7c: https://base44.com/dpa
The Responsible Use Policy, for the restrictions that apply to what may be built: https://base44.com/responsible-use
The security and trust page, for the certifications, the encryption position, the monitoring commitments and the subprocessor directory, quoted in Section 7c: https://base44.com/security
The enterprise page, for the governance controls and the deployment options: https://base44.com/enterprise
The Superagent product page, for the assistant's own framing and examples: https://base44.com/superagents
The misuse reporting page: https://base44.com/misuse
Independent sources
An independent hands-on assessment that built applications and reports the editor, the publishing path, the pricing tiers and the security certifications: https://tech.co/ai/vibe-coding/base44-review
An independent test that built several projects and reports where the generated output needed work and how the export is gated: https://cybernews.com/ai-tools/base44-review
A research-based assessment by a competing platform that states its own conflict and is precise about the managed-backend limitation, the credit consumption of debugging and the export scope: https://www.jetadmin.io/blog/base44-review
An assessment of the post-acquisition state, with the contractual changes, the pricing shifts and the entity change dated to their sources: https://www.base44devs.com/blog/base44-after-wix-acquisition-what-changed
An assessment that records where the platform breaks on migration and what the vendor lock-in consists of: https://justinmckelvey.com/blog/base44-review
An analysis of export gating across the category, which states the plan requirement on the GitHub sync: https://www.totalum.app/blog/ai-app-builder-export-your-code-2026
An independent comparison that records the code-export difference between this platform and its closest competitor: https://till-freitag.com/en/blog/base44-vs-lovable-en
A panel assessment that built the same brief across several tools in the class and records per-axis scores: https://www.agent-verdict.com/tool/base44
The security research write-up on the July 2025 authentication-bypass finding, its disclosure timeline and the vendor statement, quoted in Section 7c: https://www.wiz.io/blog/critical-vulnerability-base44
Independent news coverage of the same finding and the fix timeline: https://www.darkreading.com/application-security/critical-flaw-vibe-coding-base44-exposed-apps
Independent coverage that places the finding in the wider context of the category: https://www.veracode.com/blog/base44-vulnerability-sparks-conversations-on-securing-vibe-coding
Review platform sources
Trustpilot profile, which carries the 890-review corpus and the 2.8 rating quoted in What Users Say: https://www.trustpilot.com/review/base44.com
Product Hunt page and its review summary, which carry the 41-review corpus, the 4.4 rating and the recorded pros and cons: https://www.producthunt.com/products/base44
G2 product page, which carries the thin review base and the ratings distribution referenced in the aggregate table: https://www.g2.com/products/base44/reviews
Capterra listing, which carries the three-review corpus and the billing complaint quoted in the aggregate table: https://www.capterra.com/p/10030696/BASE44/
GetApp listing, for the same thin corpus from a second directory: https://www.getapp.com/software-solutions/a/1025107/base44/
Community and community-reported evidence
The vendor's Discord community, linked from the documentation home: https://discord.com/invite/ThpYPZpVts
The vendor's YouTube channel, for product walkthroughs and release videos: https://www.youtube.com/@base44
The vendor's X account, whose description carries its own framing of the promise: https://x.com/Base44
The public feedback board, where feature requests and roadmap discussion live: https://feedback.base44.com/
Third-party hands-on review and tutorial that builds a working application on screen: https://www.youtube.com/watch?v=_WPnF5ZdpZ0
Third-party builder assessment after maintaining several applications: https://www.youtube.com/watch?v=l3HuOWJCC8o
An open source repository maintained by the vendor that teaches external coding assistants how to work with the platform, which is where the open Agent Skills format meets this product: https://github.com/base44/skills
Framework and method
The U365 CI-First Evaluation Framework, version 1.2, which is the scoring method used here. It sets the benefit dimensions, the Humics protection rating, the AI Imposture risk assessment and the collaboration modes applied in this review: https://www.university-365.com/ci-first
The U365 INSIDE Tools review template, which sets the structure of this post: https://www.university-365.com/tools
Published U365 INSIDE Tools reviews, read as comparisons and linked where they are named in this post, including the Emergent review cited in the comparison section: https://www.university-365.com/tools
Faculty Note on Evidence Quality
Four things should be said plainly about the evidence behind this review, because they change how much weight a reader should put on each part of it.
First, the platform's published surfaces disagree about its own security posture, and the disagreement is about the plan rather than the product. The security page presents training as a control a buyer can set, with a Training data opt-out marked Enterprise, under the heading "Your data, your rules." The support documentation states the same thing without the framing and adds the two facts a buyer needs: on Enterprise the exclusion is automatic, and on every other plan the workspace data can be used to train AI models, including personal information submitted through an app's own forms, with no setting to change. Both statements are the vendor's own and both are current. This review treats the support documentation as the operational figure and the security page as marketing, and a procurement file should carry the answer obtained from the vendor rather than from either page.
Second, the quality position rests on editorial and panel assessments rather than on measurements, and that is a statement about the whole category. No vendor in this class publishes a completion rate, an accuracy figure or an engineering assessment of what it generates, and the platform's own terms go further than most in disclaiming exactly that: the output is not warranted to meet expectations, is not warranted for completeness, accuracy or intellectual-property compliance, may violate third-party rights, and should not be used in high-risk domains. What exists is hands-on testing by publishers with commercial arrangements, a panel that built the same brief on several tools, and the vendor's own scan. This review uses those sources, names them, and declines to treat any of them as a measurement. That absence is why the Quality sub-score is 5 rather than higher, and it is the first re-check trigger at the top of this document.
Third, the two review cohorts answer different questions, and averaging them would hide the finding. Product Hunt's 41 reviews come from makers rating the build experience and return 4.4. Trustpilot's 890 reviews come from paying customers and return 2.8, with the complaints concentrated on credits consumed by repeated attempts, credits that cannot be used without changing plan, cancellation and support reachability. The G2 and Capterra samples are thin enough that a single review moves them by a quarter of a star, so this review quotes them with their counts rather than in a sentence. The one place the cohorts meet is the cost of the product, and the vendor's own documentation explains the mechanism rather than disputing it. A reader should read the 2.8 as a statement about the commercial layer and the 4.4 as a statement about the builder, because that is what the two corpora are.
Fourth, the documents that decide a commercial deployment are more precise than the pages a buyer reads first, and one of them contradicts the others in a direction that matters. The terms state the ownership position clearly and give the customer a broad licence back to the vendor in the section immediately before it. The credits documentation states, without hedging, that the published per-action figures are estimates, that credits are computed after the action runs and that no per-action cost can be previewed. The data processing addendum takes the narrower subprocessor position a business buyer expects. The support documentation states the retention and training answers that the marketing pages leave out. When a vendor publishes a limit and a claim on two pages, the limit is the document to believe, because it is the one the product has to honour.
One further asymmetry, stated as a reader risk rather than as a defect. The platform takes the access question seriously enough to scan every app and rate every finding, and it does not make the answer a gate: an application can be published with a failing scan, the default for a site-like app is public without sign-in, and the terms place the responsibility for reviewing and configuring those settings on the customer while stating that default configurations may not suit an intended use. A reader who assumes a clean scan means a safe application, because the platform goes to the trouble of producing one, is assuming something the documents do not claim. The decision about who may reach what belongs to the builder, and it is the decision this review's Getting Started checklist and its first workflow exist to put on the record.
Comments