(v5 — 0-based scale; sub-criteria with points, explicit score caps, and a re-scored worked matrix)
The 0 floor matters: a platform that cannot do something (no code export, no self-host, no AI-readability) now scores 0 there and earns no "participation point" — genuine absence is distinguished from merely poor (1).
Guiding meta-principle — prefer guarantees over responsibilities. For a non-technical, AI-assisted founder, the highest-leverage property is whether the platform enforces correctness rather than leaving it to code the founder can neither write nor audit. A guarantee (DB-enforced schema/constraints, transactional-by-default, row-level security on by default, managed auth) holds no matter what the AI generates; a responsibility (validate in app code, remember to wrap a transaction, write the security check) holds only until one code path forgets — and AI forgets often. Several scoring choices flow from this single idea: schema enforcement, the default-safety lens on transactions (‖), secure-defaults weighted level with auth, and the AI-build-reliability-vs-ownership discount. When two platforms tie on features, the one that converts more responsibilities into guarantees wins for this persona.
A cap exists because a fatal weakness on a survival-critical sub-criterion can't be averaged away. For this persona, a backend an AI can't read is not "a few points worse" than one it can — it's close to unusable, and the score should say so.
If a condition below holds, the final score cannot exceed the stated ceiling. If several apply, the lowest ceiling wins.
| Gate | Condition | Ceiling | Why |
|---|---|---|---|
| G1 — AI-inoperable (universal) | Standard readable code/schema ≤ 1 and API-first control ≤ 2 | 40 | The AI is the builder; a backend it can't read or drive is near-disqualifying for a non-technical founder |
| G2 — Can't stay up (universal) | Reliability & uptime ≤ 1 | 45 | No uptime = not a real product, only a demo |
| G3 — Corrupts data (conditional) | Product handles money, inventory, or bookings and Atomic transactions & integrity ≤ 1 | 45 | Silent data corruption is fatal for that product class |
| G4 — Can't isolate tenants (conditional) | Product is multi-tenant / stores other users' personal data and Authorization & isolation ≤ 1 | 45 | A backend that can't keep tenants apart is a breach by design |
G5 — lock-in is deliberately NOT a hard cap. A fully locked-in but otherwise excellent platform still ships a working product; the risk is future, not present. Lock-in is therefore priced as a heavy weighted discount (13 points across criterion 4) plus an insurance note — not a knockout. This is a documented choice, not an omission.
Conditional gates (G3, G4) require knowing the product. State the product type before scoring; if it doesn't touch money/inventory/bookings or other users' data, those gates simply don't apply.
The three "does it work" axes are kept distinct by failure mode: structural soundness = wrong data on a healthy, authorized system; security = wrong person reaches the data; production-readiness = system down or slow. Two litmus tests are scored once, in the criterion matching their purpose: API-first under #2, row-level isolation under #5 — not under #3 — to avoid double-counting.
| Criterion / sub-criterion | Pts | What it measures |
|---|---|---|
| 1. Production-readiness (operational) | 20 | Stays up and fast under real load |
| · Reliability & uptime (track record, SLA) | 6 | Does it stay up; published SLA; incident history |
| · Scalability headroom | 5 | Reaches your target scale without re-architecture; known ceilings |
| · Performance under load | 4 | Latency/throughput at volume; function cold starts |
| · Backups & disaster recovery | 3 | Automated backups, point-in-time restore, durability |
| · Observability & ops tooling | 2 | Logs, metrics, alerts a founder or their dev can use |
| 2. AI-tool compatibility & API-first openness | 16 | Can an AI coding tool read and drive the backend |
| · API-first programmatic control (gate input) | 4 | Every operation triggerable by code/script/AI, not just a button |
| · Standard, readable code & schema (gate input) | 4 | Real code/SQL/migrations an AI can edit vs. a closed visual model |
| · MCP / native agent integration | 3 | Official MCP server; first-class in Cursor/Claude Code/etc. |
| · AI-agent build reliability (codegen, tool-use, or CLI) | 3 | Given an agent channel, how reliably an agent succeeds — training-data footprint, interface predictability, error-recoverability (Postgres ≫ niche) |
| · AI-ingestible documentation | 2 | Public, structured, complete docs an agent can consume |
| 3. Structural backend soundness (correctness) | 14 | Right answer / right state under contention & complexity |
| · Atomic transactions & data integrity (gate input) | 4 | Multi-step write rolls back cleanly; no half-finished state |
| · Concurrency correctness | 3 | No double-booking when two users act at the same instant |
| · Query flexibility, joins & server-side aggregation | 2 | Ad-hoc queries/joins/aggregation in the DB vs. pre-planned access patterns (NoSQL rigidity penalized; see ‡) |
| · Backend compute (async / long jobs) | 2 | Bulk work runs server-side without freezing the UI |
| · Schema enforcement & data consistency over time | 3 | DB-enforced typed schema on every write + migration discipline — a guarantee that holds against any AI-generated code — vs. heterogeneous/stale documents drifting in shape (see §) |
| 4. Lock-in, exit & extensibility | 13 | Can you get out, and can a dev extend it later |
| · Data portability | 4 | Clean export in a standard format (e.g., pg_dump) |
| · Logic / code portability | 3 | Business logic exportable as real code vs. trapped in config |
| · Open standards / self-hostability | 3 | Built on open source / Postgres; can self-host |
| · Developer escape hatch | 3 | Drop to custom code; a hired dev can extend a stack they know |
| 5. Security & access control | 13 | Keeps the wrong person out (integrity lives in #3) |
| · Authentication | 3 | Managed auth: providers, MFA, sessions, quality of defaults |
| · Authorization & data isolation (RLS/RBAC) (gate input) | 3 | The "glass wall" — one tenant can't read another's rows |
| · Secure defaults / guardrails | 3 | Prevents the common AI-generated misconfig (isolation on by default) |
| · Encryption & secrets handling | 2 | At rest + in transit; no leaked keys by default |
| · Compliance certifications | 2 | SOC 2, ISO 27001, GDPR, HIPAA/BAA availability |
| 6. Non-technical usability | 10 | How far a non-coder gets, alone or via an AI tool |
| · Visual / GUI capability | 3 | What you accomplish with no code |
| · AI-mediated usability | 2 | How well a non-coder drives it through an AI tool |
| · Onboarding & time-to-first-result | 2 | Speed to a working something |
| · Learning resources | 2 | Official docs/courses for humans |
| · Community | 1 | Forum/Discord size & responsiveness |
| 7. Pricing & cost at scale | 9 | Affordability and surprise-bill risk |
| · Predictability & model transparency | 3 | Subscription vs. usage/credits; bill-shock risk |
| · Cost trajectory at scale | 3 | How steep the curve gets at 10×/100× |
| · Spend controls | 2 | Hard caps, budget alerts |
| · Free / starter tier adequacy | 1 | Can you validate without paying |
| 8. Ecosystem & integrations | 3 | Convenience (lightly decomposed) |
| · Native integrations / connectors | 1 | Payments, email, auth providers, third-party APIs |
| · Client SDK breadth | 1 | Web, iOS, Android, framework coverage |
| · Marketplace / plugins / templates | 1 | Pre-built building blocks |
| 9. Company longevity & stability | 2 | Tail risk — kept atomic |
| · Longevity (funding, traction; OSS self-hostability insures this) | 2 | Shutdown risk, mitigated for open-source platforms (cross-ref #4) |
Two emphasis notes. API-first is a gate input, not just a weighted item — a near-zero there triggers G1 regardless of how strong usability or ecosystem look. Secure defaults is weighted equal to auth and authorization (3 each) on purpose: with roughly 45% of AI-generated code shipping OWASP-Top-10 flaws in Veracode's 2025 testing, what the platform does for you by default (isolation on, no public buckets) protects this founder more than any feature they must remember to switch on.
‡ Query flexibility penalizes NoSQL rigidity; manual joins forego the optimizer. Anchors: 5 = full SQL with a cost-based optimizer that plans joins/indexes for you (Supabase, Xano, Momen); 3 = a real aggregation framework and a query planner for single-collection work (index selection, explain), but joins are manual and unoptimized — $lookup runs as a naive nested-loop, in-code joins for Convex — with no cost-based join planning, so they degrade at scale and push you toward denormalization (MongoDB, Convex); 2 = single-collection filters + basic count/sum/avg, no joins at all (Firestore). The 3 credits genuine single-collection power, not relational parity: for a join-heavy or relational-reporting product, treat a manual-join platform as a 2 (conditional, like gates G3/G4). Link to §: foregoing real joins forces denormalization, and denormalized data is exactly what drifts stale — the query and consistency weaknesses compound.
§ Schema enforcement & data consistency over time — the stale/heterogeneous-data problem. Scored on default-safety (what the default path yields), consistent with the transactions note ‖. This criterion covers three guarantees: a typed schema enforced on every write, referential-integrity (foreign-key) enforcement, and migration of existing rows as the schema evolves. Anchors: 5 = typed schema + enforced FK constraints on every write + first-class migrations that bring old rows forward (Supabase/Postgres); 4 = enforced typed schema with relations/constraints + migration tooling (Convex; Momen — whose typed columns and primary-key, unique, and fk_… foreign-key constraints are verified from a project schema export, the remaining gap to 5 being its less battle-tested migration-over-time story); 3 = typed fields enforced but a real integrity gap — Xano enforces types but its "table reference" fields are not backed by FK constraints (its own docs teach a manual Precondition check to confirm a referenced record exists), so referential integrity is an app-level responsibility, not a guarantee; Bubble enforces field types by default but migration of existing records is weak/manual; 0 = no schema enforcement by default and no migration framework, so heterogeneous and stale document shapes are the default outcome (MongoDB, Firestore). Opt-in validators ($jsonSchema), app-level schemas (Mongoose), or Firestore Security Rules can claw a disciplined team back toward 3, but they are off by default, bypassable, and do nothing for the documents already stored with stale shapes — so for the non-technical, AI-assisted persona the honest default score is the floor. NoSQL platforms market "no migrations needed" as a velocity win; for a real, long-lived product that is precisely what lets a field's type drift and v1 documents never gain the v2 field.
Assumed product profile for the conditional gates: a multi-tenant SaaS that handles payments (so G3 and G4 are live). None of the seven scored ≤1 on transactions or isolation, so neither conditional gate binds — but G1 does (Bubble).
| Criterion (weight) | Supabase | MongoDB | Xano | Convex | Firebase | Momen | Bubble |
|---|---|---|---|---|---|---|---|
| Production-readiness (20) | 80/100 | 94/100 | 75/100 | 64/100 | 95/100 | 74/100 | 49/100 |
| AI-compat & openness (16) | 80/80 | 68/80 | 61/80 | 61/80 | 50/80 | 57/80 | 14/80 |
| Structural soundness (14) | 64/70 | 36/70 | 47/70 | 61/70 | 33/70 | 56/70 | 33/70 |
| Lock-in & exit (13) | 65/65 | 49/65 | 37/65 | 39/65 | 14/65 | 21/65 | 11/65 |
| Security & access (13) | 59/65 | 44/65 | 49/65 | 49/65 | 56/65 | 43/65 | 36/65 |
| Usability (10) | 39/50 | 29/50 | 40/50 | 29/50 | 36/50 | 35/50 | 42/50 |
| Pricing (9) | 33/45 | 29/45 | 31/45 | 28/45 | 20/45 | 35/45 | 21/45 |
| Ecosystem (3) | 11/15 | 12/15 | 10/15 | 8/15 | 14/15 | 7/15 | 11/15 |
| Longevity (2) | 8/10 | 10/10 | 6/10 | 6/10 | 10/10 | 6/10 | 8/10 |
| Final score | 88 | 74 | 71 | 69 | 66 | 67 | 40* |
* Bubble's base score is 45; gate G1 (AI-inoperable) caps the final at 40.
How to read it: Supabase is maxed on AI-compat (80/80) and lock-in (65/65) and never dips below ~60% on any criterion — that consistency, not a single peak, is why it wins. Firebase and MongoDB top production (95, 94) but crater on lock-in (14, 49) and structural (33, 36), the price of proprietary NoSQL. Bubble's 14/80 on AI-compat is precisely what trips the gate. Convex's structural 61/70 and Momen's structural 56/70 show real backend soundness; Momen's official MCP server lifts its AI-compat to 57/80, so lock-in (21/65) is now the main thing holding it down. The detailed per-sub-criterion scores behind every cell follow below.
| Sub-criterion (Pts) | Supabase | Xano | Convex | Firebase | Bubble | Momen | MongoDB † |
|---|---|---|---|---|---|---|---|
| Reliability & uptime (6) | 4 | 4 | 3 | 5 | 3 | 4 | 5 |
| Scalability headroom (5) | 4 | 4 | 3 | 5 | 2 | 4 | 5 |
| Performance under load (4) | 4 | 4 | 4 | 5 | 2 | 4 | 4 |
| Backups & DR (3) | 4 | 3 | 3 | 4 | 3 | 2 | 5 |
| Observability (2) | 4 | 3 | 3 | 4 | 2 | 4 | 4 |
| API-first control (4) | 5 | 5 | 4 | 4 | 2 | 4 | 3 |
| Readable code & schema (4) | 5 | 3 | 4 | 2 | 0 | 3 | 4 |
| MCP / agent integration (3) | 5 | 4 | 4 | 3 | 0 | 4 | 5 |
| AI-agent build reliability (3) | 5 | 3 | 3 | 3 | 0 | 3 | 5 |
| AI-ingestible docs (2) | 5 | 4 | 4 | 4 | 3 | 4 | 5 |
| Atomic transactions & integrity (4) ‖ | 4 | 4 | 5 | 3 | 2 | 4 | 3 |
| Concurrency correctness (3) | 5 | 2 | 5 | 3 | 2 | 4 | 4 |
| Query flexibility, joins & aggregation (2) ‡ | 5 | 4 | 3 | 2 | 2 | 4 | 3 |
| Backend compute (2) | 4 | 4 | 4 | 4 | 3 | 4 | 3 |
| Schema enforcement & consistency (3) § | 5 | 3 | 4 | 0 | 3 | 4 | 0 |
| Data portability (4) | 5 | 4 | 3 | 2 | 2 | 3 | 4 |
| Logic / code portability (3) | 5 | 2 | 3 | 0 | 0 | 0 | 4 |
| Open standards / self-host (3) | 5 | 2 | 3 | 0 | 0 | 0 | 3 |
| Developer escape hatch (3) | 5 | 3 | 3 | 2 | 1 | 3 | 4 |
| Authentication (3) | 5 | 4 | 4 | 5 | 3 | 4 | 2 |
| Authorization & isolation (3) ◆ | 5 | 3 | 3 | 4 | 3 | 4 | 3 |
| Secure defaults (3) ◆ | 3 | 4 | 4 | 3 | 2 | 3 | 3 |
| Encryption & secrets (2) | 5 | 4 | 4 | 5 | 3 | 3 | 5 |
| Compliance certs (2) | 5 | 4 | 4 | 5 | 3 | 2 | 5 |
| Visual / GUI capability (3) | 3 | 5 | 2 | 3 | 5 | 5 | 2 |
| AI-mediated usability (2) | 5 | 3 | 4 | 3 | 2 | 3 | 2 |
| Onboarding (2) | 4 | 4 | 3 | 4 | 4 | 3 | 3 |
| Learning resources (2) | 4 | 4 | 3 | 4 | 5 | 3 | 4 |
| Community (1) | 4 | 3 | 3 | 5 | 5 | 2 | 5 |
| Predictability & transparency (3) | 4 | 4 | 3 | 2 | 2 | 4 | 3 |
| Cost trajectory at scale (3) | 3 | 3 | 3 | 2 | 2 | 4 | 3 |
| Spend controls (2) | 4 | 4 | 3 | 2 | 3 | 4 | 3 |
| Free tier adequacy (1) | 4 | 2 | 4 | 4 | 3 | 3 | 5 |
| Native integrations (1) | 4 | 4 | 3 | 5 | 4 | 3 | 4 |
| Client SDK breadth (1) | 4 | 3 | 3 | 5 | 2 | 2 | 5 |
| Marketplace / plugins (1) | 3 | 3 | 2 | 4 | 5 | 2 | 3 |
| Longevity (2) | 4 | 3 | 3 | 5 | 4 | 3 | 5 |
† MongoDB is scored as "Atlas (database) + an AI-assembled backend," not a turnkey BaaS — its turnkey BaaS layer (Atlas App Services: managed auth, functions, Data API, GraphQL) reached end-of-life on Sept 30, 2025. So the auth (2) and API-first (3) scores reflect that you must build the auth/API layer yourself; the high AI-compat and lock-in scores reflect a best-in-class training-data footprint + official MCP, and that your backend code lives in your repo (portable precisely because Atlas provides no logic layer). See the discussion below for why the headline number overstates fit for a pure non-coder.
‖ Atomic transactions are scored on default-safety, not just capability ceiling. For a non-technical, AI-assisted founder what matters is whether the default pattern produces atomic writes. Convex (5) is transactional by default — every mutation is a serializable transaction. Supabase has the highest capability ceiling (full Postgres) but its common supabase-js REST pattern autocommits per call and is not atomic unless logic is deliberately pushed into a Postgres function, so it scores 4. Momen (4) is transactional by design via synchronous all-or-nothing Actionflows, but on a constrained visual layer. A purely technical team scoring on capability alone would rate Supabase 5 here. Isolation level reinforces the concurrency scores: Convex is serializable by default, so the double-booking race cannot occur — which is why it alone scores 5 on both transactions and concurrency. The Postgres-based platforms — Supabase, Xano, and Momen — all default to read committed, which blocks dirty reads but not lost-update/double-booking races; each needs an explicit guard (a unique/exclusion constraint or SELECT … FOR UPDATE). Xano now sits at 2: a user test showed that even an HTTP PATCH to different fields of the same record loses one of the writes — its auto-generated update path performs a full-record read-modify-write rather than a column-targeted UPDATE, so routine concurrent edits clobber each other and no native row-locking guard is exposed. Momen now sits at 4: the double-booking/oversell race is preventable with mechanisms it verifiably has — a composite unique constraint on an occupancy/junction row, or an atomic guarded decrement (SET available_count = available_count - 1 WHERE available_count >= 1, evaluated server-side) — and multi-step Actionflows are atomic by default. Its different-field case is now confirmed safe: Momen issues column-targeted statements (UPDATE … SET field_1 = x WHERE id = a) with no ORM doing a full-record read-modify-write, so two concurrent edits to different fields of the same row both survive — the opposite of Xano's clobber. It is held below 5 only because the advanced toolkit isn't confirmed: exclusion constraints (reject two bookings whose time ranges overlap — a plain unique constraint can't express that), explicit row locking for multi-row invariants, and opt-in serializable — all of which Supabase exposes and the corpus knows well. Supabase keeps 5 for exactly that full toolkit. MongoDB also sits at 4 by the same logic: idiomatic atomic single-document operators (findOneAndUpdate with a condition, $inc) plus unique indexes prevent double-booking by default; its residual gap mirrors Momen's — multi-document invariants need an explicit, opt-in transaction (snapshot isolation) an AI-assembled backend may omit. So Momen ≈ MongoDB in aggregate, both at 4 via mirror-image residual gaps; Xano stays at 2 because its full-record-overwrite clobber is a confirmed failure on routine concurrent edits with no exposed guard. Testing note: verify concurrency with a script firing many parallel writes — manual two-tab clicking rarely aligns the millisecond race window and gives false passes.
◆ Authorization & secure-defaults — Momen's enforcement is source-verified; Xano/Convex reflect their documented model. This pair is scored on guarantee-vs-responsibility and default-safety. Supabase (auth 5 / secure-defaults 3): Postgres-native row-level security is the gold-standard guarantee — enforced by the database kernel, auditable as SQL — but it ships off by default (the RLS-off footgun behind real vibe-coding breaches), so secure-defaults is only 3. Momen (auth 4 / secure-defaults 3): its GraphQL permission engine was read directly. Per-table, per-operation policies (TableSelectAccess/Insert/Update/Delete) carry row-level boolean-expression filters (BoolExp rowFilter/check) compiled to SQL Conditions against JWT role + session variables — row-level ABAC — plus per-role column allow-lists (fieldCoordinatesByRole). That is a declarative, uniform guarantee applied to all API traffic, not a per-resolver check — so Momen's authorization ranks above the code-enforced backends. It stays below Supabase's authorization 5 only because enforcement is the platform's own engine rather than Postgres-native RLS an outside dev can audit or rely on for non-API paths, plus less battle-testing. On secure-defaults, though, Momen only ties Supabase at 3: it ships a convenience default-open table mode (vendor-confirmed) — a footgun that mirrors Supabase's RLS-off-by-default — so the safe posture is not guaranteed by default for either. Xano / Convex (auth 4 → 3): isolation is enforced in the function stack and in-function code respectively — a responsibility the builder re-implements per access path (consistent with Xano's manual-Precondition referential-integrity pattern), not a declarative default. Scored on their documented model; either returns to 4 if shown to enforce row/column isolation declaratively by default.
| Platform | Raw (max 500) | Base score | Gate triggered | Final |
|---|---|---|---|---|
| Supabase | 439 | 88 | none | 88 |
| MongoDB (Atlas + AI-assembled backend) | 371 | 74 | none | 74 |
| Xano | 356 | 71 | none | 71 |
| Convex | 345 | 69 | none | 69 |
| Momen | 334 | 67 | none | 67 |
| Firebase | 328 | 66 | none | 66 |
| Bubble | 225 | 45 | G1 (readable-code 0, API-first 2) → cap 40 | 40 |
The standings come from consistency and gates, not single peaks: Supabase leads by having no weak axis, Bubble is held down by the AI-inoperability gate, and the middle of the field is separated mostly by lock-in and structural soundness. The schema-enforcement reweight (a guarantee property) and the 0 floor for genuine absence are what pull the proprietary and schemaless platforms down. Full per-platform reads follow.
Supabase — 88. Wins on the absence of weak spots rather than any single peak: perfect on AI-compat (80/80 — official MCP, the default target of Lovable/Bolt/v0, standard SQL an agent reads natively) and lock-in (65/65 — open Postgres, pg_dump, self-hostable), with strong structural soundness (64/70) and security (59/65). Its softer areas are usability (39/50 — it assumes some database fluency and leans on AI tools to close that gap) and secure-defaults (the RLS-off footgun behind real vibe-coding breaches, which is why security isn't higher). Production is solid (80/100) without being Google-tier, and auth-by-MAU plus egress are the cost watch-items (33/45). For this persona it's the safest default: turnkey enough to start, open enough never to trap you, and the backend AI tools handle best.
Xano — 71. The best fit for a true non-coder who wants backend power without writing code: top usability in the field (40/50 — a purpose-built visual backend with live office hours) on a real Postgres foundation, with an MCP server and OpenAPI generation keeping AI-compat respectable (61/80). But its structural soundness (47/70) carries two real integrity gaps for a production data store: its "table reference" fields are not enforced as foreign-key constraints (the docs teach a manual Precondition check instead of relying on the database), and — confirmed by testing — even an HTTP PATCH to different fields of the same record loses a write, because its update path reads and rewrites the whole record rather than the targeted column, so routine concurrent edits clobber each other (concurrency 2). Both are cases where referential and concurrency correctness fall on the builder rather than being guaranteed by the database. It's further held back by lock-in (37/65 — business logic lives in proprietary XanoScript and self-host is enterprise-only), data isolation enforced in the function stack rather than declaratively (authorization 3 — ◆), and the absence of native realtime. Pricing is predictable but climbs (31/45); community and longevity trail the incumbents. Paired with a frontend builder, and with those integrity gaps guarded explicitly, it remains a strong no-code-backend pick.
MongoDB (Atlas + AI-assembled backend) — 74. Elite where the rubric weights heaviest — production (94/100, mature Atlas) and AI-compat (68/80, official MCP plus the largest training corpus of any database) — with strong portability (49/65: self-hostable, and the backend code lives in your own repo). But it is not a turnkey BaaS (App Services is EOL since Sept 2025, so auth and the API layer must be assembled), and it craters on structural soundness (36/70): schemaless scores 0 on the enforced-schema guarantee, and $lookup joins forego the optimizer — though atomic single-document operators plus unique indexes keep concurrency respectable (4/5). Usability is low (29/50) because realizing the score means owning a four-layer custom stack. Best for a technical-adjacent founder leaning on AI; a pure non-coder's route here runs through a wrapper platform rather than Atlas directly.
Convex — 69. The structural standout among the non-Supabase options (61/70): every mutation is a serializable transaction by default and the schema is validated — the two properties that best convert responsibility into guarantee — with end-to-end TypeScript, an MCP server, and an open-sourced backend. AI-compat is good (61/80) and security is solid (49/65), though authorization lives in function code — a responsibility, not a declarative default (authorization 3 — ◆). It's held back by usability (29/50 — code-first, no visual builder, so a non-coder depends entirely on the AI), a younger and smaller production record (64/100), and a modest ecosystem (8/15). Excellent for a real-time or collaborative TypeScript app; the weakest of the field for someone avoiding code entirely.
Momen — 67. A structurally serious no-code option that improves sharply on closer inspection: real Postgres with synchronous all-or-nothing Actionflows gives it the best structural score among the pure no-code tools (53/70); a project schema export confirms genuine DB-level enforcement — typed Postgres columns, primary keys, composite unique constraints, and foreign keys (the referential integrity Xano lacks) — and its backend compute is capable, with async multi-step Actionflows and structured-output AI agents (the uploaded example is a multi-agent project cost estimator built entirely in Momen) putting it on par with the code-first backends. An official MCP server (momen-mcp) lets Cursor/Claude Desktop read and edit its data model, tables, and relations through an authenticated session — lifting AI-compat to 57/80, well clear of the gate. Production reportedly matches Supabase on reliability, scalability, and performance (user-provided, consistent with its managed-Postgres architecture), every backend operation is traced by a correlation id (observability 4/5), and the docs are comprehensive and cleanly structured. Fixed project-based pricing is the most predictable in the field (35/45). Its data-isolation model was verified from source — declarative per-table/-operation policies with row-level ABAC filters compiled to SQL and per-role column allow-lists, a genuine guarantee that lifts authorization (4) above the code-enforced backends. Secure-defaults only ties Supabase (both 3): Momen ships a convenience default-open table mode — a footgun mirroring Supabase's RLS-off-by-default — so a safe posture isn't guaranteed by default (security 43/65; ◆). What still holds it back: heavy lock-in (21/65 — no code export, no self-host, though custom code blocks, code components with a CLI, and the MCP give a real in-platform extension surface), a thin disaster-recovery story (one daily backup at 00:00 GMT, not self-service downloadable → 2/5), read-committed isolation where the double-booking race is nonetheless preventable via its verified unique constraints or an atomic guarded decrement, and concurrent edits to different fields of a record are confirmed safe (column-targeted updates, no full-record rewrite) — concurrency 4, held below 5 only by the unconfirmed advanced toolkit (exclusion constraints, explicit locking), and unverified compliance — and several platform claims remain vendor- or user-provided rather than independently verified.
Firebase — 66. Tops production (95/100, Google-grade reliability and scale) with strong security and compliance (56/65), a deep ecosystem (14/15), and rock-solid longevity (10/10). The cost is structural and strategic: lock-in is the worst among the managed options (14/65 — proprietary Firestore, no self-host, no code export, leaving means a rebuild), structural soundness is weak (33/70 — NoSQL schema scores 0, aggregation is constrained), and Blaze pay-per-operation pricing carries genuine spike risk (20/45). Strong for a mobile-first or realtime app if you accept that exit cost — which, for a multi-year product bet, is the thing to weigh hardest.
Bubble — 40 (capped). Flagship no-code usability (42/50 — the largest builder community, a deep marketplace, strong learning resources) gives it a base of 45, but the AI-inoperability gate caps it at 40: it scores 14/80 on AI-compat because an external AI tool cannot read or edit its visual logic, and its lock-in is the worst in the field (11/65 — no code export). Structural soundness is weak (33/70 — its own database struggles with aggregation and lacks real transactions). It is the fastest path to a working demo, but as a foundation for an AI-assisted, portable, production product it's the weakest here — which the cap exists to say out loud.
Cross-cutting pattern: the platforms that finish highest are the ones that convert responsibilities into guarantees (enforced schema, transactional-by-default, secure-defaults, open exit) and that an AI tool can read and drive directly — which is why a consistent Postgres-based platform beats both the higher-peaking proprietary databases and the more usable closed builders.