# https://getcreatr.com/adalo-alternatives-2026 # Adalo Alternatives in 2026: Native Mobile vs Real Web Apps Adalo alternatives 2026 **Quick answer:** The right Adalo alternative depends on whether your core need is a native mobile app or a real web app. If you need an App Store and Play Store build, look at FlutterFlow, GoodBarber, or Adalo itself - and skip the rest of the "switch to a managed build" pitch, because that is genuinely not what Creatr does. If your Adalo app is really a portal, dashboard, or business tool that needs solid auth, data correctness, and integrations, then Softr, Glide, Bubble, or a managed build like Creatr are the honest options. [Adalo](https://www.adalo.com/) earned its place by doing one hard thing well: it lets non-developers build native iOS and Android apps on a visual canvas and publish them to the Apple App Store and Google Play. It compiles native IPA and APK files from a single project rather than shipping a web wrapper. For a founder with no engineering team and a mobile-first idea, that is a real shortcut. Most people searching for Adalo alternatives split cleanly into two camps, and the worst mistake you can make is choosing a tool from the wrong camp. So before the table, the honest fork: are you building a native mobile app, or a web app that happens to be on a phone? | Alternative | Best for | Where it walls | | --- | --- | --- | | FlutterFlow | Native mobile with code export | Dart floor, web output is a compromise | | GoodBarber | Native apps plus PWA, design-led | Rented platform, less custom logic | | Softr | Web portals on Airtable data | No native apps, frontend-layer auth | | Glide | Apps over existing spreadsheet data | Light backend, not for complex logic | | Bubble | Full web apps with real logic | Hosted, performance and lock-in | | Creatr | Owned production web app | Not native mobile, not a weekend job | ## First, Be Honest About Native vs Web Adalo straddles two worlds, and that is exactly why "Adalo alternatives" is such a muddy search. Per [Adalo's own product pages](https://www.adalo.com/), it builds native iOS, Android, and web apps from one project. Some Adalo users genuinely need the native part - camera access, push notifications, offline behavior, an icon on the home screen, a listing in the App Store. Others built an "app" that is really a login-gated business tool: a CRM, a member portal, a booking system, a field-ops dashboard. Those users never needed native at all. A responsive web app would have covered the whole use case. This distinction decides everything downstream. If you pick a web-app builder when you actually need native, you will fail to publish to the stores. If you pick a native builder when you only needed web, you take on app review cycles, store fees, and platform constraints for no reason. Sort yourself into the right camp first. ## If You Need Native Mobile: FlutterFlow, GoodBarber, or Adalo If your core requirement is a real app in the App Store and Play Store, Creatr is not your tool, and we will say that plainly. Stay in the native-builder category. [FlutterFlow](https://flutterflow.io) is the strongest step up from Adalo for native. It is a more powerful visual builder, integrates Firebase and Supabase out of the box, and - the key difference - exports actual Dart and Flutter code that you own. That export is the escape hatch Adalo lacks. The cost is the Dart floor: every time the visual builder cannot express something, you drop into Dart, a smaller language by hiring pool than JavaScript or Swift. And FlutterFlow's web output is a Flutter canvas rendered in a browser, not real HTML, so it is a compromise if web matters. We cover the tradeoffs in depth in our [FlutterFlow alternatives guide](/flutterflow-alternatives-2026). [GoodBarber](https://www.goodbarber.com/) is the design-led option. It builds native iOS and Android apps plus a PWA from one back office and leans hard on visual quality, with an all-inclusive subscription that bundles hosting, push infrastructure, and analytics rather than charging for each separately. It is a rented platform with less room for arbitrary custom logic than FlutterFlow, but for a polished, fairly standard native app it removes a lot of plumbing. And Adalo itself remains a reasonable answer. Following its 3.0 infrastructure overhaul in late 2025, Adalo publishes native apps from around $36/month with unlimited usage. If your only complaint was performance, the platform you are already on may have fixed it. One thing worth saying about all three native builders: publishing native is not a one-time cost. It is an ongoing relationship with two app stores that each have review queues, rejection rules, and update cycles. Apple App Store review typically runs 1-3 days and Google Play 1-7 days, per Adalo's own publishing figures, and a rejected build means another round trip. GoodBarber even sells a managed submission service - GBTC - precisely because store rejections are common enough to need handholding. None of this is a reason to avoid native. It is a reason to be sure you actually need it before you sign up for it. ## If It Is Really a Web App: Softr, Glide, or Bubble This is the larger group, and the one where the rest of this post lives. If your Adalo app is a portal, an internal tool, or a customer-facing dashboard, you are building a web application, and the right alternatives are web-native. [Softr](https://www.softr.io/) turns a database - usually Airtable - into branded portals, dashboards, and CRMs with login pages and user authentication. It is excellent at the "give my customers a clean front end over our data" job and ships white-labeled apps with custom domains fast. The catch, by Softr's own positioning, is that it has no native mobile apps and the access control sits in the frontend layer rather than the database. [Glide](https://glideapps.com) turns existing spreadsheet or database data into a usable app interface. If the data already lives in Google Sheets or a SQL database and the problem is a clean UI over it, Glide is purpose-built for that. It is light on backend logic by design - great for surfacing operational data, wrong for anything with complex server-side rules. [Bubble](https://bubble.io) is the heavyweight. It is a full web-app builder with a real logic layer, a database, and workflows, so you can express genuine application behavior that Softr and Glide cannot. The tradeoffs are the familiar ones for a hosted visual platform: a learning curve, performance work at scale, and the lock-in that comes from your whole app living inside Bubble's runtime. For a complex web product with a non-technical builder, it goes further than anything else on this list. ## The 30-40% Every One of These Stalls On Here is the pattern we see constantly with founders who have tried these tools. Each one gets you 60-70% of a real product fast. The demo logs in, the data shows up, the happy path works. Then the last 30-40% - the part that decides whether the thing survives contact with real users - is where they stall. That hard remainder is always the same four things. Real authentication with multiple roles, where a customer, an admin, and a partner each see exactly their own data, enforced at the data layer and not just hidden in the UI. Integrations and their failure paths - what happens when the payment webhook fires twice, or the third-party API times out mid-transaction. Data correctness - constraints, foreign keys, and transactions that refuse a bad state instead of silently storing it. And security, which on any prompt-built or visual-built backend defaults to the happy path and needs an explicit review before real user data goes near it. The patterns and failure modes are worth reading before you commit, in our breakdown of [no-code app scaling problems](/no-code-app-scaling-problems) and the worked example in [how to build a social app without code](/how-to-build-social-app-without-code). ## What Switching Actually Costs You Before you move, count the real cost of a switch, because it is rarely just learning a new editor. Moving from Adalo to a web-native tool means rebuilding the UI, remapping the data model, and re-implementing every piece of logic and integration by hand - none of it ports. Moving from Adalo to another native builder like FlutterFlow means the same rebuild plus a new language floor underneath it. And whichever direction you go, your users have to follow: a native app means an App Store relisting and a forced update, while a web app means a new URL and a fresh login flow. The questions that actually decide the move are these. Does the product genuinely need native, or did it just get built that way? Who extends the codebase six months from now, and can they read what the tool produced? And what is the security posture - because any builder that generates a backend, visual or prompt-driven, is making access and data decisions for you that need an explicit review before real users arrive. If those answers point at a real application rather than a prototype, switching tools inside the no-code tier may just move the same ceiling a few feet higher. ## Where Creatr Fits - and Where It Doesn't Let us be precise, because the wrong recommendation here wastes your money. [Creatr](https://getcreatr.com) is for the web-app subset of Adalo users only. If your real need is a native App Store and Play Store app, Creatr is the wrong choice and one of the native builders above is right. We would rather say that than sell you a mismatch. For the portal, dashboard, CRM, or business-tool builders - the ones who never actually needed native - Creatr is a managed build that ships a production web app as code you own. It is built to clear exactly the 30-40% that the no-code tools stall on: multi-role auth enforced at the data layer, integrations with their failure paths handled, real schema with real constraints, and a security posture that was designed rather than defaulted. Not a platform you rent, not a prototype you have to finish. It costs more than a monthly subscription and it takes longer than a weekend. The thing you get back is an application that holds up when real users hit it. So the decision is two questions, in order. First, native or web - if native, pick FlutterFlow, GoodBarber, or Adalo and stop here. Second, if web: do you want a tool to keep operating, or a product to own? Softr, Glide, and Bubble keep you on a platform that got you most of the way. A managed build hands you the finished thing as code. Adalo was a fine place to start. Knowing which of these two forks you are actually on is what keeps the next step from being a wrong turn. --- # https://getcreatr.com/add-authentication-to-ai-built-app # How to Add Authentication to an AI-Built App (Past the Login Form) Adding authentication to an AI-built or no-code app: roles, RLS, and sessions **The short version:** A login form is roughly 10% of authentication - the real work is authorization (row-level security, roles, sessions, and reset flows) that AI builders skip because nothing in your prompt forced them to think about it. You asked your AI builder for "user login," and it gave you a login form. Email field, password field, a Supabase or Clerk call wired in, and a redirect to a dashboard after sign-in. It works. You can sign up, sign in, sign out. From the outside it looks done. Then a second user signs up, and you notice something. Open a second browser in incognito, create user B, and load the dashboard. User B can see user A's data. The orders, the projects, the messages - all of it. The login form authenticated the user. Nothing stopped them from reading everyone else's rows. This is the wall. A login form is roughly 10% of authentication. The other 90% is authorization, and it is [the part AI builders consistently skip](/how-ai-app-builders-handle-authentication) because nothing in your prompt forced them to think about it. Here is what real auth requires, what the AI gave you by default, and how to close the gap. | Layer | What the AI builder gives you | What is actually missing | | --- | --- | --- | | Login form | Email and password fields, an SDK call, a redirect | Nothing - this part works | | Roles and RBAC | A single "logged in" state | Admin, owner, member, viewer roles gated on the server | | Row-level security | Tables with RLS off by default | Policies so user B cannot read user A's rows | | Sessions and tokens | A token after sign-in | httpOnly cookies, expiry, server-side sign-out | | Password reset and email verification | A happy-path sign-up | Expiring single-use reset links, blocked unconfirmed users | | Social-login redirects | A "Sign in with Google" button | Production callback URLs, not localhost | --- ## Authentication Is Not Authorization These two words get collapsed into "auth," and that collapse is exactly where AI-built apps break. Authentication answers "who are you." It is the login form: verify a password, issue a session token, identify the user. AI builders are good at this part because it is a well-worn pattern with an SDK call at the center of it. Authorization answers "what are you allowed to do." Can this user read this row. Can they edit this record. Can they hit this admin endpoint. Should they see this project that belongs to a different account. Authorization is per-resource, per-role, and specific to your data model - which means there is no generic SDK call that does it for you. Someone has to decide the rules and enforce them on every read and write. Supabase's own documentation draws this line explicitly in its [Auth overview](https://supabase.com/docs/guides/auth): authentication verifies identity with a JWT, and authorization is enforced separately through row-level security policies on the database. The AI gave you the first half. The second half is a stack of decisions it never made. --- ## The Incognito Test: Find the Hole in 60 Seconds Before any of the fixes, confirm you actually have the problem. Most AI-built apps do. 1. Sign up as user A. Create some data - a project, an order, a note. 2. Open an incognito or private window. Sign up as user B with a different email. 3. As user B, load the same pages: the dashboard, the list view, the detail pages. If user B sees user A's data, your app has no authorization layer. The login worked; the access control does not exist. You can often shortcut this further: open your browser's network tab as user B, watch the API or database query the page fires, and check whether it filters by the current user's ID at all. If the query is `select * from orders` with no `where user_id = ...`, every signed-in user is reading the whole table. This is not a corner case. A February 2026 audit by VibeEval scanned 1,645 apps built with Lovable and found more than 170 - roughly 10% - had completely exposed databases with no row-level security enabled, leaking home addresses, financial data, API keys, and payment records ([Lovable security report, Feb 2026](https://vibe-eval.com/updates/lovable-security-report-feb-2026/)). The login forms on those apps all worked fine. We wrote about the broader pattern in [vibe coding security risks](/vibe-coding-security-risks). --- ## Row-Level Security: The Layer the AI Skipped The fix for the incognito test is row-level security, or RLS. Instead of trusting your application code to remember a `where user_id = ...` clause on every single query, you push the rule down into the database itself. The database refuses to return rows the current user is not allowed to see, no matter what query the app sends. Here is the trap: in Postgres - and therefore Supabase - tables created through the SQL editor or table editor have RLS **off by default**. The AI builder creates your `orders` table, RLS is disabled, and every authenticated request can read and write the entire table. The login form distracted you from the fact that the database door was never locked. A minimal policy looks like this: ```sql alter table orders enable row level security; create policy "users read their own orders" on orders for select using (auth.uid() = user_id); ``` The first line turns the lock on. The second says: a user can only `select` rows where the `user_id` column matches their authenticated ID. You repeat this for `insert`, `update`, and `delete`, and for every table that holds user data. Supabase's [row-level security guide](https://supabase.com/docs/guides/database/postgres/row-level-security) covers the policy syntax, the `auth.uid()` helper, and the performance patterns that matter once you have real traffic. Supabase also ships a project-level "Enable RLS on new tables" toggle - turn it on so the next table the AI creates is not born wide open. If you want the deeper mental model of how the JWT, the database, and the policies fit together, the [Supabase auth overview](https://supabase.com/docs/guides/auth) lays out the full picture. --- ## Roles and RBAC: When "Logged In" Is Not Enough The incognito test catches the worst hole. The next layer is roles. Most real apps have more than one kind of user. An admin who can see every account. A team owner who manages members. A read-only viewer. A regular member. "Is this person logged in" is a yes/no question; "is this person an admin" is a different question, and your AI builder almost certainly did not generate a role system because you did not ask for one in those words. Role-based access control, or RBAC, means you attach a role to each user and gate actions on that role. The admin dashboard checks for `role = 'admin'` before it renders. The "delete workspace" endpoint checks for `role = 'owner'` before it runs. The critical detail: these checks must live on the **server or in the database**, not in the frontend. Hiding the admin button in React stops nobody - the endpoint behind it is one `fetch` call away. Auth0's [RBAC documentation](https://auth0.com/docs/manage-users/access-control/rbac) describes the model of roles-to-permissions cleanly, and the same shape applies whether you use Auth0, Clerk, or roles stored in your own database and enforced through RLS policies. If you are on Clerk, route protection belongs in middleware so an unauthorized user never reaches the page handler at all. Clerk's [clerkMiddleware reference](https://clerk.com/docs/references/nextjs/clerk-middleware) shows how to protect routes by auth state and by role before the request hits your code. --- ## Sessions, Tokens, and the Reset Flow Nobody Tested Past roles, a cluster of edge cases decides whether your auth holds up in production. AI builders generate the happy path and stop. **Session and token handling.** When a user signs in, they get a token. Where does it live - an httpOnly cookie, or localStorage where any injected script can read it. Does it expire. Does signing out actually invalidate the session server-side, or does it just clear the client and leave a valid token in play. The default the AI picks is rarely the secure one. **Password reset and email verification.** The reset flow is a maze of edge cases: the reset link has to expire, it has to be single-use, and it must not let an attacker reset an account they do not own. Email verification has its own: what happens to a user who signs up but never confirms - can they still log in and use the app. AI builders frequently leave the "unconfirmed user" gap wide open. Supabase's [password-based auth guide](https://supabase.com/docs/guides/auth/passwords) walks through the confirmation and reset flows and the configuration that closes those gaps. **Social login redirects.** "Sign in with Google" looks trivial until you deploy. The OAuth redirect URL is hardcoded to `localhost`, or the production callback URL was never added to the provider's allowlist, and the whole flow dead-ends with a redirect error the moment a real user tries it. Supabase's [social login guide](https://supabase.com/docs/guides/auth/social-login) documents the redirect URL configuration that has to match between your provider and your deployed domain. --- ## What "Done" Actually Looks Like Run this checklist against your app. It is the difference between a login form and authentication you can put real users behind. - The incognito test passes: user B cannot see user A's data, on any page or API call. - RLS is enabled on every table holding user data, with policies for select, insert, update, and delete. - Roles exist if your product has more than one kind of user, and role checks run on the server or in the database - never only in the UI. - Sessions live in httpOnly cookies, expire, and invalidate on sign-out. - Password reset links expire and are single-use; unconfirmed users cannot access protected data. - Social login redirect URLs are configured for your production domain, not localhost. None of this is exotic. It is the standard, unglamorous work of access control - the 90% the demo never shows. The reason it stalls AI-built apps is not difficulty; it is that the model optimizes for the visible result, and a working login form looks like the finish line when it is barely the start. --- ## When the Gap Is Bigger Than a Weekend If your app already has users, fixing this is delicate. You cannot just flip RLS on across a live database and hope nothing breaks - a policy that is slightly too strict locks legitimate users out, and one that is slightly too loose leaves the hole open. Multi-tenant apps, team hierarchies, and role systems that have to coexist with data you have already collected are exactly where the 30-40% that AI builders skip turns into a real engineering project. This is the same wall on the payments side, where a working checkout button hides the unsexy correctness work underneath - we cover that in the companion piece on [adding Stripe payments to an AI-built app](/add-stripe-payments-to-ai-built-app). When the auth layer is the thing standing between you and launch, and retrofitting it cleanly is past a weekend's work, that is the kind of finish-the-hard-part problem [Creatr](https://getcreatr.com) was built to take off your plate - shipping the access control, the policies, and the role system as production code rather than a prompt you keep re-rolling. The login form was never the hard part. Now you know where the hard part actually lives. --- # https://getcreatr.com/add-stripe-payments-to-ai-built-app # How to Add Stripe Payments to an AI-Built App (Past the Checkout Button) Adding Stripe payments to an AI-built or no-code app: webhooks, idempotency, and database sync **The short version:** A working checkout button is the easy 10% - real Stripe billing is a database kept in sync with Stripe through verified, idempotent, retry-safe webhooks, with feature access driven by current subscription state. "Add Stripe payments" is one prompt. Your AI builder returns a checkout button, drops in a Stripe key, and on click it sends the user to a hosted Checkout page. You pay with the `4242 4242 4242 4242` test card, you land back on a success page, and money moves. It demos perfectly. Then a real customer pays, closes the tab before the redirect, and never gets access to the thing they bought. Another customer double-clicks the button and gets charged twice. A third refunds their purchase and keeps using the paid features for months. None of these show up in the demo, because the demo only ever walks the happy path. The checkout button is the easy 10%. The unsexy correctness work underneath is what decides whether your billing is trustworthy. Here is the real flow, what AI builders get wrong inside it, and how to test the parts that break. | Failure mode | What breaks | The fix | | --- | --- | --- | | Unverified webhook | Anyone can POST fake "payment succeeded" events | Verify the Stripe signature with constructEvent on the raw body | | Access on success redirect | A forged or skipped redirect grants or loses access | Grant access on the webhook, not the browser redirect | | No idempotency | A retry or double-click charges or records twice | Idempotency key on outbound calls, dedupe webhooks by event ID | | Payment state not synced | Your database drifts from what Stripe actually knows | Drive the database from webhook events as the source of truth | | Refund or chargeback | Revoked customers keep paid access forever | Gate features on current subscription state, not a one-time flag | --- ## The Success Redirect Is Not Proof of Payment The first wrong assumption almost every AI-generated Stripe integration makes: it grants access on the success-page redirect. The flow it generates looks like this. User clicks checkout, pays on Stripe, Stripe redirects to `yoursite.com/success`, and the success page code marks the order paid or unlocks the feature. Clean and intuitive, and wrong. The redirect is a client-side event. It happens in the user's browser, and the browser is not a reliable narrator. The user can close the tab the instant payment completes and never load the success page - they paid, they got nothing. They can also forge the redirect, hitting `/success` directly without paying at all and unlocking the feature for free. Tying fulfillment to the redirect means you both lose legitimate customers and hand the product away to anyone who reads a URL. Stripe is explicit that fulfillment belongs on the **webhook**, not the redirect. Its [fulfill orders guide](https://docs.stripe.com/payments/checkout/fulfill-orders) says to listen for the `checkout.session.completed` event and grant access there, treating the success page as a confirmation screen only. The redirect tells the user what happened. The webhook tells your server what happened, and only the server's version counts. --- ## Webhooks: The Source of Truth Your AI Never Wired Up A webhook is Stripe calling your server to say "this thing happened." Payment succeeded. Subscription renewed. Charge refunded. Card expired. These are the events that should drive your database, because they come from Stripe, not from a browser you cannot trust. When an AI builder does generate a webhook handler, two things are usually missing or broken. **Signature verification.** Your webhook endpoint is a public URL. Anyone who finds it can POST fake "payment succeeded" events at it and unlock paid features for free, unless you verify that each request genuinely came from Stripe. Stripe signs every webhook with a secret, and you verify it with `constructEvent` before trusting a single byte of the payload. AI-generated handlers routinely parse `req.body` directly and skip this entirely. Stripe's [webhook signature guide](https://docs.stripe.com/webhooks/signature) walks through `constructEvent` and the framework-specific catch that breaks it most often: you must verify against the **raw** request body, and many frameworks - Next.js included - parse the body to JSON before your handler sees it, which silently invalidates the signature. **Reliability and retries.** Stripe retries failed webhook deliveries, which is a feature, not a nuisance. If your endpoint is down or throws, Stripe will resend the event - so your server must respond `200` quickly and do the slow work afterward, and it must handle the same event arriving more than once. Stripe's [webhooks overview](https://docs.stripe.com/webhooks) covers retry behavior, event ordering, and why you return `200` first and process second. AI-generated handlers tend to do heavy database work inline and time out, which Stripe reads as failure, which triggers more retries, which compounds the next problem. --- ## Idempotency: The Reason One Payment Becomes Two Records Retries and double-clicks create the same hazard: the same operation runs twice. Without protection, that means two charges, or one payment recorded as two paid orders, or a subscription provisioned twice. There are two places to defend. On the **outbound** side - requests your app sends to Stripe - use an idempotency key. If a user double-submits and your server fires two "create charge" calls, an idempotency key tells Stripe they are the same operation, and the customer is charged once. Stripe's [idempotent requests documentation](https://docs.stripe.com/api/idempotent_requests) recommends a V4 UUID per logical operation and explains that idempotency applies to POST requests only. On the **inbound** side - webhooks Stripe sends you - assume every event can arrive more than once, because with retries it will. Before you act on `checkout.session.completed`, check whether you have already processed that event ID. Store processed event IDs, or make the database write itself idempotent (an upsert keyed on the Stripe object ID rather than a blind insert). AI-generated handlers almost always do a naive `insert`, so a single retried event produces two paid orders for one payment, and your revenue numbers stop matching Stripe's. The general rule: your database, not Stripe and not the browser, is the source of truth - but only once you have made the path to it safe against duplicates. --- ## Feature-Gating That Survives Refunds and Chargebacks Granting access on payment is half the job. Revoking it is the half AI builders forget exists. A customer pays, you flip `is_pro = true`, they use the product. Three weeks later they refund, or their bank issues a chargeback, or - for a subscription - their renewal card declines. If your code only ever listens for the "payment succeeded" event, that `is_pro` flag stays `true` forever. You are giving away paid features to people who are no longer paying, and you will not notice until you reconcile by hand. Feature-gating has to be driven by the **current subscription state**, synced from Stripe, not by a one-time "they paid once" flag. That means handling the full set of lifecycle events - `customer.subscription.updated`, `customer.subscription.deleted`, `invoice.payment_failed`, `charge.refunded` - and updating access accordingly. Stripe's [subscriptions overview](https://docs.stripe.com/billing/subscriptions/overview) maps the subscription statuses (`active`, `past_due`, `canceled`, `unpaid`) you need to react to. The correct mental model: store the subscription status in your database, update it from webhooks, and gate features on that status. Never trust a boolean that only one event can ever set. This is the same shape as the authorization problem on the auth side, where access has to reflect current state rather than a one-time grant - the companion piece on [adding authentication to an AI-built app](/add-authentication-to-ai-built-app) covers that wall. Both come down to: state changes, and your gates have to follow it. --- ## Tax and SCA: The Compliance You Cannot Prompt Away Two more pieces sit outside what any "add payments" prompt produces, and both are legal requirements, not nice-to-haves. And if your product does more than charge for your own service - moving money between users, reading bank data, or lending - you are building a fintech product, where compliance goes well beyond tax and SCA into KYC and licensing. We map those categories in [building a fintech app without code](/how-to-build-fintech-app-without-code). **SCA (Strong Customer Authentication).** European cards frequently require an extra verification step - a bank push notification, a 3D Secure challenge - mid-payment. If your integration does not handle the authentication-required state, those payments simply fail and you never learn why. Stripe Checkout and the Payment Element handle most of this for you, which is one concrete reason to prefer them over a hand-rolled card form an AI builder might generate; Stripe's [how Checkout works guide](https://docs.stripe.com/payments/checkout/how-checkout-works) covers what the hosted flow manages on your behalf. **Tax.** Depending on where you and your customers are, you may be obligated to collect VAT or sales tax. This is not something the model will surface unprompted, and getting it wrong is a liability that surfaces at filing time, not at checkout. Stripe Tax can automate the calculation, but you have to know to turn it on - the AI will not flag it, because nothing in "add Stripe payments" implies a tax obligation. Stripe's [set up Stripe Tax guide](https://docs.stripe.com/tax/set-up) walks through enabling it. --- ## How to Test the Parts That Break You cannot test webhook correctness by clicking the button and watching the success page - that only ever exercises the happy path. Use the Stripe CLI. `stripe listen --forward-to localhost:3000/api/webhook` forwards live test-mode events to your local handler and prints the webhook signing secret you need for `constructEvent`. Then `stripe trigger checkout.session.completed` fires a real event so you can watch your handler run end to end. Fire it twice and confirm you get **one** paid order, not two - that is your idempotency check. Trigger `charge.refunded` and confirm access is revoked. Trigger `invoice.payment_failed` and confirm a subscriber is downgraded. Stripe's [webhooks overview](https://docs.stripe.com/webhooks) documents the CLI workflow and the local testing loop. A short test matrix that catches most of the real failures: - Pay, then close the tab before redirect. Did the user still get access? (Tests webhook-driven fulfillment.) - Fire the same `checkout.session.completed` twice. One order or two? (Tests idempotency.) - POST a fake unsigned event to your webhook URL. Rejected? (Tests signature verification.) - Refund a payment. Access revoked? (Tests lifecycle gating.) - Let a subscription renewal fail. User downgraded? (Tests subscription-state sync.) --- ## What "Done" Looks Like, and When to Get Help Real Stripe integration is not a checkout button. It is a database that stays in sync with Stripe through verified, idempotent, retry-safe webhooks, with feature access driven by current subscription state. The button took one prompt. This took the rest of the work. If your AI builder got you the checkout flow and you are now staring at webhook signatures, double-charge bugs, and subscribers who refunded but never lost access, that is the predictable wall - the 30-40% that prompt-loop builders leave for you. We have written about why these tools [stall at the same point](/no-code-app-scaling-problems) regardless of which one you pick. When the billing correctness work is the thing between you and charging real money safely, that is the kind of finish-the-hard-part problem [Creatr](https://getcreatr.com) takes on - shipping the webhook handlers, the idempotency, and the subscription sync as production code you can trust with revenue. Money is the one part of your app where "looks like it works" and "actually works" have very different consequences. Build the boring layer underneath the button. --- # https://getcreatr.com/ai-app-builder-pricing-comparison-2026 # AI App Builder Pricing Comparison 2026: Lovable vs Bolt vs Replit vs Bubble vs Base44 Side-by-side 2026 pricing comparison of Lovable, Bolt, Replit, Bubble, Base44 and v0 AI app builders **Quick answer:** As of August 2026, the cheapest paid plans for AI app builders cluster between $16 and $32 a month: Base44 Starter around $16, Bolt Pro and Replit Core and Lovable Pro at $25, v0 Plus at $30 per user, and Bubble Starter at $32. Every one of them meters usage on top of that subscription - credits, tokens, or workload units - so the number on the bill scales with how much you build and run, not the sticker price. The right pick depends less on the headline number than on how each tool meters, and on whether you are pricing a prototype or a product. Pricing on all of these changes often, so treat every figure here as a snapshot and check the live page before you buy. There is no single "AI app builder price," because these tools do not sell you an app. They sell you capacity to generate and run one, metered in a unit that is easy to misread at signup. Two people on the same $25 plan can pay wildly different real totals depending on how much they iterate and how much traffic the app carries. So the useful comparison is not "which is cheapest." It is "which meters usage in a way that matches how I work, and what will the total actually be once credits, hosting, and the hard-to-finish last slice are included." That is what this guide lays out, starting with a single master table. --- ## What Do AI App Builders Actually Cost in 2026? Here is the side-by-side, current as of August 2026. Prices and limits on these platforms change frequently, so each row links to the live pricing page - verify before you commit. | Tool | Free tier | Cheapest paid plan | How usage is metered | Best for | | --- | --- | --- | --- | --- | | [Lovable](https://lovable.dev/pricing) | 5 build credits/day (max 30/mo) + 20 monthly cloud credits | Pro, $25/mo (100 credits/mo) | Credits per AI build action; cost varies with task complexity | Polished, UI-heavy front ends built fast | | [Bolt.new](https://bolt.new/pricing) | 300K tokens/day, 1M tokens/mo | Pro, $25/mo (10M tokens/mo, no daily cap) | AI tokens; larger projects burn more per message | Full-stack prototyping with real code access | | [Replit](https://replit.com/pricing) | Free daily Agent credits (Starter) | Core, $25/mo ($20/mo billed annually), $25 monthly credits | Agent usage / effort-based credits | Developers who want an IDE, agent, and hosting in one place | | [Bubble](https://bubble.io/pricing) | 50K workload units/mo | Starter, $32/mo ($29/mo annual), 175K WU | Workload units - server compute per query, workflow, and API call | Complex no-code logic without AI code generation | | [Base44](https://base44.com/pricing) | 25 message + 100 integration credits/mo (5/day cap) | Starter, ~$16/mo (annual) | Message credits to build + integration credits to run | Fast AI MVPs; now part of Wix | | [v0](https://v0.app/pricing) | $5 credits/mo, 7 messages/day | Plus, $30/user/mo ($30 credits/user) | Token-based across four model tiers | React/Next.js UI generation in the Vercel ecosystem | A few things the ranking hides, because they matter more than the order of the numbers. The $25 tier is a real cluster. [Lovable Pro](https://lovable.dev/pricing), [Bolt Pro](https://bolt.new/pricing), and [Replit Core](https://replit.com/pricing) all land there, and it is not a coincidence - it is the price the market has settled on for "one serious builder, enough capacity to make real progress." Base44's Starter is nominally cheaper at around $16 a month on annual billing, but its own guidance points most real projects to the Builder tier for custom domains, backend functions, and integrations, which lands it back near the others. Bubble's $32 Starter looks comparable but is a fundamentally different product: it does not generate code from prompts by default, it runs a visual programming environment, and its meter is server compute, not AI work. The free tiers are trials, not homes. Every free plan here is scoped to let you evaluate the tool, not to run anything real on it. Lovable's 30 credits a month, Bolt's 1M tokens, v0's seven messages a day - each is enough to answer "does this build what I want" and no more. We break down exactly what Lovable's free plan does and does not cover in [Lovable pricing 2026](/lovable-pricing-2026). Different meters are the whole story, so they get their own section next. --- ## How Does Each Tool Meter Usage - and Where Do the Bills Come From? This is the part the sticker price hides. Two builders on identical plans pay different totals because the meter runs on different things. Here is what each unit actually measures and where the surprise charges come from. | Tool | Meter unit | What runs the meter down | The gotcha | | --- | --- | --- | --- | | Lovable | Build credits | Each AI build action - a change, a deploy, a preview - not each message | Iteration and debugging burn credits faster than the prompt count suggests; complex work like row-level security costs the most | | Bolt.new | AI tokens | Syncing your project files to the model each message; larger codebase = more tokens per turn | A looping debug session can spend millions of tokens rewriting the same file; runtime AI features keep spending after you stop building | | Replit | Effort-based Agent credits | Agent work per task; harder tasks cost more credits | Cost is tied to effort, not a fixed per-message rate, so a stubborn feature is unpredictable to budget | | Bubble | Workload units (WU) | Every database query, workflow run, and API call your live app executes | The meter runs on end-user traffic, not just your building - a popular app consumes WU whether or not you touch it | | Base44 | Message + integration credits | Message credits to build; separate integration credits when the live app calls external services | Two meters, and the integration meter runs in production on real user activity | | v0 | Tokens across model tiers | Input and output tokens; the faster/stronger model tiers cost several times more per token | Picking a higher tier for quality multiplies token cost silently against your credit balance | Read the middle column twice, because it is where budgets go wrong. Lovable, Bolt, Replit, and v0 meter your building - you spend the unit while you are actively working, which means the cost tracks iteration. The tools that penalize iteration hardest are the ones you use for hard problems, because hard problems need more back-and-forth, not less. That is the trap in [Lovable's credit model at scale](/lovable-pricing-2026): the exact work that is expensive to build - auth, permissions, integrations that handle failure - is the work that eats the most credits per unit of progress. Bubble and the "integration credits" half of Base44 meter something different and more dangerous to forget: production traffic. Their meter keeps running when real users use the app, whether or not you are logged in. A Bubble app that gets popular consumes workload units on every query and workflow, so success raises your bill automatically. That is not a flaw - it is a usage-based model doing what it says - but it means the price you modeled while building is not the price you pay while running. Then there are the charges that sit outside the meter entirely: per-seat costs when a second person joins, marked-up API passthrough when the platform brokers your OpenAI or Stripe calls, support gated behind higher tiers, and the migration effort when you leave. We itemize all of those in [AI app builder hidden costs](/ai-app-builder-pricing-hidden-costs), and the exit cost specifically in [AI app builder vendor lock-in](/ai-app-builder-vendor-lock-in). None of them appear on the comparison table above. All of them appear on the bill. --- ## Why Is the Subscription Price Not the Real Price? The subscription is the price to prototype. It is not the price to ship. Those are two different numbers, and conflating them is the single most common pricing mistake founders make with these tools. Here is the mechanism. AI app builders get you to roughly 60 to 70 percent of a real product remarkably cheaply - the screens exist, the data saves, the demo convinces. For that stretch, the cost really is close to just the subscription plus your own hours, and the tools are genuinely excellent. If your goal is a prototype, an internal tool, or a validation build for a handful of trusted users, that may be the entire job, and you should not overpay for more. Our roundup of [the best vibe coding tools in 2026](/best-vibe-coding-tools-2026) covers which tool wins that prototype race. The gap opens on the last 30 to 40 percent, and it is not evenly hard. It is a specific list: real authentication and tenant isolation, permissions that never leak one account's data to another, integrations that survive a webhook arriving twice or an API timing out, data that stays correct under concurrent use, and the operational work of hosting, monitoring, and patching. That slice is where the metered cost spikes - because it is all iteration - and where the app either becomes real or quietly stalls. If you want the full picture of that failure mode, the [best no-code app builders comparison](/best-no-code-app-builders-2026) is honest about which categories of app hit the wall and which do not. So the real total for shipping stacks up in layers on top of the headline plan: - **The subscription** - the number on the pricing page, $16 to $32 for one builder. - **Metered overage** - the credits, tokens, or WU you burn past the plan's included allowance, which for active building routinely exceeds the base plan itself. - **Per-seat and passthrough** - a second editor, and any API costs the platform brokers at a margin. - **Hosting and runtime** - the meter that keeps running on production traffic after launch. - **The completion cost** - the weeks of hardening, or the developer you eventually hire, to finish the part the builder could not. A realistic B2B build on one of these platforms - a couple of editors, a few integrations, real users - lands closer to $135 to $160 a month than the headline $25, and that is before the completion cost, which is labor, not subscription. None of that makes AI builders a bad deal. For the speed they deliver, $150 a month is cheap. It makes "the price to prototype" and "the price to ship" two separate questions you should answer separately. --- ## How Should I Choose an AI App Builder by Budget and Stage? Match the tool to the stage you are actually at, not the product you imagine shipping. Here is the map. | Stage and budget | What you actually need | Best-fit picks | Why | | --- | --- | --- | --- | | Kicking tires, $0 | To answer "can this build my idea at all" | Any free tier - Lovable, Bolt, v0 | Free plans are built for exactly this and nothing more; do not pay yet | | Prototype for a demo, under $30/mo | Convincing screens fast, one builder | Lovable Pro or v0 Plus (UI-heavy), Bolt Pro (needs code access) | These win on speed to a polished front end; the meter is fine at prototype iteration volume | | Internal tool, real logic, ~$40/mo | Backend, integrations, a custom domain, real data | Base44 Builder, Replit Core, or Bubble | Base44 and Replit for AI-generated backends; Bubble when the value is complex workflow logic, not AI code | | Traffic-driven app, usage matters | A meter you can predict against real user load | Model the WU or token cost before committing | Success raises the bill on usage-metered tools; run the production math first | | Real users, real money, real data | 100 percent finished and hardened, not 70 | A managed build, or a builder plus a developer to finish it | The last 30 to 40 percent is not optional here, and no self-serve tool closes it for you | The pattern across the table is consistent: the further down you go, the less the subscription price matters and the more the meter and the completion cost dominate. At the top of the table, pick on speed and free-tier fit. In the middle, pick on how the meter behaves for your kind of work. At the bottom, the question stops being "which tool is cheapest" and becomes "who carries the hard 30 to 40 percent," because that is where the real money and real risk live regardless of which logo is on the invoice. Three honest rules of thumb before you buy: **Estimate the meter on a real feature, not a demo screen.** Build one representative feature from your actual project on the free tier and count the credits, tokens, or WU it consumes. Multiply by your feature count. That number, not the plan price, is your real monthly cost. **Price the production run, not just the build.** For anything with real users - especially Bubble, Base44 integrations, or any app with runtime AI - the meter keeps running after launch. Model the cost at the usage level you are trying to reach, not the level you build at. **Decide prototype vs product up front.** If you need to validate an idea, buy the cheap prototype and stop. If real money or sensitive data is involved, price for the full 100 percent from the start, because the completion cost is coming either way. --- ## Where Creatr Fits Creatr builds, hosts, and runs production-grade software for you, with the first build shipped in 24 hours and code you own outright. It sits in a different column than every tool in the table above, and it is worth being precise about where that difference is worth it and where it is not. The reason Creatr exists is the exact pattern this whole comparison is about: the first 60 to 70 percent of a product is now cheap and fast on any of these builders, and the hard, expensive, metered 30 to 40 percent - auth, tenant isolation, integrations that handle failure, data correctness, hosting, monitoring - is where projects stall and where the real cost hides. The self-serve tools hand that part back to you. Creatr is built to deliver the whole thing, finished and running, with humans in the loop rather than a meter you have to operate alone. So the honest fit test is the same one from the stage table. If you are prototyping, validating, or building an internal tool with a handful of trusted users, one of the builders above is very likely the right, cheap call, and you should use the pricing here to pick well. If you are at the point where the metered credit model is the wrong constraint - where the question is no longer "how many iterations to get the screen right" but "will this hold up for a hundred users with different roles and real data" - that is where a managed build changes the math. We will not claim to beat every agency on price, because that depends entirely on scope. What is different is the shape: no retainer, delivery in days, the first build in 24 hours, and code you own rather than rent. If that fits how you want to buy software, [start with Creatr](https://getcreatr.com). If it does not, the tables above still hold - use them to get an honest total from whichever tool you choose. --- # https://getcreatr.com/ai-app-builder-pricing-hidden-costs # AI App Builder Hidden Costs: What You Budget vs. What You Actually Pay **Quick answer:** The advertised $20-30 entry tier is a demo environment. Real production cost stacks up from credit or token overages, per-seat editor charges, marked-up API passthrough, paid support tiers, and migration effort at exit. A realistic B2B build runs closer to $135-160 a month than the headline price. Do the production math before committing, not in month three. Hidden costs of AI app builders in 2026 The plan was $25 a month. Three months later the credit card showed $140. No new features. No additional users. Just more usage of the same app, doing the same things it had been doing since week one. This happens consistently enough that there is a pattern to it. The pricing page shows you one number. The actual bill shows you a different one. The gap between them is not random - it comes from the same places every time. Here is where the money goes. --- ## The Starter Plan Is a Demo Environment Most AI app builders price their entry tier for evaluation, not production. $20 to $30 a month gets you enough to see whether the tool can build what you want. It is not designed to carry a real app with real users. The limits that bite first are usually not the ones you checked before signing up. [Lovable's free tier](https://lovable.dev/pricing) gives you 5 credits per day (we break the free plan down in detail in [Lovable pricing 2026](/lovable-pricing-2026)). Each meaningful edit consumes between one and five credits depending on complexity. A real build session - the kind where you are iterating on a feature rather than making cosmetic changes - can exhaust a day's allocation in an afternoon. The paid Starter plan at $25 a month gives you 100 credits per month. For a founder actively building, that goes in a week. Bolt charges by the day: $14 a month for 10 million tokens daily. That sounds like a lot until you learn that debugging a non-trivial feature can burn through several million tokens in a single session if the model is looping - rewriting the same code multiple times to get to a working state. A real build across three or four features can exhaust a day's allocation before you finish the second one. The entry tier works fine for building the first version. The moment you start maintaining it, debugging it, adding features in response to user feedback, or onboarding a second person to work on it - you are in upgrade territory. --- ## The Workspace Seat Tax The first person who is not you who needs to look at the project has a cost attached to them. [Lovable charges $25 per month per editor seat.](https://lovable.dev/pricing) One collaborator doubles the base subscription. Two collaborators triples it. For a small founding team - a technical and a non-technical cofounder who both want to review and edit - the $25 plan becomes $75 before any usage happens. Bolt has similar mechanics. The entry-level plan is single-user. Team plans start at a per-seat rate on top of the base subscription. This is the most predictable hidden cost because it is written in the pricing page. But it is invisible at signup because most founders sign up alone and assume they can add people later. They can. The price increases when they do. --- ## Token Overages at Production Usage AI builder platforms sell credit packages or token allocations. When you exceed them, there are two outcomes: the feature stops working until the billing period resets, or you pay overage charges. Both are bad in a production app. The specific issue with production usage is that it is constant. During development, you use credits when you are actively building. Once real users are interacting with the app - especially apps that use AI features, real-time data, or frequent API calls - the baseline consumption does not stop when you close the laptop. Bolt's pricing documentation acknowledges this: "apps that use external APIs or AI features may consume significantly more tokens during runtime." What this means in practice is that a founder who built a customer-facing feature that calls an external API on each user interaction is paying token costs they did not model when they planned the build. The math is not intuitive because you are used to thinking in terms of "how much does it cost to build this." The relevant question in production is "how much does it cost to run this, every day, at the usage level I'm trying to reach." The two numbers are different. --- ## The API Passthrough Problem Several AI builders let you connect your app to external services - OpenAI, Anthropic, Stripe, Twilio, Resend, and others. Some of these connections are handled at the platform level, which means the API costs route through the platform's billing rather than your own account. This is worth noticing for two reasons. First, you often pay a markup. The platform negotiates rates with the API providers and passes them through at a margin. For low-volume usage this is invisible. For apps that make frequent API calls - generating text, sending emails, processing payments - the markup accumulates. Second, you lose visibility. When your Stripe or OpenAI usage routes through a platform's billing system rather than your own accounts, you cannot see the raw consumption in the provider dashboards. You see the platform bill. Understanding which features drive costs requires reverse-engineering the allocation from the platform's analytics, if those exist at all. The alternative - connecting external APIs through your own accounts rather than the platform's - is often available but requires configuration that most founders do not know to ask about. The platform defaults to its own integration because that is simpler at setup time and generates additional revenue at scale. --- ## Support Tiers That Gate Basic Help The AI builder category has normalized charging separately for the kind of support that used to come with a software subscription. Lovable's free and Starter tiers get community support - forums, Discord, documentation. Email support is on the Pro tier. Priority support is on the Teams tier. If you have a production issue at 11pm that is blocking paying customers, the path to getting someone who can help is through a tier you may not have paid for. This structure makes sense from the platform's perspective. Support is expensive. Charging for it separately allows lower base prices. From the user's perspective, it means that the price you see on the pricing page assumes self-service troubleshooting is sufficient. For a founder with technical depth, it often is. For a non-technical founder whose entire app is running on the platform, a production outage with no support path is a different kind of problem. --- ## The Export and Migration Penalty This one is not on the monthly bill. It shows up when you want to leave. Lovable's projects are tied to the Lovable platform and its Supabase integration. Exporting your code is possible - the option exists - but what you get is a React codebase with dependencies on Lovable's build pipeline and Supabase-specific configurations. Moving that code to a different host, or handing it to a developer to extend, requires effort proportional to how deeply the platform-specific assumptions are embedded. Bolt exports cleaner code in some respects because it is more framework-agnostic. But the same general dynamic applies: code written inside an AI builder environment carries implicit assumptions about the environment it was built for. Running it somewhere else requires auditing and often rewriting those assumptions. The exit cost is not priced. It is also not zero - it is the [vendor lock-in](/ai-app-builder-vendor-lock-in) that nobody models at signup. Founders who build on these platforms as their primary production environment and later need to hand the codebase to an engineering team or migrate to a different infrastructure face a bill that was never visible in the monthly pricing comparison. --- ## What the Realistic Number Looks Like Running the math on a real production scenario: A B2B SaaS with 50 active users, two founders who both access the codebase, three external API integrations, and monthly feature development: - Base subscription: $25 - Second editor seat: $25 - Usage overage (monthly iterations + production traffic): $40-60 - API passthrough markup on modest usage: $15-20 - Support tier upgrade: $30 (if needed) Total: $135-160 per month This is not a scam. These are real costs for real usage. The issue is that the pricing page number and the production number are not the same number, and the gap between them is not visible until you are already past it. The founders who avoid bill shock are the ones who did the production math before committing, not the ones who signed up on the entry tier and hoped it would scale. --- ## The Right Comparison None of this means AI builders are overpriced. For the speed they deliver and the alternatives they replace, $150 a month is cheap. A freelancer hour costs more than that. The mistake is comparing the pricing page to free, rather than comparing the full production cost to [the actual alternatives](/ai-app-builder-vs-development-agency). When you model it correctly - full subscription cost, API costs, seat costs, and the exit costs if you ever need to move - the picture is more expensive than the headline and still competitive with what it replaces. What it is not competitive with is "free." There is no version of a production app that costs $25 a month forever. Plan for the real number from the beginning and the cost is manageable. Discover it in month three and it feels like the platform changed the deal on you. It did not change the deal. The deal was always on the pricing page in the tiers below the one you read. --- # https://getcreatr.com/ai-app-builder-vendor-lock-in # AI App Builder Vendor Lock-In: What Happens When the Platform Disappears **Quick answer:** Vendor lock-in on AI builders runs across four dimensions - data, code, integrations, and knowledge. Exported code carries hidden assumptions about the platform's environment, and platform-abstracted integrations are not portable. Builder.ai's collapse showed the exit window can close fast. Reduce it by using standard integrations, connecting your own Supabase and Stripe accounts, and periodically running the export yourself before you need to. AI app builder vendor lock-in risks 2026 [Builder.ai raised $450 million.](https://techcrunch.com/2025/05/20/once-worth-over-1b-microsoft-backed-builder-ai-is-running-out-of-money/) In 2024, it collapsed. Not from lack of product. Not from a sudden market shift. From internal financial mismanagement that became impossible to hide when the company tried to raise its next round. The investors who discovered that the company had been misrepresenting its financial position walked away. The company filed for administration. The customers whose apps were running on Builder.ai's infrastructure had days to figure out what to do. Builder.ai was not a small experiment. It had thousands of business customers who had paid for apps that ran on its platform. When the platform went away, those apps went with it. The risk of building on any single platform is real. In the AI builder category in 2026, it is more real than it has been in most software categories in recent history, because the category is new, well-funded by investors who expect large returns, and consolidating rapidly. Not every platform that exists today will exist in three years. Here is what vendor lock-in actually means for founders who build on AI platforms, and what it costs when the platform changes. --- ## The Four Lock-In Dimensions ### 1. Data Lock-In Where does your data live, and can you get it out? This question sounds simple but the answer is often more complicated than the platform's documentation suggests. Most AI builders use managed databases - typically Supabase, but sometimes proprietary storage - that are configured by the platform and accessed through the platform's APIs. The data is yours in the legal sense: the terms of service say you own it. The practical question is what you need to do to get it into a format that another system can use. Supabase offers direct database access, which means data portability is relatively straightforward if you know how to export a PostgreSQL database. But many founders who use Lovable or Base44 with Supabase integration have never connected to their Supabase instance directly - they interact with data only through the platform's interface. In an exit scenario, the ability to access that data depends on the platform remaining operational long enough for you to run the export. If the platform disappears suddenly - not an orderly shutdown but a collapse, as in Builder.ai's case - the access window may be short. Founders who had not thought about data portability often discover the problem after it is already a crisis. ### 2. Code Lock-In Can you run your app without the platform? Lovable exports React code. The code is real and it is yours. But the code was built against the platform's Supabase configuration, with API routes that depend on the platform's build pipeline, and components that assume the platform's deployment environment. Running it somewhere else requires more than copying files - it requires understanding what the code assumes about its environment and reconfiguring those assumptions. Bolt exports cleaner code in the sense that it is less opinionated about deployment. But the same general principle applies: code written inside an AI builder inherits structural assumptions about the environment it was built in. Those assumptions are not documented. They are embedded in the code. Discovering and removing them takes time proportional to how long the app has been in development. The test is not whether you can export the code. It is whether you can run the exported code somewhere else without the platform's support. Most founders who have tried this find the answer is: with significant effort. ### 3. Integration Lock-In What connections are proprietary versus standard? AI builders handle external service integrations through their own abstraction layers. The authentication integration that "just works" in Lovable works because Lovable has built and maintains a specific connection between its platform and Supabase's auth service. If that connection changes or disappears, your app's authentication changes or disappears with it. The same applies to payment integrations, email services, and anything else the platform connects for you. These integrations look like your integrations. In practice they are the platform's integrations that you are using. The distinction matters when the platform is not there to maintain them. Standard integrations - building directly against Stripe's API, directly against Resend's API, directly against your database's native connection - are portable. Proprietary abstractions are not. ### 4. Knowledge Lock-In Who understands how the app was built? This is the lock-in dimension that gets the least attention and causes the most damage. An app built with an AI builder was built by a model making decisions that were not logged, not explained, and not taught to the founder. The founder knows what the app does. They do not know why the code is structured the way it is, which architectural decisions were made and which were deferred, or what assumptions the code makes about its operating environment. When something goes wrong - a bug in production, a security issue, a need to extend the app beyond what the tool can generate - the founder is dependent on the tool to fix it. If the tool is unavailable, they are dependent on a developer who has to reverse-engineer a codebase they did not write and was not documented. This knowledge gap is not unique to AI builders - any codebase built by contractors who are no longer available has the same problem. But it is more acute with AI-generated code because the decisions embedded in the code were often not decisions in the conscious sense: they were the model's defaults, applied without explanation. --- ## What Platform Risk Looks Like in Practice The Builder.ai collapse was an extreme case. The more common version is slower and less dramatic. **Acquisition:** The platform gets acquired by a larger company. The roadmap shifts to serve the acquirer's strategy rather than the original user base. Features that were the reason you chose the platform get deprioritized. Support quality declines as the team gets absorbed. The platform technically still exists, but the version you built on is no longer the version being maintained. This is what happened with Base44 after the [Wix acquisition](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/). **Pricing change:** The platform raises prices. Not catastrophically - just enough that the economics of your app change materially. The monthly cost that was reasonable at $50 is not reasonable at $300. The feature tier you need has moved to a higher plan. You are now paying more for the same product, and migrating costs more than the price increase. This is the trap: the migration cost is high enough that you stay and pay, even when the new price is not the price you signed up for. **Feature removal:** The integration you depend on gets deprecated. The authentication method the platform supports stops being supported. The framework version the platform uses gets too far behind the framework's current state to maintain. You are now running on a stale version of a dependency with no upgrade path provided by the platform. **Platform shutdown:** The orderly version of Builder.ai: the platform gives 90 days notice and shuts down. You have time to migrate. You also have to do it on the platform's timeline, not yours. If you are in the middle of a fundraise, a customer contract, or a launch, 90 days may not be the time you wanted to spend migrating infrastructure. --- ## The Questions to Ask Before You Build Not all of these are dealbreakers. Some of them are acceptable risks depending on the stage of your product and how dependent on the platform you intend to be. But they are the questions that determine what your exit costs look like. **Can I export my data to a standard format without the platform's help?** If the answer requires the platform to be operating and cooperative, that is a meaningful constraint. **Can I run the exported code without the platform's infrastructure?** Test this before you go deep, not after. Take a recent export and see what it takes to run it on a generic cloud host. If you cannot figure it out in a few hours, the exit cost is higher than it looks. **Are my external integrations built directly against the provider's API, or against the platform's abstraction?** Direct API connections are portable. Platform abstractions are not. **What is the platform's financial position?** This is harder to assess for private companies, but some signals are available: recent funding announcements, public financial reporting if the company has any, the trajectory of the team size, and whether the company is growing or contracting based on public information. A platform that raised significant funding two years ago and has not raised since is in a different position than one that raised recently. **What does migration actually cost?** Not the theoretical migration cost - estimate it concretely. How many hours of developer time to take the exported codebase and make it run independently? What data migration would be required? What integrations would need to be rebuilt? Put a number on it. If the number is larger than the annual subscription cost, you are more locked in than the pricing suggests. --- ## Building With Portability in Mind The practical implication is not to avoid AI builders. It is to build in ways that reduce lock-in depth without sacrificing the speed advantage that makes the category useful. Use standard integrations where they exist. Connect to Stripe directly through their SDK rather than through the platform's payment wrapper. Set up email through your own Resend or Postmark account rather than the platform's relay. Connect to your own Supabase project rather than the platform-provisioned one. The additional setup time is small. The portability gain is significant. Export and run your code periodically. Not just when something goes wrong - as a regular practice. Set up a minimal cloud environment and verify that the export runs. This takes an afternoon the first time and less thereafter. It also tells you exactly what the exit cost is before you need to know under pressure. Keep the data model documented. Write down what your tables are, what the relationships are, and what the key business rules are. This documentation does not need to be comprehensive - it needs to be sufficient for a developer to understand the structure without reading every line of code. The knowledge lock-in problem is partly solvable by externalizing the knowledge that would otherwise be trapped inside the AI builder's context. The platforms that will survive and grow are the ones that build toward portability rather than against it. Open code, standard integrations, and data that lives in standard databases are signs of a platform that is confident in its value proposition. Proprietary formats, data export friction, and integration abstractions that cannot be bypassed are signs of a platform that knows its value proposition weakens when you can leave. Build with the exit in mind. You may never need it. When you do, you will be glad you thought about it before the platform gave you a deadline. --- # https://getcreatr.com/ai-app-builder-vs-development-agency # AI App Builder vs Hiring a Development Agency: The 2026 Cost Breakdown **Quick answer:** Use an AI builder (Lovable, Bolt) for a fast, cheap prototype - roughly $200-400 in tool cost plus 60-120 hours of your time - accepting likely security and architecture gaps. Hire an agency ($15,000-150,000, 2-6 months) when you need an accountable, production-ready system. The real comparison is total cost to production and rebuild risk, not the headline tool price versus agency invoice. AI app builder vs development agency cost comparison 2026 In early 2026, a founder in the UK spent fourteen weeks and $47,000 with a nearshore development agency building an internal operations tool. The spec was clear. The agency was professional. The timeline slipped twice - two weeks for scope clarification, three weeks for a senior developer who left mid-project. The delivered app covered about 80% of what was specified. The remaining 20% required a change order that would have cost another $12,000 and six weeks. The founder shelved it and started looking at AI builders. Three months later, a different founder used Lovable to build a client-facing dashboard over a weekend for approximately $40 in tool costs. The app worked beautifully in the demo. Four weeks later, when three clients were using it simultaneously and one of them reported that they could see another client's data, the founder discovered that row-level security had never been enabled. The fix required a rebuild of the data access layer. The "weekend app" cost three additional weeks of debugging and two client relationships. Both founders made reasonable decisions given what they knew at the time. Both got outcomes they did not expect. The comparison between agency and AI builder is one of the most consequential decisions a non-technical founder makes, and most of the available guidance presents it as a cost comparison when it is actually a risk comparison dressed up as a cost question. This post does the real math on one specific project type, across all realistic build paths, so you can make the comparison honestly. --- ## The Project We Are Pricing Rather than speaking in generalities, pick one specific project: a B2B SaaS with user authentication, a dashboard, Stripe billing, and three user roles - admin, standard user, and read-only viewer. This is not a complex project by software development standards. It is an extremely common starting point for B2B founders. The auth system needs to support email and password login, password reset, and session management. The dashboard needs to display data specific to the logged-in user's role. The Stripe integration needs to handle subscription creation, the payment webhook that activates access, the customer portal for managing billing, and subscription cancellation. The three user roles need different access levels enforced at the data layer - admin sees everything, standard user sees their own data and can take actions, read-only viewer sees their own data without action capabilities. This is the kind of app that takes a developer familiar with the stack two to three weeks to build correctly. It is the kind of app that takes a junior developer two to three months and still has gaps. It is the kind of app that AI builders can produce a convincing prototype of in a day - and a production-ready version of in something closer to a week with the right approach. The question is not which approach gets you to a demo the fastest. The question is which approach gets you to a production system that works correctly, at what total cost, in what time, with what risk. --- ## Path One: US Development Agency A US-based development agency billing at $150-250 per hour for a project of this scope will typically quote a fixed-price engagement. [Fixed-price quotes for this type of app](/custom-software-development-cost-2026) range from $50,000 to $150,000 depending on the agency's market position, the thoroughness of the spec, and how much discovery work happens before the quote is written. The $50,000 floor is a basic implementation from an agency that has built this stack before and can work efficiently from a clear spec. The $150,000 ceiling is an agency that includes a discovery phase, architecture review, security audit, QA, documentation, and ongoing support retainer. The timeline from signed contract to deployed production system runs 3-6 months. Three months is achievable if the spec is complete, no requirements change, and no team disruption occurs. Six months is the realistic median when you account for the two-week spec refinement cycle that almost every project goes through, the typical one-week pause when a key developer is on leave, and the QA and revision cycle at the end of the build. What you receive for the agency cost, at the high end: a production-deployed system built by developers who have answered for similar projects before, security review baked in, documentation you can hand to a future developer, accountability if something breaks in the first 90 days. What you receive at the low end of the agency range: a production-deployed system built to spec, probably with adequate security, minimal documentation, and a support relationship that ends when the retainer does. The number most founders do not track: the founder's own time during an agency engagement. A three-month agency project requires roughly 40-80 hours of founder time across the engagement - spec review, feedback cycles, demo reviews, revisions, launch coordination. At a $100 opportunity cost per founder hour, that is $4,000-8,000 in economic value that did not show up in the agency invoice. --- ## Path Two: Nearshore or Offshore Agency A [nearshore agency in Eastern Europe, Latin America, or Southeast Asia](/nearshore-software-development-guide-2026) billing at $30-80 per hour produces dramatically lower project costs. The same B2B SaaS with auth, dashboard, Stripe, and three user roles comes in at $15,000-40,000 at this rate range, with a timeline of 2-4 months. The cost difference is real. The coordination overhead is also real. Working across time zones adds a communication latency that does not exist in a co-located or same-timezone engagement. A question that takes 20 minutes to resolve with a US-based agency takes 24 hours to resolve through asynchronous messages with a team 8 hours ahead. Over a 3-month project, this latency compounds. Spec ambiguities that a US agency would catch in a same-day call become week-long clarification threads with an offshore team. Accountability also differs. A US-based agency has a reputation in a market where your investors and future developers might know them. An offshore agency you found on a platform has less inherent accountability - the relationship is primarily transactional, and the leverage if something goes wrong is limited. The quality range is also wider. The best nearshore teams produce work that is indistinguishable from US agencies and costs 50-70% less. The worst produce the same structural problems as vibe-coded apps - missing security layers, no documentation, architectures that cannot evolve - at a cost that looks attractive until the rebuild cost arrives. The $15,000-40,000 price range is real. So is the variance in what you receive for it. --- ## Path Three: Freelancer A [freelance developer billing at $50-150 per hour](/hire-app-developer-cost-2026) puts the same project at $8,000-45,000 depending on rate and efficiency. The cost case for freelancers is real but the accountability structure is the weakest of any option. A freelancer who leaves mid-project leaves you with code only they understand. A freelancer who underestimates the project - which happens in roughly half of fixed-scope freelance engagements, because freelancers price optimistically to win the work - either absorbs the loss and delivers something incomplete, or comes back with a change order that erases the cost advantage. Freelancers are also typically specialists. A strong frontend developer who takes on a full-stack project will be weaker on the backend. A strong backend developer will produce a system that works correctly and looks rough. The three-role Stripe integration requires breadth across auth, billing, and data access that a single specialist may not have evenly. The coordination risk is also higher than with agencies. A two-person agency has internal redundancy. A solo freelancer has none. When a freelancer gets sick, takes a trip, or gets a better offer, your project pauses. Freelancers are the right choice when you have a specific, bounded piece of work - adding a feature to an existing system, migrating a database, building one integration - and when you have enough technical literacy to review the work and hold the freelancer accountable. For a greenfield production app, the coordination and accountability risk frequently offsets the cost advantage. --- ## Path Four: AI Builder (Lovable or Bolt) The headline cost of building a B2B SaaS on Lovable or Bolt is dramatically lower than any of the above options. [Lovable Pro at $25 per month](https://lovable.dev/pricing), Bolt's token-based pricing at $20-50 per month for an active build - the tool cost for a complete app is $200-400 in the first month and ongoing. This is real. The tool cost is genuinely low. What the tool cost does not include is founder time. A non-technical founder building a B2B SaaS with auth, Stripe, and three user roles on an AI builder typically spends 20-40 hours on a straightforward build. On a complex build - one where the roles have nuanced access rules, the Stripe integration needs to handle edge cases, or the data model is non-trivial - the time runs 60-100 hours. At $100 per hour of founder opportunity cost, the economic cost of the build is $2,000-10,000 in founder time, not $200-400. This is not a hypothetical number. It is the economic value of what the founder could have been doing instead of prompting, debugging, and re-prompting. For a founder whose time genuinely costs $100 per hour in opportunity, building a 60-hour app on an AI builder costs $6,000 in economic value whether or not any cash changed hands. The structural risk compounds the economic calculation. The 88% RLS-disabled finding from the 2026 vibe-coded app audit means that a B2B SaaS with three user roles, built on Lovable or Bolt without explicit security configuration, has an 88% chance of shipping without the data access layer that makes three user roles actually work correctly. The Stripe integration built from the happy-path prompt - card charged, subscription activated - has no retry logic, no idempotency, and no webhook signature verification. These are not features you can add with a follow-up prompt. They require architectural decisions that have to be made before the data model exists. The realistic cost of building this specific app on Lovable or Bolt to a production-ready standard - with RLS configured correctly, Stripe integration built for failure cases, three user roles enforced at the database level - requires either deep expertise to validate and fix the AI builder's output, or a rebuild when the structural gaps surface in production. Neither cost appears in the tool subscription. --- ## The Hidden Number Nobody Counts: Time to Production The cost comparison above focuses on direct costs. The more important comparison for a founder is time to production - how long until the system is actually running the business. A US agency engagement that takes 5 months to deliver a production system means 5 months of operating your business without the tool. If the tool would generate $5,000 per month in operational efficiency or revenue, 5 months of delay is $25,000 in foregone value. That number does not appear in the agency invoice. It appears in the bank account. The AI builder that produces a working prototype in two days but requires 6 weeks of debugging to reach production security standards took 6 weeks plus two days to reach production - not two days. The "two days" number that gets quoted in launch threads is the time to demo, not the time to production. For the specific project we are pricing - B2B SaaS, auth, dashboard, Stripe, three user roles - realistic time-to-production across paths: US agency: 3-6 months. This is the range across the actual distribution of similar projects. Nearshore agency: 2-4 months. Lower cost, similar timeline, higher coordination overhead. Freelancer: 1-4 months. High variance depending on freelancer competence and availability. AI builder (self-managed): 1-12 weeks for a production-ready system. Two days to prototype. 6-10 weeks to production if the architectural gaps surface and require rebuilding. 1-2 weeks if you have the expertise to configure security and integration correctly from the start. A production-grade delivery service - one that takes requirements from the founder, makes the architectural decisions before building, and delivers a deployed system - runs 1-2 weeks. The comparison is not between demo speed (AI builder wins) and production quality (agency wins). It is between the total time from "I want to build this" to "this is running my business correctly." --- ## What You Actually Get From Each Path The comparison most founders make is cost versus speed. The more useful comparison is what you receive for each option, specifically the things that are not visible in the output. From a US or nearshore agency: accountability. If something breaks in the first 90 days of a properly scoped engagement, there is a relationship and a contract to invoke. From a freelancer: specialization within their domain, and a lower cost if you can manage the coordination risk. From an AI builder: speed and control - the ability to iterate, change direction, and own the codebase without waiting for anyone. What you do not get from an AI builder: architecture review. No one looked at the data model and asked whether it can handle the queries the app will actually need to run at scale. No one reviewed the access control logic and verified that role enforcement is complete across every endpoint. No one audited the integration handlers and confirmed they handle the failure cases. These reviews happen in agency engagements because the agency has seen what breaks in production and builds defensively from that experience. They do not happen in a solo AI builder session because the tool does not have the context to know what to review. What you do not get from an agency that you get from an AI builder: control. An agency-built system is documented (ideally), but the institutional knowledge of why it was built the way it was built lives in the heads of the developers who built it. Every time you want to change something, you are dependent on those developers - or on new developers who have to reverse-engineer the decisions. An AI builder session produces a codebase you own and can modify. Whether you can modify it correctly is a function of your technical literacy, but you own it. The meaningful question is not "which path is cheapest" but "which path gets me to a production system that runs my business, at a total cost I can absorb, in a time frame that fits my roadmap, with a risk profile I can manage." --- ## The Total Cost to Production: An Honest Comparison For the specific project - B2B SaaS, auth, dashboard, Stripe, three user roles - here is the honest version of the comparison. US agency, mid-market: $60,000-80,000 total spend, 4-5 month timeline, production-ready delivery with security review, accountability structure, minimal documentation. Founder time: 50-60 hours across the engagement. Economic cost including opportunity cost: $65,000-86,000. Nearshore agency, quality tier: $20,000-35,000 total spend, 2-4 month timeline, production-ready delivery if you selected well, higher coordination overhead, variable documentation. Founder time: 60-80 hours. Economic cost: $26,000-43,000. Freelancer: $12,000-35,000 total spend, 2-3 month timeline with high variance, quality and completeness dependent on individual, accountability risk. Founder time: 40-80 hours. Economic cost: $16,000-43,000. AI builder (self-managed, non-technical founder): $200-400 tool cost, 2-10 week timeline to production depending on structural complexity, significant founder time investment, high probability of architectural gaps requiring rebuild. Founder time: 60-120 hours. Economic cost including opportunity cost: $6,000-12,400. Rebuild risk: if structural gaps require a rebuild, add $15,000-30,000 to those numbers and 4-8 additional weeks. A production-grade delivery service - structured requirements process, architectural decisions made before building, deployment included - runs at a cost point significantly below the mid-market agency range, with a timeline measured in days rather than months. The output is owned code running on your infrastructure, not a platform dependency. The difference from an AI builder is that the architectural decisions were made deliberately, by people who have seen what breaks in production, before the build started. --- ## The Rebuild Cost: The Number That Changes the Calculation Every comparison between AI builders and traditional development paths needs to account for the rebuild cost - the cost of fixing structural gaps that were not caught before launch. The rebuild cost is real and it is not rare. The 2026 Altar.io comparison of five AI builders found all five produce code at 60-70% of a real product. The remaining 30-40% - access control, integration failure handling, data model correctness - requires either a developer to retrofit or a rebuild. Retrofitting access control on a data model that was not designed for multi-tenant isolation is expensive. Adding row-level security policies to tables that were built without user ownership baked in requires schema changes, data migration, and validation that the new policies work correctly without breaking existing functionality. Doing this to a live production system, with real user data, is significantly harder than designing it correctly from the start. The cost of retrofitting the Stripe integration to handle failure cases on a system where the happy-path integration is already live, with paying customers on it, involves doing development work that cannot be tested against production without risk. A Stripe webhook handler that incorrectly processes an event in production is not a test environment problem - it is a live billing problem. The rebuild cost that founders rarely include in their AI builder math: 40-80 developer hours at $100-200 per hour to address the structural gaps that surface after launch. That is $4,000-16,000 in addition to the tool cost and founder time. For founders who find those gaps before serious users are on the system, it is an annoying expense. For founders who find those gaps through a user reporting that they can see another user's data, it is a crisis. --- ## What the Honest Comparison Looks Like The founder trying to decide between paths is rarely comparing identical outcomes. An agency build and a well-executed production delivery are both correct production systems. A self-managed AI builder build and a production delivery are starting from different foundations. The right comparison is: given this specific project, this specific timeline, this specific risk tolerance, and this specific budget, which path produces a production system running my business, correctly, in the time I have? A founder with $80,000, a 6-month timeline, and zero technical literacy who needs a production-grade system they can hand to an enterprise sales team without embarrassment should hire a US agency or a quality nearshore agency. The accountability structure and the formal delivery process are worth the premium. A founder with $20,000, a 2-month timeline, and some technical literacy who needs a production system they control completely should consider a structured delivery service that makes the architectural decisions before building and delivers owned code at significantly below agency cost. A founder with $500, a 2-week timeline, and high technical literacy who needs a prototype they can test with early users before committing to a production build should use Lovable or Bolt with clear eyes about what they are producing - a prototype, not a production system - and plan the production build separately. The mistake is conflating these three use cases. The AI builder cost in the third scenario does not apply to the first scenario. The agency accountability in the first scenario is not available in the third. The decision about which path to take should be made based on the full picture - total cost to production, total time to production, risk of needing to rebuild - rather than headline tool cost versus headline agency invoice. The UK founder who spent fourteen weeks and $47,000 on an agency build that delivered 80% of the spec made a reasonable decision with available information. The founder who built a client-facing dashboard in a weekend and discovered the data isolation gap four weeks later also made a reasonable decision with available information. Neither decision was wrong given what was visible at the time. The information that would have changed the calculation - the realistic total cost to production for each path, including founder time, rebuild risk, and structural gap probability - was not available in a form either founder could use when they needed it. --- # https://getcreatr.com/airtable-alternatives-2026 # Airtable Alternatives in 2026: What to Use When It Becomes Your App's Backend Airtable alternatives 2026 **Quick answer:** If you are using Airtable as a project tracker, stay on Airtable. This guide is for the other use - the one where Airtable quietly became the database behind a customer portal, an internal tool, or a small app. For that, the honest options are Tadabase, NocoDB, Baserow, and Lovable plus Supabase. Each fixes part of the problem. If you want a real app on a real database that your team actually owns, a managed build like Creatr ships that as production code rather than another platform to outgrow. Airtable is a great spreadsheet-database hybrid. The trouble starts when a base stops being a list and becomes the system of record behind something people log into. A vendor portal. A client-facing dashboard. An internal ops tool built on Softr or Glide sitting on top of an Airtable base. The base was never designed to be a backend, and at a certain scale that shows. This post is scoped tightly to that intent: Airtable used as an app's backend, not Airtable as an Asana or monday competitor. If your problem is task management, you are reading the wrong roundup. | Alternative | Best for | Where it walls | | --- | --- | --- | | Tadabase | No-code web apps with real roles | Still a hosted platform you rent | | NocoDB | UI over an existing SQL database | You own the DB, not the app layer | | Baserow | Open-source self-hosted base + apps | Ops burden, you build the app | | Supabase + Lovable | Real Postgres with a generated app | Prompt-built code needs hardening | | Creatr | Owned production app on real DB | Higher cost, longer than a weekend | ## How Airtable Became Your Backend Almost nobody decides to build an application on Airtable. It happens by accretion. You start with a base to track a few records. Someone connects [Softr](https://www.softr.io/data-sources/airtable) or [Glide](https://glideapps.com) to give non-technical users a clean front end with login pages. Now external people read and write to your base through a portal. Then sales wants their own view, customers want theirs, and finance wants a third. The base is now a multi-tenant application backend that nobody architected as one. This is a real pattern, not a strawman. Softr's own marketing is explicit about it: turn Airtable data into a custom client portal with user authentication and white-labeled domains. The frontend tools are good. The issue is the layer underneath them. ## The Three Walls You Actually Hit **Record limits.** Airtable caps records per base by plan. As of 2026 the Free plan allows 1,000 records per base, Team allows 50,000, Business allows 125,000, and Enterprise Scale allows 500,000, per [Airtable's pricing page](https://airtable.com/pricing). That ceiling is per base and cumulative across tables. An app that logs events, stores order lines, or keeps an audit trail burns through 50,000 records faster than a tracker ever would. When you hit the cap, Airtable stops letting you add records until you upgrade a tier - which on a per-seat plan is a real cost jump, not a rounding error. **Permission gaps.** Airtable's access model is built around collaborators on a workspace, not end users of an application. There is no native concept of "this customer can see only their own rows and nothing else" enforced at the data layer. Frontend tools like Softr bolt user authentication on top, but the filtering happens in the presentation layer. The base itself does not know who the end user is. For anything touching sensitive data, "the UI hides it" is not the same as "the database refuses to return it." **Data correctness.** A spreadsheet is forgiving by design. It will happily store a phone number in a date field, two records that should be one, or a linked record that points at nothing. That forgiveness is a feature for a tracker and a liability for a backend. There are no enforced foreign keys, no schema-level constraints, no transactions across tables. When two automations write at once, or a webhook fires twice, the base has no way to refuse the bad state. ## If You Want No-Code With Real Roles: Tadabase [Tadabase](https://tadabase.io/) is the most direct answer to the permission wall. It is a no-code platform built specifically to make database-driven web apps, and roles are a first-class concept rather than an add-on. You define roles like admin, sales, and customer, then control access at the layout, page, and row level. Per [Tadabase's user roles documentation](https://docs.tadabase.io/academy/article/users-roles), admins can see all data while customers see only the rows relevant to them, enforced by the platform rather than a frontend filter. The honest caveat: Tadabase is still a hosted platform you rent. You get proper roles and a real app builder, but the data and the application live inside Tadabase's system. If the worry that drove you off Airtable was "we are renting our backend from a vendor," Tadabase fixes the roles problem without fixing the ownership one. ## If You Want a UI Over a Real Database: NocoDB [NocoDB](https://github.com/nocodb/nocodb) takes the opposite approach. Instead of giving you a new place to store data, it puts an Airtable-style spreadsheet interface on top of a database you already run - MySQL, PostgreSQL, MariaDB, SQLite. Connecting it to an existing Postgres instance takes a couple of minutes, and now your real database has the friendly grid UI that made Airtable pleasant in the first place. This is the right move when the data already belongs in a proper SQL database and you just want humans to interact with it without writing queries. You get foreign keys, constraints, and transactions because those live in the actual database, not the UI. One thing to know before you build a business on it: NocoDB changed its license from AGPL-3.0 to a "Sustainable Use License" starting with v0.301.0. Self-hosting for internal use is fine, but offering it as a managed service to third parties requires a commercial license. Read the terms if your use case is anywhere near reselling. ## If You Want Open Source and Self-Hosted: Baserow [Baserow](https://baserow.io/blog/nocodb-vs-baserow) is the fuller open-source platform. Unlike NocoDB, it manages its own PostgreSQL database and ships an application builder, an automation engine, and real-time collaboration. The core is MIT-licensed with no restrictions on commercial use, with premium and enterprise features under a separate license. If your reason for leaving Airtable is genuinely about ownership and avoiding per-seat pricing, Baserow is the closest like-for-like swap. The cost is operational. Baserow runs a Django plus PostgreSQL plus Redis stack, which needs more resources than NocoDB and, more importantly, needs someone to run it - upgrades, backups, security patches, uptime. Self-hosting trades a subscription bill for an ops responsibility. For a team with infra capacity that is a fair trade. For a two-person team shipping a product, it is a second job. ## If You Want a Real App on Real Postgres: Supabase Plus an AI Builder This is the path most teams actually want when they say "we need a real backend." [Supabase](https://supabase.com/features/row-level-security) is an open-source Postgres platform that fixes the two hardest Airtable problems directly. It gives you an actual relational database with constraints and transactions, and it gives you Row Level Security - authorization rules enforced inside Postgres itself, where `auth.uid()` ties a logged-in user to exactly the rows they are allowed to touch. That is the permission model Airtable cannot offer, sitting at the data layer instead of the UI layer. To get an app on top, teams pair Supabase with an AI builder like [Lovable](https://lovable.dev) or [Bolt](https://bolt.new), which generate a React or Next.js frontend wired to your Supabase backend. This gets you to a working, owned application fast - real database, real auth, real code. The caveat is the same one that applies to every prompt-driven builder, and it is worth taking seriously. In April 2026 Lovable disclosed a broken object-level authorization vulnerability that let any free-account holder reach another user's source code and database credentials; they patched it and wrote it up on [Lovable's blog](https://lovable.dev/blog). RLS only protects you if every policy is correct, and a model that writes policies optimizes for the happy path. Generated auth and access rules need an explicit security review before real user data goes near them. ## Where Creatr Fits Every option above is a tier on the same ladder. Tadabase fixes roles but rents you the platform. NocoDB and Baserow fix ownership but hand you either just the UI or the ops burden. Supabase plus an AI builder gets you closest to a real owned app, then leaves you holding the hardening - the auth review, the failure paths, the data-correctness work that the demo skips. [Creatr](https://getcreatr.com) is a managed build for the team that wants the end state without managing the climb. The output is a production web app on a real database - proper schema, real multi-role auth enforced at the data layer, integrations with their failure paths handled - delivered as code you own outright. Not a base, not a platform subscription, not a prototype you have to finish. It is honestly not the cheapest line item and it is not a weekend project. But if the reason you are reading an Airtable-alternatives post is that a spreadsheet quietly became the backend of something real, the fix is not a better spreadsheet. It is an actual application. The decision comes down to one question: do you want another tool to operate, or a product to own? If you are mapping the jump from a makeshift backend to a real one, the patterns in [building an internal tool without code](/build-internal-tool-without-code), the failure modes in [no-code app scaling problems](/no-code-app-scaling-problems), and the worked example of [building a custom CRM without code](/build-custom-crm-without-code) are the right next reads. Airtable is excellent at what it was built for. The moment it became your backend, you outgrew the category - and the right move is to switch categories, not tiers. --- # https://getcreatr.com/ajak-fuel-axis AJAK Fuel Axis wasn’t a speculative brief. The UK agency commissioning it had scoped the requirements properly, the four user roles mapped out, the integrations listed, and an operator on the other side waiting to run the fleet on it. They had chosen a generative build platform, and they had spent four months pushing the build toward something the operator could actually work on. At month four it was still *almost working*. *Almost working* in this build looked like a specific loop. A fix to the compartment volume flow landed clean on a Tuesday; by the following Monday a change to the rebate invoice path had silently broken the trailer inventory updates. A POD template lined up under one customer’s branding and drifted under another. The UI quality kept regressing. Work was moving; the product wasn’t arriving. When the requirements document reached us, DeepBuild shipped the platform in two days. Seven days later, the fuel operation was live on it. Fuel logistics isn’t the shape generative platforms ship well. It isn’t a dashboard. It’s a state machine with physical constraints on every click. A single tanker has multiple compartments. Each compartment holds exactly one fuel type at a time - **Diesel, Derv, Kerosene, Gas Oil, Petrol, Aviation Jet A1, Heating Oil, AdBlue, HVO, Marine Gas Oil**, plus six more - at a specific volume. A driver’s day stacks a collection at one terminal into three compartments, a delivery at one customer site that empties two of them, and another delivery that draws half the third. The platform has to know, at every point on that route, which compartment holds what fuel at what volume, and it has to update that state the moment each stop closes. Stack the rest on top. ADR transport documents generated off the products actually loaded - UN numbers, hazard classes, packing groups, tunnel codes. Driver certifications that expire (ADR, PDP, HGV licence, terminal induction). Trailer certifications that expire (MOT, SLP, ADR). Volume variance rules that refuse to close the stop if actual differs from planned beyond threshold without a driver note. Two POD templates chosen per customer. Rebate jobs that recompute Purchase Order and Transport Invoice against *actual* volumes collected, not the planned ones. Generative platforms close the first sixty percent of this fast. The last forty - where every element has to stay consistent with every other as the day’s jobs move - is where four months disappears. The **job engine** is the spine. Office staff create a job - *delivery*, *collection*, or *site work* - with any number of collection and delivery stops, a customer, products per stop, and a pricing shape assembled from per-litre, fixed, day rate, mileage, and tolls in any combination the customer contract specifies. Jobs are stamped `AJAK-YYMMDD-XXXXXX` and drop onto a live dispatch board the moment they land. **The driver PWA** works the job stop by stop. At a collection, the driver enters compartment volumes, photographs the Bill of Lading, enters the BOL number, photographs the meters before and after, and captures the collection signature - or toggles *unmanned* if the terminal runs that way. At a delivery, compartment volumes drawn down, tank gauge photos before and after, the ullage pre-pumping declaration, the delivery signature, and GPS at completion. Everything the office needs to invoice is on the stop before the truck pulls away. **Trailer state** updates in real time. Each compartment’s current fuel type, volume, and source location move as stops close. A compartment filled at the depot and three-quarters delivered at stop one leaves the remaining quarter - of that specific fuel type - visible to the next job that could draw from it. There is no end-of-day reconciliation, because the state is always current. **ADR transport documents** generate automatically off the compartment configuration the instant collections complete. UN number, class, packing group, tunnel code - pulled from the fuel product table, attached to the job, ready to travel with the load. **Proof of delivery** composes the moment the delivery signature goes down. The stop’s photos, signatures, and actual volumes flow into the customer’s template - AJAK or Nirva - and the PDF emails through Resend to the customer’s POD address before the driver has left the site. **Rebate jobs** - where the customer is paid for fuel being collected - generate a Purchase Order PDF for the fuel and a Transport Invoice PDF for the haulage, separately, both recomputed against actual volumes. What invoices is what moved. **Invoicing** runs off completion. One calculator composes per-litre × actual volume, day rate × days, mileage × miles, tolls, and rebate maths, and lays the breakdown out line by line. Invoice numbers stamp `INV-YYYY-XXXX`; the payload lands in Xero and fires a Zapier webhook in the same call. **Compliance tracking** sits under assignment, not after it. A driver whose PDP expires this month is flagged before they’re assigned. A trailer whose ADR expires this week is excluded. Terminal inductions are tracked per driver per terminal. The gap is closed at dispatch, not at audit. **The customer portal** is a scoped read-only view per company - their jobs, their invoices, and the supporting evidence on every one of them: POD, BOL photos, meter photos, signatures. Disputes route to the sales rep. The paperwork calls the office used to field all day stopped. The thing the agency had lost four months to wasn’t any one feature. It was iteration. Each new rule - a new compartment behaviour, a new pricing wrinkle, a new report - compounded against a codebase nobody had full grip on. On Creatr, a change that touches data or backend goes through a plan before code. DeepBuild describes what will move - tables, flows, boundaries - and the change is approved against that plan, not against a guess. Once the code lands, end-to-end tests run across the functionality already in production. Nothing merges that regresses a working flow. Two days shipped the platform. The five days between the build and production weren’t spent chasing regressions; they were spent shaping. The operation is running fuel on it. Dispatchers build routes. Drivers close stops on the PWA. Tankers keep their own books compartment by compartment. PODs leave the platform as the fuel arrives. Invoices close the day the fuel moved and land in Xero the same afternoon. The paperwork the office used to chase isn’t there to chase. You deliver what you say you're going to deliver - we've confirmed that. The flexibility, transparency, and quality of the work make Creatr a great partner. For complex projects going forward, why wouldn't we just start with Creatr? Agencies that ship serious software for clients have two things at risk on every build: the calendar and the reputation. This one burned four months defending the second. They brought the same requirements to us, and the second build shipped. --- # https://getcreatr.com/base44-alternatives # Base44 Alternatives in 2026: What Changed After the Wix Acquisition **Quick answer:** After the Wix acquisition, the honest Base44 alternatives are Lovable (best UI-first output), Bolt (more code control), Replit (strong deployment), and Retool (internal tools on existing databases). All stop at roughly 60-70% of a real product. If you need someone to own the full stack and security of a production business app, a managed build like Creatr fits where these tools do not. Base44 alternatives for business app builders in 2026 In June 2025, [Wix acquired Base44 for approximately $80 million](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/). Base44 had been [one of the more interesting entries in the AI builder space](/base44-review-2026) - a tool that leaned toward structured business apps rather than just rapid UI prototyping. The acquisition made strategic sense for Wix, which was looking for a credible AI-first product story. For Base44 users, it meant something different: a platform they had chosen independently was now absorbed into a much larger product with different priorities. The Trustpilot score tells part of the story. 2.4 out of 5 as of mid-2026, with reviews clustering around two specific complaints: the platform works well for simple apps and stops working predictably at the same threshold of complexity that most business apps eventually cross, and customer support response times had slowed noticeably in the months following the acquisition. If you are evaluating Base44 now or looking to move, here is an honest read of the landscape. --- ## What Base44 Actually Got Right Before the alternatives, it is worth being specific about what made Base44 a reasonable choice in the first place - because the alternatives worth considering are the ones that preserve those strengths rather than just avoiding the weaknesses. Base44's differentiation was in the structured data layer. Where Lovable and Bolt optimize for visual output first, Base44 built around the idea that a business app is fundamentally a data model with an interface on top. The tool was designed to make the data model explicit rather than emergent. You defined your entities, their relationships, and their permissions before you started building screens. The screens were built from the model, not the other way around. This produced apps with more coherent data structures than the typical vibe-coded output. Not always - the generator still made common-case assumptions in places where explicit decisions were needed - but directionally, the approach was sound. The tradeoff was speed. Base44 was slower to first output than Lovable or Bolt. The upfront model-definition step that made the data layer coherent also added friction at the start of a build. For founders who wanted to see something working immediately, it felt slower. For founders who had already learned the cost of rebuilding a data model six months into a project, it made sense. --- ## What the Acquisition Changed Wix integrations started appearing in Base44's interface within months of the acquisition. This is predictable - the acquirer wants to create cross-sell and upsell paths - but it created a specific problem for founders using Base44 for standalone business apps that had nothing to do with website hosting or e-commerce. The roadmap visibly shifted toward features that serve Wix's existing customer base. The business app use case - the one that drove most of Base44's technical differentiation - received less investment. This is not necessarily permanent, but the post-acquisition trajectory follows a pattern that has played out in similar acquisitions: the acquired team's roadmap gets absorbed into the acquirer's strategy rather than continuing on its own path. For founders who chose Base44 specifically for its structured approach to business apps, the post-acquisition product is a different bet. The underlying capability is still there. The platform's prioritization has shifted. --- ## Honest Assessment of the Alternatives The AI builder category in 2026 has a consistent failure mode: most tools get to [60-70% of a real product and stop](/lovable-alternatives-business-apps). This was true of Base44 before the acquisition and it is true of everything listed here. The relevant question is not which tool avoids the wall - none of them do - but what the wall looks like with each tool and whether you can work around it. [**Lovable**](https://lovable.dev) remains the strongest option for UI-first products. The visual output is genuinely better than any other tool in the category. The Supabase integration means you can go from idea to working auth and database in under an hour. The limitations are consistent: [row-level security requires explicit configuration](/vibe-coding-security-risks) (and most founders do not know to ask for it), multi-role access control is a prompt-by-prompt affair rather than a system-level concern, and the codebase that Lovable produces becomes harder to maintain as the app grows in complexity. For a SaaS with a clean, linear happy path, it is the fastest option. For a business app with complex permissions, it is a problem to manage. [**Bolt**](https://bolt.new) gives you more control over the code and a faster time to first output. It is also more willing to work with stacks other than React and Supabase. The cost structure is harder to predict - token consumption during debugging can be significant - and the security profile at the output level is similar to Lovable (the 88% RLS-disabled finding from the 2026 vibe-coded app audit covered Bolt as well). For founders who are code-literate and want AI assistance rather than AI ownership of the build, [Bolt fits better than Lovable in specific cases](/bolt-vs-lovable). For founders who need someone to own the entire build, the gap between what Bolt produces and what a production app requires is theirs to close. [**Replit**](https://replit.com) has made genuine progress on the deployment story - you can go from prompt to running app on a real URL in minutes. The platform is particularly strong for apps where the backend is the interesting part and the UI is secondary. The limitations are around customization depth and the ability to hand the code off to a developer for extension. Replit's model is platform-first: the app runs on Replit's infrastructure. If you need to take it elsewhere, that requires more work than it does with tools that produce cleaner exportable output. [**Retool**](https://retool.com) is worth considering if the app is primarily internal. It is not an AI-first builder in the same category as the others - it is a configuration-based tool for building dashboards, data tables, and admin panels on top of existing databases. The UI ceiling is lower: everything looks like Retool because it is Retool. But for internal tools where that ceiling is acceptable, it is significantly more production-stable than AI-generated apps and supports SQL queries, REST APIs, and script logic without requiring prompt iteration. --- ## The Limitation None of Them Fix The fundamental limitation of the AI builder category - including Base44 at its best - is that these tools start building from whatever description you give them. They do not ask the questions that determine whether the output will be correct for your specific situation. Who can see which records? Not just which role - which specific records. What happens when a payment fails? Not just the happy path - the failure path, the retry, the customer notification, the database state that needs to be corrected. What does a working version look like in month six when there are three user types, fifty clients, and a billing cycle that runs at the end of each month? Base44's structured data approach got closer to surfacing these questions than most tools. The explicit model-definition step forced decisions that other tools deferred. But it still started building before it fully understood the constraints. The tools that actually work for business apps are the ones that treat the requirements conversation as real work, not friction before the real work starts. The architectural decisions get made in that conversation - before any code exists, when changing them is free. After the build starts, changing the data model is not free. --- ## What to Actually Do If you are currently on Base44, the practical question is whether the post-acquisition product is still serving the use case you chose it for. If the structured data approach was the reason and the roadmap has shifted away from that, the migration question is real. The migration path that preserves the most value is exporting the data model explicitly - the entity definitions, the relationship structure, the permission logic - and rebuilding from those specifications rather than from the UI. Every tool in the category will build you a new UI from a description. None of them will correctly infer the permission structure from a description that does not make it explicit. The data model is the part worth carrying forward carefully. If you are evaluating the category fresh, the choice among these tools depends more on what you are building than on which tool scores better in a comparison matrix. UI-heavy products with simple data models: Lovable. Code-literate teams who want AI assistance: Bolt. Internal tools on existing databases: Retool. Production business apps where someone needs to own the full stack and the security implications: the tools in this category are not the answer you are looking for, and the 60-70% wall is not a limitation you will engineer your way around by picking the right tool. For that case, [Creatr vs Base44](/vs/base44) lays out the trade-off - owned production code against a platform whose roadmap now answers to Wix. --- # https://getcreatr.com/base44-review-2026 # Base44 Review 2026: Is It Worth It After the Wix Deal? Base44 review 2026 - is it worth it after the Wix acquisition **The short version:** Base44 is worth it if you want a working app fast without assembling a stack yourself - it ships frontend, database, auth, and hosting in one place, and the Wix acquisition gave it money and distribution rather than gutting it. It is not worth it as the system your business runs on. Like every AI builder, it gets you to roughly 60-70% of a real product and stalls on the multi-role permissions, data correctness, and integration failure handling that make up the rest. Buy it as a fast path to a working v1, not as a replacement for production engineering. Most Base44 reviews stop at "I described an app and it built one." That part is true and it is genuinely impressive. It is also the easy part. The question worth 1,500 words is what happens on day 40, when the demo works, real users are in it, and somebody with the wrong role can see somebody else's records. --- ## What Base44 actually is [Base44](https://base44.com) is an AI app builder: you describe an app in plain language and it generates the frontend, a backend, a database, user authentication, and a deployed URL. Its defining choice is that everything is built in - you do not connect your own Supabase project or wire your own auth provider. That is the whole pitch and, as we will get to, the whole tradeoff. Wix [announced its acquisition of Base44 on June 18, 2025](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif), for approximately $80 million in initial consideration plus earn-out payments through 2029 tied to performance, with roughly $25 million in employee retention bonuses expected in 2025. Base44 was founded by Maor Shlomo, who stayed on as CEO. The interesting part is what happened next. By Wix's Q3 2025 results, [Base44 had reached 2 million users - roughly a sevenfold increase since the deal closed](https://www.calcalistech.com/ctechnews/article/sy194qsg11g) - was projected to hit $50 million in annual recurring revenue by year end, and was adding more than 1,000 new paying subscribers a day. Wix's CFO said growth was exceeding expectations. That is the acquisition working, not an acqui-hire quietly dissolving. --- ## What Base44 does genuinely well **Time from idea to something you can click is short.** This is not marketing. Describe a CRM, an intake form with a dashboard, a small internal tool, and you get a working, deployed app in minutes. For validating an idea or replacing a spreadsheet, that speed is the product. **Everything is included by default.** Auth, database, file storage, analytics, payments, and email are part of the platform rather than five integrations you have to reason about. For a non-technical builder, removing that assembly step is worth more than any individual feature. **The free tier is a real free tier.** Base44's [pricing page](https://base44.com/pricing) gives free accounts 25 message credits and 100 integration credits per month with core features - auth, database, analytics - and up to 5 apps. You can find out whether this tool fits your problem before paying anything, which is more than several competitors offer. **You can get the code out.** Base44's own FAQ states you own what you build and that two-way GitHub sync exports full source to your repo. That matters, because the usual failure mode of all-in-one builders is that leaving costs you everything. Verify the export on your own project before you depend on it, but the escape hatch is documented and it is a real differentiator against pure visual platforms. **Wix distribution is a durable advantage.** A parent with a large SMB customer base, a real balance sheet, and an incentive to keep investing makes Base44 more likely to exist in three years than a comparably sized independent startup. For a tool you might build a business on, that is not a small thing. --- ## Where Base44 stalls The failures are not random and they are not unique to Base44. They cluster at the boundary between "looks finished" and "is correct." **Multi-role authorization.** Base44 will happily give you login. Login is not authorization. The moment your app has an admin, a manager, and a customer who must not see each other's data, you need rules enforced on the server for every read and write - not a role check in the UI that hides a button. Generated apps routinely get the UI layer right and the enforcement layer wrong, and the bug is invisible until someone looks. **This is not theoretical for Base44 specifically.** In July 2025, a month after the Wix deal, [Wiz Research disclosed a critical authentication bypass in Base44 itself](https://www.wiz.io/blog/critical-vulnerability-base44): apps set to "Private with SSO" could be joined by anyone holding the app's `app_id`, a value that was publicly visible in URLs and manifest files. Wiz reported it on July 9, 2025 and Wix shipped a fix within 24 hours, with no evidence of abuse found. Credit where due - that is a fast, clean incident response. The reason it belongs in a review is that it illustrates the category's structural risk: when the platform owns your auth, your access control is only as correct as their platform, and you have no way to audit it. **Row-level data isolation.** Related but distinct. Tenant A must never be able to query tenant B's rows, and that has to hold at the database layer, not the application layer. Getting this right requires deliberate design up front. Prompt-by-prompt schema growth does not produce it. **Integration failure handling.** The demo covers the happy path. Production is the unhappy path: the Stripe webhook that retries, the email provider that times out, the API that returns a 500 halfway through a multi-step write. Idempotency, retries, and reconciliation are boring, they never show up in a prompt, and skipping them corrupts data quietly. **Credit burn during debugging.** Base44's paid plans are metered in message credits - 100/month at Starter, 250 at Builder, 500 at Pro, 1,200 at Elite. Building features is the cheap use of those credits. Debugging is the expensive one, because a fix-break-refix loop consumes the same allowance as productive work. Public reviews on [Trustpilot](https://www.trustpilot.com/review/base44.com) are polarized, and the recurring negative theme is billing and credits consumed fixing problems rather than shipping - worth reading a page or two before you commit to an annual plan. (Trustpilot blocks automated fetching, so read it in a browser.) This is the same wall every tool in the category hits. We map it in detail in [why AI-built apps stall at the 80% problem](/why-ai-built-apps-stall-80-percent-problem). Base44 is not worse at it than its peers. It is just not exempt. --- ## Base44 pricing at a glance All figures are the annual-billing rate from Base44's pricing page as of this writing; Base44 states yearly billing carries a 20% discount over monthly. | Plan | Price (billed annually) | Message credits / mo | Integration credits / mo | Best for | | --- | --- | --- | --- | --- | | Free | $0 | 25 | 100 | Evaluating the tool; up to 5 apps | | Starter | $16 | 100 | 2,000 | Personal projects, first real build | | Builder | $40 | 250 | 10,000 | Iterating on a live internal tool | | Pro | $80 | 500 | 20,000 | Complex apps, GitHub sync, beta access | | Elite | $160 | 1,200 | 50,000 | Running a business on it, premium support | The number that decides your real cost is not the plan price. It is how many credits a debugging session eats. Budget for a tier above the one the feature list suggests. --- ## Is Base44 worth it? Verdict by user type | User type | Is it worth it? | Why | | --- | --- | --- | | Non-technical founder, demo or validation scope | Yes | This is the best use of the tool. Fastest path from idea to something investors and users can click, and the free tier lets you test the fit first. | | Non-technical founder, production scope | No | You will reach a working app and then hit auth, permissions, and failure handling you cannot evaluate, let alone fix. The remaining 30-40% is engineering, not prompting. | | Technical founder or developer | Partly | Excellent for scaffolding and for killing the boring setup. Use the GitHub export, then own the security model yourself rather than trusting the generated one. | | Small business internal tool (single role, low sensitivity) | Yes | A shared dashboard or intake form for a team that already trusts each other is genuinely well served here. This is Base44's sweet spot. | | Multi-tenant SaaS or anything with regulated data | No | Row-level isolation and audited access control are the requirements, and they are exactly what generated apps get wrong. | If you want the fuller field, we compare the category in [Base44 alternatives](/base44-alternatives), look at the parent-company angle in [Wix vs Base44](/wix-vs-base44), and put our own approach side by side with it on [Creatr vs Base44](/vs/base44). --- ## Did the Wix deal make Base44 better or worse? Better on stability, neutral-to-better on product, unresolved on independence. Stability improved: funding, a security team that patched a critical bug in a day, and a parent motivated to keep shipping. The product did not regress - growth accelerated after the deal rather than stalling, which is not what usually happens to acquired startups. Independence is the open question: Base44 now sits inside a company whose core business is website subscriptions, and roadmap priorities eventually follow the parent's strategy. Nothing has gone wrong there yet. It is a risk you are taking that you were not taking in May 2025. --- ## Where Creatr fits, and where it does not Creatr (DeepBuild) is not a Base44 competitor in the way another builder would be, and pretending otherwise would make this review worthless. Base44 is a tool you operate. Creatr builds, hosts and runs the thing for you: you describe the product, and a complete, deployed application is built and handed to you as source code you own - with the multi-role authorization, row-level data isolation, and integration failure handling done rather than deferred. Humans stay in the loop the whole way. It exists for people who want the finished outcome, not a builder to drive. That means Creatr is the wrong choice for a lot of people reading this. If you want to build it yourself, if the iteration loop is the fun part, if you are validating an idea and a demo is genuinely enough, or if your budget is a $16 plan - use Base44 and use it well. It is a capable tool and this review should not talk you out of it. Creatr fits the narrower case where the software has to be correct because real customers and real money depend on it, and you would rather receive a working system than manage its construction. You can see what that looks like at [getcreatr.com](https://getcreatr.com). So: is Base44 worth it in 2026? For a first working version, an internal tool, or an idea you need to test this week - yes, and the Wix deal made that answer safer than it was a year ago. For the system your business runs on - no, and the tell is that the failure shows up after the demo works, not before. --- # https://getcreatr.com/base44-vs-lovable # Base44 vs Lovable (2026): Which AI App Builder Fits? Base44 vs Lovable comparison 2026 **Quick answer:** Base44 is the better fit for internal business apps with named users, roles, and SSO - its data layer ships with row and field level permissions as a first-class concept, and it now has Wix distribution behind it. Lovable is the better fit for customer-facing products where the UI is the product, and its Git sync and downloadable codebase make handoff to a developer straightforward. Both produce something real in an afternoon. Both stall at roughly the same 60-70% mark, on authorization, integration failure handling, and data correctness under concurrent use. The comparison most people run is "which one writes better code." That is not the deciding variable. Both tools write code that runs. The deciding variables are what happens to the backend when your app grows a second user role, and who owns the artifact when you outgrow the builder. --- ## The head-to-head | Dimension | Base44 | Lovable | | --- | --- | --- | | What it generates | Apps on Base44's own platform primitives - entities, backend functions, agents - with framework support including React, Vue, Solid, Refine, Hono and React Native ([docs](https://docs.base44.com/developers/app-code/local-development/github)) | Full-stack web apps, code viewable and editable in an in-product code editor ([docs](https://docs.lovable.dev/features/code-mode)) | | Code export and ownership | Two-way GitHub sync on the Builder plan or higher. The docs are explicit that sync is permanent - you cannot disconnect or transfer the project back ([docs](https://docs.base44.com/developers/app-code/local-development/github)) | Download the codebase from the code editor on paid plans, or two-way Git sync with GitHub, GitHub Enterprise, or GitLab ([docs](https://docs.lovable.dev/integrations/git-sync-overview)) | | Backend and database | Built-in entity system with JSON Schema definitions, plus row level and field level security rules on every entity. Deno-powered serverless functions ([docs](https://docs.base44.com/developers/backend/resources/entities/security)) | Lovable Cloud, which the docs describe as built on "Supabase's open-source foundation" - Postgres, auth, storage, edge functions ([docs](https://docs.lovable.dev/integrations/cloud)) | | Pricing model | Two separate meters: message credits and integration credits, across Free through Elite tiers ([pricing](https://base44.com/pricing)) | One credit pool per workspace, priced "by the credits they include, not by seats," with unlimited workspace members ([pricing](https://lovable.dev/pricing)) | | Ecosystem and distribution | Owned by Wix since June 2025 - custom domains purchasable through Wix, plus enterprise SSO and SCIM provisioning | Independent. Deep Supabase lineage, GitHub and GitLab sync, a ChatGPT app, Wiz vulnerability scanning | | Best for | Internal tools, ops apps, anything with roles and a real permission model | Customer-facing products where design quality is the differentiator | Two things in that table matter more than the rest. The first is Base44's permission model. Every entity supports row level security with `create`, `read`, `update` and `delete` permissions, and field level security with separate `read` and `write` rules. Each permission takes `true`, `false`, or a condition that compares record fields against the current user - `created_by` against the requester's email, for example. That is not an afterthought bolted onto a table editor. It is how entities are defined. The second is the export asymmetry. Lovable's docs describe a "Download codebase" button in the code editor and two-way sync you can set up per project. Base44's GitHub docs carry a warning that once you connect, "GitHub sync is permanent. You can't disconnect or transfer the project back to Base44," and that version history from before the connection becomes unrestorable. Both give you the code. Only one of them is a reversible decision. --- ## What the Wix acquisition actually changed Wix announced the acquisition of Base44 on June 18, 2025, for [initial consideration of approximately $80 million plus earn-out payments through 2029](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif). The release also disclosed roughly $25 million in retention bonuses to Base44 employees in 2025, and cited B2B traction with eToro and SimilarWeb. The strategic read is straightforward in both directions. Base44 gains distribution. Wix has an enormous installed base of small businesses already paying for a web presence, and Base44 becomes the natural upsell when one of them needs an actual application rather than a brochure site. Domain purchasing through Wix is already wired in. That is a durable, cheap acquisition channel no independent AI builder can match. Base44 also loses roadmap independence. Its owner's core business is websites. When Wix has to choose between shipping deeper multi-tenant permissions for a 200-seat operations tool and shipping something that converts more of the site-builder base, the second one has a clearer P&L attached. Nothing about the acquisition guarantees that Base44's enterprise-grade features - the SSO, the SCIM provisioning, the field level security - stay the priority. They are the parts of the product a website company is least structurally motivated to keep investing in. If you want the fuller version of that argument, we wrote it up separately in [Wix vs Base44](/wix-vs-base44). None of this makes Base44 a bad choice today. It is a real consideration if you are betting a three-year internal system on it. --- ## Where Lovable is genuinely better Lovable's output looks finished. Spacing, states, component choices, typography - the defaults land in a place that reads as deliberate design rather than as generated markup. For a product where the interface is the thing customers judge you on, that is not cosmetic. It is the product. The Supabase lineage under Lovable Cloud is the other real advantage. Postgres is Postgres. Auth, storage, edge functions and real-time subscriptions come from a stack that thousands of engineers already know, which matters enormously the day you hire one. And the code export is real, not theatrical - React, Tailwind, your routing, your config, in a repo you control. Lovable's docs are also unusually honest about the failure mode. On the Supabase integration page: "Before going live, make sure every table has Row Level Security policies that restrict who can read and write each row," followed by the note that "Missing RLS policies are the most common way app data gets exposed." That is a vendor telling you where its own happy path ends. Our longer assessment is in the [Lovable review for 2026](/lovable-review-2026). --- ## The wall both tools hit Here is the part neither comparison video covers, because it does not show up in a demo. A login form is authentication. Deciding *who may read which row* is authorization. They are different problems, and prompt-driven builders are excellent at the first and structurally bad at the second - because authentication is one screen and authorization is an invariant that has to hold across every screen, every API route, and every export you will ever add. When you type "only managers should see the payroll column," the model adds a check to the screen you happen to be looking at. It does not go audit the other twenty-two screens, the CSV export, the search endpoint, or the webhook handler to confirm the same rule holds there. Base44's per-entity RLS makes this much harder to get wrong than a system with no permission primitive at all - the rule lives on the data, not the view. But it is still on you to write the condition, and Base44's own security overview says so plainly: "You are responsible for your app's security settings." The same wall shows up in three other places: - **Integrations that handle failure.** Charging a card is one prompt and it works. The subscription-lapsed webhook, the failed-payment retry, the signature validation, the reconciliation when the webhook arrives before the redirect - each of those is a separate prompt, and the tool treats each as a new feature rather than as one billing system it owns end to end. - **Data correctness under concurrent use.** Two users hitting the same record at the same moment. Nothing in the prompt loop raises this, so nothing addresses it, and the bug is invisible until it is in production with real money attached. - **The audit you cannot prompt for.** You do not know which of your rules is missing, because the app looks correct from the inside. This is a category property, not a vendor defect. We broke down the pattern in detail in [why AI-built apps stall at the 80% problem](/why-ai-built-apps-stall-80-percent-problem). If you are evaluating more broadly than these two, the fuller landscape is in [Base44 alternatives](/base44-alternatives) and the [Creatr vs Base44](/vs/base44) comparison. --- ## Pick this one if | Your situation | Pick | | --- | --- | | Internal ops tool, 10-200 named employees, roles matter | Base44 - entity-level RLS and FLS, SSO, SCIM | | Customer-facing SaaS where design quality is the pitch | Lovable | | You already run on Wix and want one vendor | Base44 | | You will hand this to a contract developer in three months | Lovable - Postgres plus a reversible export | | Enterprise SSO with Entra ID or Okta is a hard requirement | Base44 | | Weekend prototype to validate an idea with real users | Either. Genuinely - pick on which UI you prefer | | Regulated data, multi-tenant isolation, or money moving | Neither, without a security review you did not write | --- ## Where Creatr fits, and where it does not Creatr is not a third builder in this list. Our product, DeepBuild, works the other way round: you describe the outcome, and we build, host and run production-grade software that you own outright - with the authorization model, the integration failure paths, and the data guarantees treated as requirements rather than as things you discover are missing. It exists for people who want the finished system, not a tool to drive. That is a different category, and it is the wrong choice for a lot of people. If the building is the point - if you want to iterate at 2am, change your mind about the data model six times, and learn the shape of your product by pushing on it - use Base44 or Lovable. They are good at that, and delegating the build will feel slow and constraining by comparison. If what you actually want is the working system, [Creatr](https://getcreatr.com) is the honest answer. --- # https://getcreatr.com/best-no-code-app-builders-2026 # The Best No-Code App Builders in 2026: A Practical Guide Best no-code app builders compared in 2026 **Quick answer:** There is no single best no-code app builder - there is a best one for your use case. For full-stack apps with real database logic, [Bubble](https://bubble.io) is the most capable. For client portals and dashboards on top of existing data, [Softr](https://www.softr.io) and [Glide](https://www.glideapps.com) win. For native mobile apps, [Adalo](https://www.adalo.com) and [FlutterFlow](https://www.flutterflow.io) lead, with FlutterFlow adding code export. For marketing sites and content, [Webflow](https://webflow.com) is the standard. All of them are genuinely excellent inside their model - and all of them share the same ceiling. When your app needs custom auth, non-standard logic, deep integrations, or code you actually own, no-code stops being the shortcut and starts being the constraint. The no-code market has matured to the point where the honest advice is no longer "avoid it" or "use it for everything." It is "match the tool to the job, and know exactly where the job outgrows the tool." This guide does both. It assesses the major no-code app builders on their real merits, maps each to the work it does best, and is explicit about the shared limits that no vendor markets. It ends where the honesty leads: the moment you need to cross the ceiling into owned production software, and what that transition actually costs. --- ## First, A Distinction That Saves You Months: App Builders vs Website Builders The phrase "no-code app builder" gets used for two fundamentally different kinds of tool, and conflating them is the most common expensive mistake in this space. A **website builder** produces content pages. It is optimized for layout, typography, marketing copy, SEO, and visual polish. The output is pages a visitor reads. Webflow is the best-in-class example, though it has grown well beyond a simple page builder. An **app builder** produces software with state. It has a data layer, user accounts, permissions, and logic that changes what a given user sees and can do. The output is an application a user operates. Bubble, Glide, Softr, Adalo, and FlutterFlow live here. The trap is that a landing-page tool with a form attached can look like an app, and an app builder can render a marketing page. But the moment you need user accounts, saved records, role-based views, or workflows that fire on events, you need an app builder. Trying to force a website builder into that job produces brittle glue and eventually a rebuild. Below, the tools are grouped by which job they actually do well. --- ## The Capability Matrix Before the tool-by-tool assessment, here is how the major builders compare on the dimensions that decide whether one fits your project. Ratings are qualitative and reflect each tool's core model, not marketing claims. Verify current specifics on each vendor's own site, linked throughout. | Tool | Primary output | Data model | Custom logic depth | Mobile | Code export | | --- | --- | --- | --- | --- | --- | | Bubble | Full-stack web app | Native database | High (visual workflows) | Responsive web / PWA | No | | Softr | Web app / portal | External (Airtable, Sheets, etc.) | Low to medium | Responsive web | No | | Glide | Web + mobile app | External or built-in | Low to medium | PWA / app-like | No | | Adalo | Native mobile app | Built-in or external | Medium | Native iOS / Android | No | | FlutterFlow | Native + web app | Firebase / Supabase | Medium to high | Native iOS / Android | Yes (Flutter) | | Webflow | Website / CMS | CMS collections | Low (interactions, logic add-on) | Responsive web | Partial (front-end) | | Airtable-based | Internal tool / portal | Airtable base | Low to medium | Responsive web | No | The pattern in the table is the point. Capability and portability trade against ease of use. The tools that get you to a working app fastest own the most of your stack, and the ones that give you more control ask more of you in return. No row in this table both maximizes ease and hands you owned, portable code. That is not a gap any one vendor is failing to fill. It is the structural shape of the no-code model, and it is the thesis this guide returns to at the end. --- ## Bubble: The Most Capable Full-Stack Builder **What it is best at.** [Bubble](https://bubble.io) is the closest thing no-code has to a real application platform. It has a genuine database layer, a visual workflow engine that expresses conditional logic, an editor where the data, the logic, and the interface all speak the same language, and a plugin ecosystem that connects Stripe, mapping, authentication providers, and thousands of other services without code. If you are a non-technical founder who needs to build a data-driven product - a marketplace, a SaaS tool, a booking system - Bubble can take you further than any other single no-code tool. **Its model.** Bubble is fully hosted and fully integrated. You define data types, build workflows that read and write them, and design pages that display them, all inside one environment. Billing is organized around Workload Units, a usage-based metric that meters server computation across workflows, database operations, and API calls. See [Bubble's pricing page](https://bubble.io/pricing) for current plan structure, because the model has changed over time and exact figures are not worth quoting from memory. **Where it stalls.** Three walls show up reliably. The first is cost predictability during heavy development, because debugging and iteration consume the same metered compute as production traffic. The second is that there is no source-code export - your app is a set of proprietary abstractions inside Bubble, and moving off means rebuilding. The third is performance under genuine complexity, where recursive workflows and multi-condition searches across related data slow down in ways you cannot optimize past the platform's own ceiling. We go deep on all three in our [Bubble review for 2026](/bubble-review-2026), and on the ways out in [Bubble alternatives in 2026](/bubble-alternatives-2026). **Who it is for.** Founders building a real, logic-heavy product who value speed to a working app over owning the underlying code, and whose complexity sits below Bubble's performance and portability ceilings. For a large share of early-stage products, that describes the situation exactly, and Bubble is the right call. --- ## Softr: The Fastest Path from a Database to a Portal **What it is best at.** [Softr](https://www.softr.io) turns structured data you already have - typically an Airtable base or a Google Sheet - into a polished web app or client portal, fast. If your data lives in a spreadsheet and you need a clean, permissioned front end on top of it, Softr is often a same-day job. Membership gating, role-based visibility, list and detail views, and forms come together with very little friction. **Its model.** Softr is a front-end layer over an external data source. It does not own the database - it reads and writes to Airtable, Sheets, or similar. That is its central design decision, and it drives everything else about the tool. **Where it stalls.** Because the data model lives in the connected source, your logic is only as capable as that source allows. Complex relational queries, heavy write concurrency, and large record volumes push against the limits of Airtable or Sheets, not Softr. Custom business logic beyond filtering, gating, and simple automations is not Softr's strength, and it is not trying to be. When a portal grows into an application with real workflows, Softr is usually the layer you outgrow first. **Who it is for.** Teams and operators who have their data organized already and need to expose it as a branded, permissioned interface to clients, members, or staff - without building or maintaining a back end. For internal tools and client portals, it is one of the most efficient tools available. --- ## Glide: Apps from Spreadsheets, Now With More Ambition **What it is best at.** [Glide](https://www.glideapps.com) started as the fastest way to turn a spreadsheet into an app-like experience, and it still holds that title for simple cases. It produces polished, mobile-friendly progressive web apps with very little effort, and it has expanded toward more capable data handling and AI-assisted features. For internal tools, field apps, simple directories, and lightweight CRUD applications, Glide gets you to something usable remarkably quickly. **Its model.** Glide is app-generation over a data source - its own tables or an external one - with pricing that has historically been organized around users and updates rather than raw compute. Check [Glide's pricing page](https://www.glideapps.com/pricing) for the current structure, because the per-user and usage dimensions matter for team apps and have shifted over time. **Where it stalls.** The same trade that makes Glide fast makes it shallow for complex needs. Deep custom logic, intricate multi-role permissions, and heavy relational data are not where it shines. As an app's logic grows, you spend more time working around Glide's model than working within it. It is also PWA-first, so a true native app-store presence with native device capabilities is not its core strength. **Who it is for.** Operators and small teams building internal tools and simple customer-facing apps who value speed and a clean result over deep customization. For a large category of "we just need an app that does this one thing well," Glide is an excellent answer. --- ## Adalo: Native Mobile Without the Native Toolchain **What it is best at.** [Adalo](https://www.adalo.com) is built for people who need an actual mobile app - something that installs from the App Store and Google Play - without learning Swift or Kotlin. It has a component-based visual editor, a built-in database or external connections, and a publishing pipeline that produces native iOS and Android apps. For a consumer-facing mobile app with standard patterns - lists, profiles, feeds, forms, notifications - Adalo covers the ground. **Its model.** Adalo owns the stack from data to native build. You design screens from components, wire up actions, and publish to the app stores through Adalo's pipeline. It sits in the app-builder category firmly, with mobile as its center of gravity. **Where it stalls.** Performance and flexibility are the ceilings. Apps with large data sets, heavy lists, or complex interactions can feel slower than a hand-built native app, and highly custom UI or logic runs into the limits of the component model. As with the others in its class, there is no export of a maintainable native codebase, so the app remains dependent on Adalo's platform and pricing. **Who it is for.** Founders and teams who need a native mobile app with conventional patterns, shipped without a mobile development team. For a straightforward mobile product in validation, it removes an enormous amount of work. --- ## FlutterFlow: The One That Hands You Code **What it is best at.** [FlutterFlow](https://www.flutterflow.io) is the most developer-adjacent tool in this list. It is a visual builder for Flutter apps, which means it produces genuine native iOS, Android, and web applications - and, importantly, it can export the underlying Flutter code. It integrates with Firebase and Supabase for the back end, supports custom functions and custom widgets, and lets a developer drop into code where the visual layer runs out. That combination makes it the bridge between no-code speed and real ownership. **Its model.** FlutterFlow is a visual front end over the Flutter framework with real back-end integrations. Its defining feature is that the output is not a proprietary black box - it is Flutter, a code you or a developer can take and extend. That single decision changes the ceiling story for FlutterFlow relative to every fully-closed tool above it. **Where it stalls.** The catch is that the ownership is only useful if you have the skills to use it. Exported Flutter is real code, which means maintaining, extending, and deploying it well requires actual mobile engineering. The visual layer gets you far, but complex apps still demand custom functions, state-management decisions, and back-end architecture that a non-developer will struggle to own. In other words, FlutterFlow relocates the ceiling rather than removing it - it moves the wall from "the platform won't let you" to "now you need an engineer." **Who it is for.** Technical founders, developers who want to move faster, and teams that expect to eventually hand the app to engineering. If code ownership matters to you and you have or can hire the skills to use it, FlutterFlow is the most future-proof choice in the mobile category. --- ## Webflow: The Website Builder That Earns Its Category **What it is best at.** [Webflow](https://webflow.com) is the standard for visually designed, production-quality websites and content-driven sites. Its visual editor maps cleanly onto real HTML and CSS, its CMS handles structured content like blogs and catalogs well, and the output is fast, standards-based markup that designers and marketers can control precisely. For a marketing site, a portfolio, a documentation site, or a content platform, Webflow is hard to beat. **Its model.** Webflow is a website and CMS builder first. It has added logic and interaction capabilities over time, and it can produce sophisticated marketing experiences, but its center of gravity is content and design, not stateful application logic. Its plans are structured around sites, CMS items, and traffic - see [Webflow's pricing page](https://webflow.com/pricing) for current details. **Where it stalls.** Webflow is not an app builder, and the failures come from asking it to be one. User accounts, role-based application logic, complex saved state, and multi-step workflows are not its native territory. People stretch it there with add-ons and integrations, and it works until it doesn't, at which point the glue becomes the maintenance burden. Kept in its lane, Webflow is excellent. Pushed out of it, it becomes the wrong tool. **Who it is for.** Marketers, designers, and founders who need a beautiful, fast, editable website or content platform. If your need is pages a visitor reads rather than software a user operates, Webflow is the right answer and an app builder is overkill. --- ## Airtable-Based Tools: The Database as the Application **What it is best at.** [Airtable](https://www.airtable.com) itself is a spreadsheet-database hybrid that many teams run entire operations on, and an ecosystem of tools - Softr and Glide among them, plus Airtable's own interface designer - turns those bases into applications. The strength of this whole category is that the data model and the app are tightly coupled. You structure your data once, and the interface follows from it. For internal tools, lightweight CRMs, project trackers, and content pipelines, an Airtable-centered stack is fast and coherent. **Its model.** The Airtable base is the source of truth, and the app is a view onto it. This is the same external-data pattern that Softr and Glide use, and it inherits both the speed and the limits of that pattern. **Where it stalls.** The database is the ceiling. Airtable has record limits, automation limits, and performance characteristics that are fine for team-scale operations and not fine for a high-volume consumer product. Complex relational logic, transactional integrity, and heavy concurrent writes are not what a base is built for. When an internal tool becomes a real product, the Airtable foundation is usually the first thing that has to be replaced. We cover exactly this failure mode in [why no-code apps hit a scaling wall](/no-code-app-scaling-problems). **Who it is for.** Teams building internal tools and lightweight operational apps on data they already manage in Airtable. For that job, it is one of the most productive stacks available, and it should not be replaced with something heavier before the limits actually bite. --- ## Best Tool by Use Case Feature comparisons mislead because they optimize for the wrong question. The right question is "what am I building," not "which tool has the most features." Here is the mapping that actually holds up. | You are building | Best-fit no-code choice | Why | | --- | --- | --- | | Full-stack web app with real logic | Bubble | Native database plus a visual workflow engine | | Client portal on existing data | Softr | Fastest front end over Airtable / Sheets | | Simple internal tool from a spreadsheet | Glide or Airtable interfaces | Fast, clean, low-maintenance | | Native consumer mobile app | Adalo or FlutterFlow | True app-store native output | | Native mobile with code ownership | FlutterFlow | Exports real Flutter code | | Marketing site or content platform | Webflow | Best-in-class design and CMS | | Internal ops tool on managed data | Airtable-based stack | Data model and app tightly coupled | | Production app that must scale and be owned | None of the above alone | Crosses the no-code ceiling | The last row is the honest one, and it is not a knock on any tool above it. It is the boundary condition. Everything above that row is a job no-code does well. The row itself is where the model runs out, and the rest of this guide is about that line. --- ## The Ceiling Every No-Code Builder Shares Each tool has its own limits, but three ceilings cut across the entire category. They are structural, not bugs, and no vendor markets them because they are inherent to what no-code is. Understanding them is the difference between choosing a tool with open eyes and discovering the wall after you have built on it. | Shared ceiling | What it means | When it bites | | --- | --- | --- | | Code ownership and lock-in | Most tools give you no portable, maintainable codebase | When you want to move, extend, or hand off the app | | Scaling limits | Shared infrastructure and external data sources cap performance | At real user volume or data complexity | | The custom 30 to 40 percent | Non-standard auth, logic, and integrations resist visual tools | When the app needs to do something the platform did not anticipate | **Code ownership and lock-in.** With the notable exception of FlutterFlow's Flutter export, the tools in this guide do not hand you a codebase you can take elsewhere. Your app is a set of proprietary abstractions living inside the vendor's platform. That is a reasonable trade for speed early on, and a serious constraint once the app is a business asset. If the platform changes its pricing, deprecates a feature you depend on, or simply stops fitting, your options are limited and a migration usually means a rebuild. We unpack what ownership actually means, and how to tell what you really have, in [do you own the code from AI app builders](/do-you-own-the-code-from-ai-app-builders). **Scaling limits.** No-code apps run on shared, abstracted infrastructure, or on external data sources like Airtable that were not built for high-volume application load. That is exactly why they are easy - the platform hides the hard parts. The same abstraction that makes them approachable is what caps them, because you cannot reach in and optimize the query layer, change the database engine, or scale components independently. For most projects that ceiling is far above what you need. For a product that finds real traction, it arrives, and it arrives suddenly. The full anatomy of that wall is in [no-code app scaling problems](/no-code-app-scaling-problems). **The custom 30 to 40 percent.** This is the ceiling that surprises people most. Visual builders handle the standard 60 to 70 percent of an app beautifully - the CRUD, the forms, the lists, the common integrations. The remaining portion is where real products are differentiated and where the difficulty concentrates: custom authentication and multi-role permission logic, non-standard business workflows with real error handling, deep or unusual third-party integrations, and production concerns like rate limiting and observability. These do not yield to a drag-and-drop interface or a prompt, because they require decisions that have to be made explicitly rather than generated by default. This is the same failure pattern we describe in [why AI-built apps stall at the 80 percent problem](/why-ai-built-apps-stall-80-percent-problem) - the last stretch is where the tool's model and the product's needs diverge, and it is where projects get stuck. --- ## When No-Code Is the Right Answer - and When It Is Not The point of being precise about ceilings is not to argue against no-code. It is to draw the line clearly, because most projects sit comfortably on the right side of it. No-code is the correct choice when you are validating an idea, building an internal tool, running an operation on data you already manage, standing up a portal or a simple app fast, or shipping a product whose complexity genuinely fits inside the standard patterns the tools handle well. In those cases, reaching for custom development is slower, more expensive, and needlessly heavy. The tools in this guide will take you from idea to working software in days, and that is a real and repeatable win. If your project is described by any of those situations, stop here and pick the tool from the use-case table. That is the answer. No-code becomes the wrong choice at the ceiling: when you need to own and extend the code, when you need to scale past what shared infrastructure allows, or when the differentiating third of your app lives in exactly the custom auth, logic, and integrations that visual tools resist. At that point, continuing to force the tool costs more than crossing over - in workarounds, in performance debt, and eventually in the rebuild you were trying to avoid. --- ## Crossing the Ceiling: Where a Managed Build Fits When a project crosses that line, the traditional options have historically been three, and each has a real cost. Learn to code or hire engineers, which is slow and expensive and hard to get right. Hire an agency, which means long timelines, retainers, and a build you often do not fully own or understand. Or push the no-code tool past its limits and absorb the workarounds until they collapse into a rebuild. There is a fourth option that has emerged specifically for this transition, and it is where [Creatr](https://getcreatr.com) sits. Creatr builds, hosts, and runs production-grade software for you. The output is agency-grade - real, custom, owned code with the hard 30 to 40 percent designed in rather than deferred - without the agency timeline or the ongoing retainer. You own the code. There are humans in the loop making the architectural decisions that visual builders and prompt-driven tools skip, and the turnaround is measured in 24 hours rather than months. That model matters precisely because of the ceiling this guide has been describing. The custom auth, the multi-role permissions, the non-standard workflows, the deep integrations, the scaling architecture, the ownership - these are the exact things that no-code cannot give you and that a managed build treats as the actual work. It is not a replacement for no-code. For the many projects that fit inside a no-code tool's model, no-code is faster and Creatr would be overkill. It is the thing you move to when the project has outgrown the tool, so that crossing the ceiling does not mean a nine-month agency engagement or a from-scratch rebuild. The practical way to use this guide, then, is as a decision, not a ranking. Find your project in the use-case table and use the tool that fits. Watch for the three shared ceilings, because if you are building something with real traction, at least one of them will eventually apply. And when you hit that line - when the tool that got you here cannot take you further, and what you need is owned production software rather than a platform to operate inside - that is the moment a managed build becomes the right next step, not before. The best no-code app builder is the one that matches your job today. Knowing where it ends is what keeps that choice from becoming a trap. --- # https://getcreatr.com/best-no-code-tools-to-build-a-saas-2026 # Best No-Code Tools to Build a SaaS in 2026 (and Where Each One Walls) Best no-code and AI tools to build a SaaS in 2026 compared **Quick answer:** For prompt-to-app speed use Lovable or Bolt; for visual full-stack logic use Bubble; for an Airtable-backed portal use Softr; for a code-owned MVP use a Supabase + Stripe stack. All five get you to roughly 60-70 percent of a real SaaS quickly and then stall at the same wall: production-grade auth with multiple roles, integrations and their failure paths, data correctness, and security. The honest version of this roundup is short on a single winner and long on a map. Most "best no-code tool" lists are vendor placement disguised as advice. They rank tools by feature checklists and affiliate payouts, not by where the tool actually breaks when you put it in front of paying customers. Every tool here is good at something specific. Every one of them hits a wall at the same place, and that wall is not a bug. It is the boundary between scaffolding an app and operating one. Here is the map. Pick by what you are building, not by which tool has the loudest launch. | Tool | Best for | Where it walls | | --- | --- | --- | | Lovable | Prompt-to-app SaaS UI fast | Multi-role auth, edge-case logic | | Bolt | In-browser full-stack prototypes | State sync, integration failure paths | | Bubble | Visual full-stack with real DB | Workload cost, performance, security review | | Softr | Airtable-backed client portals | Custom logic, complex permissions | | Supabase + Stripe | Code-owned MVP, you own the stack | You build the hard 30-40 percent yourself | | Past 70 percent (production) | Real customers, real money, real data | Managed engineering takes it the rest of the way | --- ## The 60-70 Percent Pattern, Stated Plainly Across all of these tools, the first day is genuinely impressive. You describe a CRM, a booking app, a marketplace, and within an hour you have screens, a data model, and clickable flows. That is real progress, not a demo trick. The tools have gotten good at the part of software that is mostly structure: layouts, forms, lists, basic create-read-update-delete. The trouble is that a SaaS is not mostly structure. The first 60-70 percent is the visible part. The last 30-40 percent is the part customers actually pay for, and it is almost entirely invisible until it fails: - **Auth that survives contact with reality.** Not "users can log in." Multiple roles, an admin who can act on behalf of a user, an owner who can invite teammates, a billing seat that differs from a permission seat, password resets that do not leak account existence, sessions that expire correctly. - **Integrations and their failure paths.** Connecting Stripe is easy. Handling a failed renewal, a disputed charge, a webhook that arrives twice, or a webhook that never arrives is the actual work. - **Data correctness.** Two users editing the same record. A counter that must never go negative. A report that has to reconcile to the penny. No-code tools rarely give you transactions or constraints strong enough to guarantee this. - **Security.** Authorization on every read and write, not just the screens you remembered to hide. The default failure mode of visual tools is "the UI hides it but the API still returns it." Keep this pattern in mind as you read each tool below. The strengths are real. The walls are the same wall. --- ## Lovable: Best for Prompt-to-App SaaS UI, Fast **Best for:** Founders who want a polished, working SaaS front end from a prompt, with a real backend wired in behind it. **Strength:** Lovable is the strongest of the prompt-to-app tools at producing a coherent application, not just a landing page. It generates a React frontend and connects a Postgres backend through its [Supabase integration](https://docs.lovable.dev/integrations/supabase), wiring auth, database, and serverless functions from natural language. For a single-role product - one kind of user, straightforward data - you can get remarkably far. The output is real code, which matters when you eventually need to leave. **Where it stalls:** The wall shows up the moment your access model has more than one shape. An admin who manages other users, a per-organization data boundary, a "can view but not edit" role - these require authorization logic enforced at the data layer, and the generated app tends to enforce it at the screen layer. The model is excellent at adding the next feature and poor at reasoning about the whole system's invariants. You ask for a fix in one flow and it quietly changes another. Around the 70 percent mark you stop building features and start fighting regressions. --- ## Bolt: Best for In-Browser Full-Stack Prototypes **Best for:** Technical and semi-technical builders who want to spin up and iterate on a full-stack prototype entirely in the browser. **Strength:** Bolt runs the whole stack in a browser sandbox, so you see the running app immediately and can wire a backend through its [Supabase integration](https://support.bolt.new/integrations/supabase) for database, auth, storage, and edge functions. It is fast for proving a concept and good for builders who can read the code it produces and steer it. Because you can edit the underlying files, you are less boxed in than with a purely visual tool. **Where it stalls:** The same place, plus a state-management tax. As the app grows, keeping client state, server state, and the database in agreement gets hard, and the failure paths around integrations - retries, idempotency, partial failures - are exactly the code the model is weakest at writing correctly. Bolt gets you a working prototype fast; turning that prototype into something that handles a double-charged customer gracefully is a different and much longer job. --- ## Bubble: Best for Visual Full-Stack With a Real Database **Best for:** Non-technical founders building genuinely data-driven products who are willing to learn a real tool. **Strength:** Bubble is the most capable purely visual full-stack builder. It has an actual database, real workflow logic, and a deep plugin ecosystem. Unlike the prompt-to-app tools, Bubble gives you a coherent integrated stack where the data model and the editor speak the same language. Plenty of real products run on it. **Where it stalls:** Three walls. First, cost: Bubble bills compute as Workload Units, and per its [pricing documentation](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans) the overage rate is 0.30 dollars per 1,000 workload units if you have no workload tier subscription, so an inefficient app or a traffic spike turns into a bill you did not model. Second, performance: complex pages and heavy searches get slow, and the optimization levers are limited. Third, the security and correctness wall every visual tool shares - privacy rules are powerful but easy to get subtly wrong, and a missed rule means data is exposed through the API even when the UI looks locked down. Bubble pushes the wall out further than most. It does not remove it. --- ## Softr: Best for Airtable-Backed Client Portals **Best for:** Internal tools, client portals, and directories sitting on top of an Airtable or Google Sheets database. **Strength:** Softr is the fastest way to put a clean, permissioned front end on data you already keep in a spreadsheet-style backend. Its [user groups and permissions](https://docs.softr.io/core-concepts-overview/user-groups--permissions) system handles logged-in versus public users and custom groups for clients or staff, with visibility rules at the UI and data level. For a portal where the data model is simple and the value is access control plus presentation, Softr is hard to beat on time-to-live. **Where it stalls:** Softr is a presentation and permission layer, not an application engine. The moment your product needs custom business logic - calculations, multi-step workflows, conditional automations beyond what the backend offers - you are outside what Softr is built to do. Complex permission models strain the user-group system, and because the database is a spreadsheet underneath, data-correctness guarantees like uniqueness and transactional updates are weak. It is excellent inside its lane and abruptly insufficient just outside it. --- ## Supabase + Stripe: Best for a Code-Owned MVP **Best for:** Founders with a developer (or who are one) who want to own the codebase from day one. **Strength:** This is not no-code, but it belongs on the map because it is what people graduate to. [Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security) gives you Postgres, auth, and Row Level Security so authorization lives in the database where it cannot be bypassed by hitting the API directly. [Stripe Billing](https://docs.stripe.com/billing/subscriptions/overview) handles subscriptions, invoicing, and the lifecycle of recurring payments. Together they are the standard production substrate for a modern SaaS, and you own all of it. **Where it stalls:** It does not stall so much as hand you the bill for the hard 30-40 percent directly. Row Level Security is only correct if you write every policy correctly. Stripe is only reliable if you handle [webhooks](https://docs.stripe.com/webhooks) idempotently - verify signatures, return 200 fast, process asynchronously, and survive duplicate or missing events. Supabase and Stripe give you the right primitives. They do not give you the engineering judgment to assemble them into something that does not corrupt data or leak it. That judgment is the whole job from here. --- ## Which Tool for Which MVP Strip away the vendor noise and the decision is mostly about the shape of your product, not the tool's marketing. - **A single-role SaaS UI you want fast, with real code underneath:** Lovable. - **A full-stack prototype you will steer in the browser and can read the code of:** Bolt. - **A data-heavy product with a genuine database and real workflow logic, no developer on hand:** Bubble - and budget for Workload Units. - **A client portal or internal tool on top of Airtable, where access control is the point:** Softr. - **An MVP you intend to own and grow, with a developer in the building:** Supabase + Stripe. Notice what none of these answers is: "and then you are done." Every path lands you at the same boundary, holding a product that looks finished and behaves like a prototype the first time a real customer does something unexpected. --- ## When No-Code Is Not Enough: The Managed Build There is a category the vendor listicles leave out, because it competes with all of them at once: a managed engineering build. The honest framing is that no-code and AI builders are excellent at the 60-70 percent and structurally weak at the 30-40 percent, and the 30-40 percent is non-negotiable for anything handling real money or real data. You do not get partial credit for auth that mostly works. A permission bug that exposes one tenant's data to another is not a rough edge; it is the end of the product. When you hit that wall, the choice is to learn production engineering yourself, hire a team and wait months, or have the hard part built and operated for you. That last option is the gap [Creatr's DeepBuild](/build-saas-without-coding) is built for: take the validated 60-70 percent and ship the production-grade remainder - real multi-role auth, integration failure paths, data correctness, and security - as working software you own. If you want to pressure-test where your current path walls before you pick, three reads help: [why no-code apps hit scaling problems](/no-code-app-scaling-problems), the [hidden costs in AI app builder pricing](/ai-app-builder-pricing-hidden-costs) that the Workload Unit math above only hints at, and the broader case for [building a SaaS without coding](/build-saas-without-coding) and what that actually requires past the demo. Pick the tool that fits your MVP's shape. Use it to get to 70 percent as fast as it lets you. Just go in knowing that the wall is real, it is the same wall for every tool on this list, and crossing it is where a prototype becomes a product. --- # https://getcreatr.com/best-vibe-coding-tools-2026 # The Best Vibe Coding Tools and AI App Builders in 2026: An Honest Comparison Best vibe coding tools and AI app builders compared in 2026 **Quick answer:** The best vibe coding tools and AI app builders in 2026 sort cleanly by the job in front of you. For a working web app from a plain-English prompt, use [Lovable](https://lovable.dev) for the best-looking UI or [Bolt](https://bolt.new) for full-stack control in the browser, with [Base44](https://base44.com) for internal tools and [Replit](https://replit.com) for a real cloud IDE with an agent attached. For an editor where AI writes most of the code but you stay in control, use [Cursor](https://cursor.com) or Windsurf (now Cognition's [Devin Desktop](https://devin.ai/desktop)). For polished UI components you drop into an existing codebase, use [v0](https://v0.app). For an agent that edits your real repo from the terminal, use [Claude Code](https://claude.com/product/claude-code). Pick by what you are actually building, not by the demo. The caveat that applies to every single one: they get you to a running 60-70% of a product fast, and then the hard 30-40% - multi-role auth, row-level security, integrations that survive failure, and data that stays correct - is left to you. That wall is a property of the category, not a flaw in one tool. Most "best AI app builder" and "best vibe coding tool" lists are affiliate pages dressed up as reviews. They rank tools by which one pays the highest commission and give every entry a glowing paragraph. This one is different. It ranks these tools on real merits, tells you where each one stops, and is honest about the fact that all of them share the same ceiling. If you only take one thing from this piece, take the shared caveat above, because it will save you the six weeks most founders lose discovering it the expensive way. --- ## What vibe coding actually is Vibe coding is a way of building software where you describe the outcome you want in plain language and an AI model generates the underlying code, while you evaluate and refine by looking at the running result rather than by writing or reading most of the code yourself. The name captures the workflow: you are guided by the feel of the output - does it look right, does it do the thing - instead of by line-by-line authorship. An AI app builder is the sub-category that takes this furthest: it turns a prompt into a deployed URL, provisioning the backend for you. That is different from three neighbors people confuse it with. It is not no-code, because there is real code underneath that you can own, export, and eventually hand to an engineer. It is not traditional AI autocomplete, where a developer writes most of the code and the AI finishes lines. And it is not fully autonomous software generation, because a human is still in the loop making judgment calls about what to build next. Vibe coding sits in the middle: the human sets direction and reviews, the AI does the typing. The trap is that the first experience is not the whole job. Building software is roughly two problems glued together. The first is producing screens, flows, and a happy path - the version of your app where one user does the expected thing in the expected order. These tools are extraordinary at this. The second problem is everything that happens when reality shows up: two users editing the same record, an admin who can see things a member cannot, a payment webhook that fires twice, a third-party API that times out at 2am, a report that has to reconcile to the penny. This second problem is where every tool on this list slows down or stops, and we cover exactly why in our breakdown of [why AI-built apps stall at the 80% problem](/why-ai-built-apps-stall-80-percent-problem). There are four families of tools in 2026, and picking the right family matters more than picking the right brand inside it. | Category | What it produces | Who it is for | Representative tools | | --- | --- | --- | --- | | Full-app builders | A deployable web app from a prompt | Founders and non-engineers building v1 | Lovable, Bolt, Base44, Replit | | IDE-based assistants | Edits inside a full code editor you control | People comfortable with a codebase who want speed | Cursor, Windsurf / Devin Desktop | | UI generators | Front-end components and screens | Teams with a codebase who need UI fast | v0 | | Terminal agents | Direct edits to your real repo via CLI | Developers automating multi-file work | Claude Code | Every assessment below uses the same structure: what it is, what it is best at, and where it stalls. No tool wins every category, and the "best" one is entirely a function of what you are trying to ship. Pricing and credit models in this category change every few months, so this piece describes them qualitatively and links to each live pricing page rather than quoting numbers that will be stale by the time you read them. --- ## Full-app builders: the AI app builders This is the family that made vibe coding famous, and the one people mean when they say "AI app builder." You type a description of an app and get back a running, deployable web app - front end, back end, database, and hosting, wired together. No editor to learn, no environment to set up. For non-engineers, and for engineers who want a v1 in an hour, these are the headline tools. ### Lovable: the best-looking output in the category **What it is.** [Lovable](https://lovable.dev) turns a prompt into a running full-stack web app - a React frontend, a [Supabase](https://supabase.com) backend for database and auth, and a live URL. You describe features in prose, it builds them, you describe changes, it changes them. **Best at.** Lovable produces the best-looking UI output of any builder available right now. The default choices - spacing, typography, hover and empty states, component selection - look like a designer made deliberate decisions rather than a model filling a template. Put a Lovable screen next to a screen from a funded SaaS product and a non-technical person genuinely cannot tell which one cost real money. Its iteration loop is tight, and the Supabase integration is the closest thing to magic in the category: auth connects in a click, a table shows up as a UI table. **Where it stalls.** The polish is frontend-deep. When your app's complexity moves into the backend - genuinely distinct roles with different permissions, security rules that hold up when someone pokes at them, integrations that need to behave when the other side fails - Lovable slows down and starts generating plausible code that does not quite hold. The credit model also rewards work you nail on the first pass and quietly penalizes the tweak-look-tweak loop that is most real product work. For the full breakdown, including the credit math and where the wall sits, read our [Lovable review 2026](/lovable-review-2026). ### Bolt: the most full-stack control in the browser **What it is.** [Bolt](https://bolt.new), from StackBlitz, runs a complete development environment in your browser using WebContainers. It does not just generate code and hide it - it runs a real Node environment client-side, so you can install npm packages, run a dev server, edit files directly, and watch the app rebuild, all without anything installed on your machine. **Best at.** Bolt gives you more genuine control over the stack than the prompt-only tools. You are not limited to whatever framework the builder prefers; you can steer toward specific libraries, inspect and edit the actual files, and intervene when the AI goes sideways. For developers and technical founders who want AI speed but refuse to give up the ability to open the code and fix things by hand, Bolt hits a sweet spot the pure no-code tools cannot. **Where it stalls.** More control is a double-edged sword. Bolt assumes you can read and reason about the code it produces, which means non-technical users lose the safety net the moment something breaks. Token and credit consumption can climb fast on larger apps because regenerating and re-running a full project is expensive. And like the rest of the category, the code it produces is a strong first draft of the frontend and happy path, not a hardened backend. See our full [Bolt review 2026](/bolt-review-2026) for where that line falls in practice. ### Base44: the no-code-leaning all-in-one **What it is.** [Base44](https://base44.com) is an all-in-one builder aimed at people who want a working internal tool or business app without touching infrastructure. It bundles the database, auth, hosting, and integrations into a single opinionated package, so there are fewer moving parts to wire together. It became well known after being acquired by Wix. **Best at.** Base44 is strong for internal tools, dashboards, CRUD-heavy business apps, and the kind of software a small team needs to run operations rather than sell to the public. Because it hides more of the plumbing, a non-technical founder can get further before hitting something they cannot do themselves. **Where it stalls.** The same opinionation that makes it approachable becomes a ceiling when you need something the platform did not anticipate. Custom logic that falls outside the built-in patterns, unusual integrations, and fine-grained permission models are where the abstraction starts to fight you. Our [Base44 review 2026](/base44-review-2026) goes deeper on where the all-in-one model helps and where it hems you in. ### Replit: a real cloud IDE with an agent attached **What it is.** [Replit](https://replit.com) is a full cloud development environment that has existed for years and added a capable AI agent on top. Unlike the prompt-first builders, Replit is a real IDE first: a terminal, a file tree, package management, databases, deployment, and collaboration, with an agent that can build and modify projects inside that environment. It sits a little between the IDE family and the full-app family. **Best at.** Because Replit is a genuine development platform, it does not hit the "the AI broke it and now I am trapped" wall as hard as the pure builders. When the agent gets something wrong, you have a real environment to drop into and fix it. It supports many languages rather than locking you to one web stack, handles deployment natively, and is a good bridge for someone growing from vibe coding toward understanding the code underneath. **Where it stalls.** Having access to the code is not the same as reviewing it. The agent will produce a working app quickly, and the responsibility for whether the data model and permissions hold up under real load still lands on you. The environment gives you the tools to check; it does not do the checking. Non-technical founders can also get overwhelmed by the surface area. The full-app family is the right starting point for most founders. It is unbeatable for going from nothing to a testable product. Its shared limit is that it produces the visible 60 to 70 percent - the part that demos - and leaves the invisible remainder to you. --- ## IDE-based assistants: Cursor and Windsurf (Devin Desktop) This family is for people who are at least a little comfortable living inside a code editor. You get an editor that looks and feels like a professional development environment, with an AI layered through it that can write, refactor, and explain code across your whole project. You are still the one deciding what happens, but the AI does most of the typing. ### Cursor **What it is.** [Cursor](https://cursor.com) is an AI-native code editor - a fork of the familiar VS Code environment with deep model integration. You can chat with your entire codebase, ask for multi-file changes, and let an agent mode plan and execute larger tasks while you supervise. **Best at.** Working inside a real, growing codebase. Cursor shines when you already have a project and want to move through it fast: renaming things safely across dozens of files, generating a new module that matches your existing patterns, or debugging with the model aware of your whole repo. For anyone who can already read code, it is one of the highest-leverage tools available, because it operates at the level where the hard problems actually live - the auth logic, the security rules, the integration error handling. **Where it stalls.** Cursor assumes you can read code and catch a bad suggestion. That is a feature for engineers and a trap for everyone else. If you cannot tell that the auth check the model just wrote is subtly wrong, Cursor will happily let you ship it. It accelerates whoever is driving - a strong engineer goes faster, and a beginner generates plausible-looking mistakes faster too. If you are shopping around, we did a longer breakdown in our [Cursor alternatives guide](/cursor-alternatives-2026). ### Windsurf, now Devin Desktop **What it is.** Windsurf is another AI-native editor built around an agentic workflow, with a tighter loop between you and an agent that keeps context on what you are doing. Its bigger story this year is corporate: it was absorbed by Cognition, the company behind Devin, and is being rebranded as [Devin Desktop](https://devin.ai/desktop). If you care about product stability, that history matters, and we cover the full comparison in [Cursor vs Windsurf](/cursor-vs-windsurf-2026). **Best at.** Longer, multi-step tasks where you want the agent to keep momentum - carrying context across a sequence of edits without you re-explaining the goal each time. Teams that like the agent-first framing often prefer its flow to a more manual assistant. **Where it stalls.** Same ceiling as Cursor. The agent is confident and fast, and confidence is not correctness. The more autonomy you give an agent inside a real codebase, the more you need someone who can review the diff before it becomes production behavior. It makes the generation cheap; it does not make the review optional. The IDE family is the most powerful of the four for anyone who can read code, and the least forgiving for anyone who cannot. Pricing runs on tiered subscriptions with usage-based model costs on top; check the current plans on each site, since they change often. --- ## UI generators: v0 **What it is.** [v0](https://v0.app), from Vercel, generates front-end UI - components, layouts, whole screens - from a prompt or an image, producing clean, framework-ready code you paste into an existing project. It started as a UI tool and has grown toward full apps, but it is narrower than the full-app builders on purpose. **Best at.** Front-end velocity for teams that already have a codebase and a backend. For anyone already living in React, Next.js, Tailwind, and shadcn/ui, v0 is the most natural fit on this list. The code it produces is idiomatic, clean, and meant to be integrated rather than kept behind a wall - you own the output and drop it into your project. The Vercel integration makes going from generated screen to deployed page nearly frictionless. **Where it stalls.** v0 does not pretend to build your backend, your data layer, or your auth, so its "stall" is really a scope boundary: it hands you a great front end and expects a competent team to wire it into a safe system. It also assumes React fluency; the more you want to steer or fix the output, the more you need to actually know React and Next.js. Used as intended, that focus is a feature. Used as a shortcut to a whole product, it leaves the hardest 40 percent entirely unaddressed. --- ## Terminal agents: Claude Code **What it is.** [Claude Code](https://claude.com/product/claude-code) is an agentic coding tool that lives in your terminal and operates directly on your real repository. You give it a task in plain language and it reads files, makes edits across your project, runs commands, and iterates - all against the actual codebase on your machine. **Best at.** Real engineering work that spans many files: implementing a feature end to end, doing a large refactor, writing tests, tracing and fixing a bug across modules. Because it works on your genuine repo with your genuine tooling, it fits naturally into a professional workflow where the output goes through version control and review. In the hands of an engineer, it is one of the most capable members of the family precisely because it does not hide the code from you. **Where it stalls.** It is a power tool, and power tools reward skill. Claude Code assumes you have a repo, a review process, and the judgment to evaluate a large diff before you commit it. Point it at a serious task with no one able to review the result and you get the same underlying risk as everywhere else in this guide, just applied to more files faster. The tool is not the safeguard; the human reading the diff is. --- ## The adjacent one: Builder.io for design-to-code **What it is.** [Builder.io](https://www.builder.io) approaches the problem from the design and content side. It is a visual development platform with AI that can turn designs, including Figma files, into code and let teams edit and compose interfaces visually while keeping developer control underneath. It is more of a design-to-code and visual CMS play than a prompt-to-app builder. **Best at.** Builder.io shines when the starting point is a design rather than a sentence, and when non-technical team members need to edit and publish content or pages without going through engineering for every change. For marketing sites, content-heavy front ends, and teams that want designers and marketers to move without a developer bottleneck, it fills a real gap the prompt-first builders do not. **Where it stalls.** It is not aimed at building the complex, stateful, backend-heavy application - it is aimed at the presentation and composition layer. The deep application logic, multi-role security, and resilient data plumbing are outside its lane by design. It solves a different slice of the problem, which is exactly why it belongs on an honest list: knowing which tool solves your slice is most of the decision. --- ## The head-to-head capability matrix Here is how the main full-app builders line up on the dimensions that actually decide a project. "Strong" means genuinely best-in-class, "Good" means solid and usable, and "Limited" means possible but with real friction. | Capability | Lovable | Bolt | Base44 | Replit | v0 | | --- | --- | --- | --- | --- | --- | | UI polish out of the box | Strong | Good | Good | Limited | Strong | | Speed from prompt to running app | Strong | Strong | Strong | Good | Good | | Backend and database wiring | Good | Good | Strong | Good | Limited | | Code ownership and editability | Good | Strong | Limited | Strong | Strong | | Fit for non-technical founders | Strong | Limited | Strong | Limited | Limited | | Recovery when the AI breaks it | Limited | Good | Limited | Strong | Good | | Multi-role auth and security depth | Limited | Limited | Limited | Limited | Limited | Notice the last row. Every column is "Limited." That is not an accident of this table - it is the entire point of the article. The tools differ meaningfully on polish, control, and approachability, and they converge completely on the one thing that separates a demo from a product. --- ## Which tool for which job Match the row to what you are actually trying to do this week, not to what you might do someday. | Your goal | Best fit | Why | | --- | --- | --- | | Validate an idea with a clickable app today | Lovable, Bolt | Prompt to live app in under an hour | | Get the best-looking prototype in front of users | Lovable | Best-looking output, tightest iteration loop | | Build an internal tool for a small team | Base44, Replit | Standard CRUD and workflows assembled fast | | Keep your hands on the code in the browser | Bolt | Real in-browser environment, editable files | | Move fast inside an existing codebase | Cursor, Windsurf / Devin Desktop | AI across a real project you control | | Add polished UI to a real front end | v0 | Clean, framework-ready components | | Ship a multi-file feature or refactor | Claude Code | Agentic edits on your actual repo | | Turn designs into editable pages | Builder.io | Design-to-code with visual editing | | Learn the code while it gets built | Replit | Real environment you can open and edit | | Get the whole thing shipped to production, done | A managed build | The last 30% built, not deferred | That last row is the one most comparison articles pretend does not exist, and it is where this piece is going. --- ## The thing they don't tell you: the shared wall Every tool above is real, useful, and worth your time. This is not a warning against vibe coding - it is the fastest way to build software that has ever existed, and pretending otherwise is dishonest. But there is a shared limit, and the marketing pages will not lead with it because leading with it would slow the sign-up. The limit is this: AI-generated code is optimized to produce a result that looks and behaves correctly on the surface, and the surface is not where software fails. The parts that decide whether an app survives contact with real users are the parts you cannot see in a demo - whether authentication actually blocks the wrong people, whether the database enforces who can read what, whether a failed payment or a dropped API call is handled instead of silently swallowed, whether the data stays correct when two things happen at once. These layers do not show up in the UI. An app can be leaking data and look completely finished. The reason this matters more with vibe coding than with hand-written code is not that AI makes more mistakes. It is that the person shipping often cannot see the mistakes, because they never wrote the code and the tool never surfaced the decision. We documented what that looks like in practice in our writeup on [vibe coding security risks](/vibe-coding-security-risks), and the slower-burning version - working apps that accumulate hidden fragility - in our piece on [vibe coding technical debt](/vibe-coding-technical-debt). Here is the honest breakdown of where the tools take you and where they stop. | The hard 30-40% | Why these tools stall here | What it costs if it is missing | | --- | --- | --- | | Multi-role auth | Roles interact in ways a prompt cannot fully specify; edge cases multiply | Users see data they should never see | | Row-level security | Correct rules require reasoning about every access path, not a happy path | A single leak becomes a breach | | Integration failure handling | The demo assumes the third party always responds; reality does not | Silent data loss, double charges, stuck states | | Data correctness | Concurrency, reconciliation, and consistency are invisible until they break | Reports that do not add up, trust gone | | Scale and performance | Generated queries are correct-ish, not tuned; they fall over under load | The app dies exactly when it succeeds | The reason this wall is so consistent is that the first 60-70% of an app is pattern-shaped work - screens, forms, CRUD, a happy path - and pattern-shaped work is exactly what a language model is best at. The last 30-40% is judgment-shaped work. It requires reasoning about what happens when things go wrong, who is allowed to do what, and whether the numbers are actually right. That is a different kind of problem, and it does not yield to a better prompt. The practical failure mode looks the same every time. A founder builds 70% in a weekend, feels unstoppable, and then spends the next two months fighting the remaining 30% - hiring a contractor to untangle the generated auth, discovering a security hole after a user finds it first, or quietly rebuilding the backend because the generated one cannot handle a real load. The speed at the start is real. The wall at the end is also real. Both things are true. --- ## Where these fit versus classic no-code It is worth situating these tools against the older no-code and low-code world, because founders often confuse the two. Classic no-code tools trade flexibility for reliability inside a fixed set of patterns - you get less freedom, but what you build tends to work because you are staying on rails the platform hardened. Vibe coding tools trade the opposite way: near-total flexibility at the frontend and happy-path layer, and far less certainty that the hard parts are correct, because the model generates rather than constrains. Neither is strictly better. If your app fits cleanly inside a no-code platform's assumptions, the no-code route can be more durable than a pile of generated code. If your app needs a custom UI and custom flows, the AI builders win on the front half and lose on the back half. We mapped the full landscape, including where each option holds up under a real SaaS, in our guide to the [best no-code tools to build a SaaS in 2026](/best-no-code-tools-to-build-a-saas-2026). Read it alongside this one: together they cover both halves of the build-versus-buy-versus-generate decision. --- ## So which is the best? The honest answer is that there is no single winner, and any article that gives you one is selling something. The best tool is the one whose strengths match the job in front of you. Want the prettiest prototype fastest? Lovable. Want to keep your hands on the code in the browser? Bolt. Building an internal tool without wanting to think about infrastructure? Base44. Working outside the standard web stack in a real cloud IDE? Replit. Living in React on Vercel? v0. Already an engineer working in real code? Cursor, Windsurf, or Claude Code is a more powerful lever than any of the builders. But there is a second question underneath the first, and it is the one that actually determines whether your project succeeds: not "which tool builds the fastest 70%," but "who builds the 30% that these tools structurally leave undone?" For a lot of people the honest answer to that second question is not another tool at all. It is either learning enough engineering to finish it yourself, hiring someone to finish it, or having it finished for you. --- ## When you need the last 30% done, not deferred Every tool on this list stops at roughly the same place, and that place is exactly where a real product begins. When you need the hard part - the multi-role auth that holds, the security that survives someone testing it, the integrations that handle failure instead of assuming it never happens, the data that stays correct under load - actually built rather than left as a TODO, that is a different kind of work than any prompt-to-app tool is built to do. That is the gap [Creatr](https://getcreatr.com) fills. We build, host, and run production-grade software for you. Not a scaffold that gets you to 70% and hands you the cliff - the whole thing, including the last 30% that the tools above defer. You can bring us a vibe-coded prototype that got you 70 percent of the way and needs the hard remainder done properly, or start with us and get it built right from the first line. Either way, real humans stay in the loop on the parts that decide whether an app is safe, you own the code, and the turnaround is measured in 24 hours, not months. So use the vibe coding tools. They are legitimately great at what they do, and this whole article stands behind that. Prototype with Lovable, iterate with Bolt, spin up an internal tool with Base44, deploy a component from v0, refactor with Claude Code. Just go in knowing where the road ends - and know that when you need to cross the wall instead of camping at it, there is a way to have the finished product built for you in a day instead of spending two months discovering the last 30% the hard way. --- # https://getcreatr.com/bolt-alternatives-2026 # Bolt.new Alternatives in 2026 Bolt.new alternatives for production web apps in 2026 **Quick answer:** If you want a faster prompt-to-prototype loop, Lovable or v0 fit; if you write code, Cursor or Replit fit; if you need the hard backend done right - real server-side auth, locked-down data, integrations that survive failure - Creatr is the managed option that hands you owned production code. Bolt.new is good at one thing and it is genuinely good at it: you type a sentence, and 90 seconds later a working web app is running in your browser. For a landing page, an internal demo, or a pitch prototype, that speed is real and worth paying for. The problem starts the moment you try to put a Bolt app in front of real users with real data. Bolt is frontend-first by design. It writes React in the browser, wires Supabase as the backend, and gets you to something that looks finished fast. But "looks finished" and "safe to ship" are different claims, and the gap between them is where almost every Bolt project stalls. Below is an honest look at the alternatives a reader actually considers, and where each one walls off. | Alternative | Best for | Where it walls | | --- | --- | --- | | Lovable | Prompt-to-prototype, design-led MVPs | Same Supabase RLS and auth gaps as Bolt | | v0 (Vercel) | UI and component generation | Frontend only, you build the backend | | Cursor | Developers writing real code | Assumes you can code and review it | | Replit | Coders who want hosting included | Still a DIY build-and-maintain model | | Creatr (managed build) | A production app you own, built for you | Not DIY - it is a managed service | ## What Bolt Actually Gets Wrong The failures are not random. They cluster in one place: the boundary between the browser and the server. A Bolt app puts your Supabase keys in client-side code. The publishable (anon) key is meant to be public, and that is fine - if every table has Row Level Security policies enforcing who can read and write what. AI-generated apps frequently skip RLS entirely. Security researchers have repeatedly found Supabase databases left wide open this way; in one early-2026 case documented by Wiz, an exposed database leaked 1.5 million API tokens and 35,000 email addresses because anyone with the public key could read every row. The [Supabase Row Level Security docs](https://supabase.com/docs/guides/database/postgres/row-level-security) are explicit that without policies, your data is open by default. Worse is the service-role key. That key has `BYPASSRLS` - it ignores every policy and is meant only for your backend. When you ask an AI builder to add an admin feature, it hits the RLS wall, and a common "fix" is to switch to the service-role key in client code rather than move the call server-side. Now an admin credential is sitting in a JavaScript bundle anyone can read. Supabase's own [API keys guide](https://supabase.com/docs/guides/api/api-keys) warns this key must never reach the browser. The third failure is auth that only exists on the frontend. Bolt will happily render a route that checks `if (user.role === 'admin')` in React and hides the admin panel otherwise. That is not security. Anyone can open dev tools, call the API directly, and the server - which never checks the role - answers. Frontend auth is a UI convenience, not an access control. We wrote about this pattern in depth in [vibe-coding security risks](/vibe-coding-security-risks). None of these are exotic edge cases. They are the default output for the most common things an app needs: a login, a role, a private record. The reason they slip through is that the app looks correct - the admin panel is hidden, the login works, the data shows up for the right user in the demo. Nothing visibly fails. The failure is invisible until someone goes looking, and by then the app is live with real user data behind it. That is the worst possible time to learn that the security model was never real. ## The Token-Burn Spiral Here is the part that costs money. When you discover the auth is broken and ask Bolt to fix it, you enter a loop. The model patches the symptom, breaks an adjacent thing, you re-prompt, it patches that. Each round consumes tokens. Bolt's [pricing](https://bolt.new/pricing) runs on a token model: a free tier with a daily cap, and Pro at $25/month for a monthly allowance. Generating a UI is cheap. Debugging a security model the tool does not really understand is not - it is the most token-expensive thing you can do, because the model is reasoning across the whole app every turn. Founders routinely report blowing through a month of tokens fixing auth and data access that should have been correct the first time. The cheap prototype becomes an expensive thing that still is not safe to ship. There is a second, quieter cost. Every fix the model makes is a fix you did not design and cannot fully verify, because you are not reading the code. You are trusting that "I fixed the auth" means the auth is fixed. When the same class of bug reappears two prompts later, you have no way to tell whether it is a new bug or the old one that was never actually closed. The token meter is the visible cost. The invisible cost is shipping on top of changes you cannot audit. ## Lovable: Same Speed, Same Wall [Lovable](https://lovable.dev) is the closest like-for-like alternative and arguably has a nicer design sensibility - apps come out looking more polished. But Lovable runs on the same architecture: React frontend, Supabase backend, keys and logic that lean toward the client. That means the failure mode is identical. You get to 60-70% fast, the UI is even prettier, and then you hit the same RLS, the same frontend-only auth, the same need to move sensitive logic server-side. If you are choosing between Bolt and Lovable on prototype quality, Lovable is a reasonable pick. If your actual problem is the hard backend, switching from Bolt to Lovable does not solve it - we cover that distinction in [Bolt vs Lovable](/bolt-vs-lovable). ## v0, Cursor, and Replit: Different Tools, Different Tradeoffs [v0](https://v0.dev) from Vercel is excellent at generating UI - components, layouts, full page designs from a prompt or a screenshot. But v0 is honest about its scope: it produces frontend. You still own building the backend, the auth, the data layer, and the integrations. For a designer or frontend developer who wants a head start on the interface, v0 is great. For a non-technical founder who needs a whole app, it is a fraction of the job. [Cursor](https://cursor.com) is the best AI-enhanced IDE available, with a reported $500M ARR. But it is an IDE - a tool for people who write and read code. If you can review what it generates and catch the service-role key in the bundle yourself, Cursor is powerful. If you cannot, an IDE does not help, because the whole tool assumes coding knowledge you would be paying to avoid. [Replit](https://replit.com) bundles an AI agent with hosting, so you build and deploy in one place. That is convenient, but it is still a DIY model: you are the one responsible for the app being correct, secure, and maintained over time. Replit removes the deployment friction. It does not remove the part where someone has to own getting auth and data right. ## Where Creatr Is Different Every alternative above is a tool you operate. The faster ones (Bolt, Lovable, v0) hand you a frontend-heavy prototype and the hard 30-40% becomes your problem. The developer ones (Cursor, Replit) assume you can solve that 30-40% yourself. Creatr is not a tool you operate. It is a managed service. You describe what you need, and Creatr delivers a complete, deployed application - database, authentication, integrations, deployment - as code you own. The difference that matters for the Bolt failure mode: the hard 30-40% is built as part of the deliverable, server-side, by people who treat RLS, real multi-role access control, and secret handling as the baseline rather than the thing you discover is missing in week three. Concretely, against the three Bolt failures: - Keys and admin logic live server-side, not in a client bundle. - Access control is enforced on the server, so a route check in React is decoration, not your security boundary. - Integrations are built with their failure paths - what happens when the payment webhook retries, when the email provider is down, when an API returns a 500. Be honest about the tradeoff: this is not DIY. You do not sit in an editor and prompt your way to a result. If your goal is the experience of building it yourself, or you only need a throwaway prototype, Bolt or Lovable is the right call and Creatr is overkill. Creatr fits when you need a real product, in production, and you want to own the source code rather than rent a prototype. ## How to Choose The honest decision tree is short. Need a prototype, a demo, or a landing page this afternoon? Bolt or Lovable, and do not over-invest. Want the prettiest prototype? Lovable. Just need UI? v0. Can you read and review code? Cursor, or Replit if you want hosting bundled in. Need an app that real users and real data depend on, with auth and integrations that hold up under attack and under failure, and you want to own the code? That is the 30-40% that the prompt-to-prototype tools leave for you and that the IDEs assume you can do yourself. That is the case Creatr is built for - a managed build that ends with production code in your hands, not a prototype that stalls at the security model. --- # https://getcreatr.com/bolt-review-2026 # Bolt.new Review 2026: Is It Worth It? Bolt.new review 2026 - is it worth it **Quick answer:** Bolt is worth it for code-literate builders who want a fast in-browser prototype, a real deployed URL, and a Supabase-wired demo in minutes. It is not worth it as your production system - the token-metered model, session context drift, and default auth and RLS gaps mean the last 30-40% is still yours. That is where a managed build like Creatr fits. Most reviews of [Bolt.new](https://bolt.new) answer the wrong question. They ask whether it can build an app. It can - fast, in your browser, with a live URL at the end. The question that actually decides whether it is worth your money and your months is narrower: what happens after the demo works? That is where this review lives. Bolt is genuinely good at one thing. Type a sentence and roughly 90 seconds later a working web app is running in the browser. For a landing page, an internal demo, or a pitch prototype, that speed is real and worth paying for. The trouble starts the moment you try to put that app in front of real users with real data. So let us split the verdict cleanly: what Bolt does well, where it hits the wall, and who it is actually worth it for. ## What Bolt.new is and how its pricing works Bolt is a browser-based AI IDE. It runs a full Node environment in the tab through WebContainer, starts building immediately, shows you the actual files rather than hiding the machinery, and supports over 50 languages and frameworks rather than locking you into one stack. It wires Supabase for the backend, deploys with one click, and ships a product - [Bolt Cloud](https://bolt.new/cloud) - aimed at the fragile-infrastructure problem it identified in vibe-coded apps. The pricing is where the review gets sharp, because it is not a flat subscription - it is metered by tokens. A free tier gives you a daily cap. Bolt's day-rate plan runs $14 a month for 10 million tokens daily, and Pro sits at $25 a month for a monthly allowance. Generating a UI is cheap. The expensive thing is debugging, because the model reasons across the whole app on every turn. That distinction matters more than the headline number. Bolt's own docs acknowledge that "apps that use external APIs or AI features may consume significantly more tokens during runtime" - so the meter does not stop when you close the laptop. The advertised entry tier is a demo environment, not a production budget. A realistic B2B build - base plan, a second editor seat, usage overage, API passthrough markup, a support tier - lands closer to $135-160 a month than the sticker price. We break that math down in [AI app builder hidden costs](/ai-app-builder-pricing-hidden-costs). The pattern to remember: the bill is set by debugging loops, not by the build. ## What Bolt does genuinely well Credit where it is due, because a fair review has to name the wins: - **Time to first output is best-in-category.** Nothing else gets from prompt to a running app faster. For prototypes, hackathon projects, and proofs of concept, that speed is the whole value. - **WebContainer is real.** A full dev environment in the browser tab means no local setup, no dependency wrangling, and instant preview. You are iterating in seconds. - **It shows its work.** Unlike tools that hide everything behind visual output, Bolt exposes the actual files. If you can read code, you can see exactly what it wrote. - **Stack flexibility.** Bolt is not tied to React and Supabase. If you have an existing database, an existing API, or a framework preference, it can work with it. - **Supabase in one click, deploy in one click.** Auth connects, a table becomes a UI, and a live URL exists at the end. For a demo, that loop is close to magic. If your goal is a throwaway prototype or a thing to validate an idea this afternoon, Bolt earns its price on these strengths alone. The review would end here if prototypes were all anyone built. They are not. ## Where Bolt hits the wall The failures are not random. They cluster at one boundary - between the browser and the server - and they are invisible in the demo, which is exactly why they are dangerous. **Session context drift.** Bolt starts building from your description and makes common-case assumptions to keep moving fast. As a build grows across sessions, the model loses the thread of what the whole system is supposed to do. It patches the screen in front of it without auditing the twenty other screens the change should touch. The structural decisions - who can read which data, what happens when a payment fails - were never established, so they cannot be enforced consistently later. **The schema gets built prompt by prompt.** A real data model is designed up front. In Bolt, it accretes one feature at a time. Each new role, each new table, each new integration is a fresh prompt treated as a new feature rather than a change to a connected whole. By session 15 you have a schema nobody designed for the thing you are actually building. **Auth and RLS defaults.** This is the expensive one. Bolt puts your Supabase keys in client-side code. The publishable anon key is meant to be public - fine, if every table has Row Level Security policies. AI-generated apps frequently skip RLS entirely; [Supabase's own docs](https://supabase.com/docs/guides/database/postgres/row-level-security) are explicit that without policies your data is open by default. A researcher who audited 50 vibe-coded apps across Bolt and its peers in early 2026 found 88% had RLS entirely disabled - absent, not misconfigured. Worse is the service-role key, which ignores every policy and is meant only for the backend; a common "fix" when the model hits the RLS wall is to switch to it in client code, dropping an admin credential into a JavaScript bundle anyone can read. [Supabase's API keys guide](https://supabase.com/docs/guides/api/api-keys) warns that key must never reach the browser. And frontend auth - a `user.role === 'admin'` check in React - is a UI convenience, not access control, because the server never checks. **Unpredictable debug cost.** When you find the auth is broken and ask Bolt to fix it, you enter a loop: the model patches the symptom, breaks something adjacent, you re-prompt, it patches that. Every round burns tokens. One developer documented spending over 500,000 tokens fixing a single authentication issue - not building anything new, just closing one bug that had been broken since the start. The credits consumed debugging a production problem routinely exceed the credits spent building the feature in the first place. That is the metered model's sharpest edge. None of this is exotic. It is the default output for the most common things an app needs - a login, a role, a private record. Altar.io's comparison of five tools in this category found they all reach 60-70% of a real product and stall at the same 30-40%. Bolt is fast to the wall. It does not get you over it. ## Is Bolt worth it? Verdict by user type The honest answer depends entirely on what you are building and who you are. | User type | Is Bolt worth it? | Why | | --- | --- | --- | | Prototyper or hackathon builder | Yes | Fastest prompt-to-running-app in the category. Ship the demo, do not over-invest. | | Code-literate developer | Yes, with eyes open | You can read the output, catch the service-role key in the bundle, and write the RLS it skips. Budget for debug-loop tokens. | | Designer needing UI fast | Partly | It works, but a UI-first tool may fit better; Bolt's design defaults are functional, not designer-grade. | | Non-technical founder building a demo | Yes | Great for validating an idea or showing investors something real. | | Non-technical founder shipping production | No | The auth, RLS, and integration-failure work is the 30-40% Bolt leaves for you - and you are not equipped to review it. | | Team needing multi-role access + real integrations | No | Access control across many screens and failure-handling for payments and webhooks is exactly what stalls here. | The line runs down the middle of the category. If you value the experience of building it yourself, or you only need something that looks finished for a demo, Bolt is a reasonable pick. If the app has to be correct - real users, real data, real money - the tool takes you to 60-70% and stops. We map that wall across every major tool in [Bolt.new alternatives](/bolt-alternatives-2026), and against its closest rival in [Bolt vs Lovable](/bolt-vs-lovable). Switching to Lovable does not solve it - same Supabase architecture, same wall. ## When to graduate off Bolt, honestly There is a specific moment builders describe: the demo works, the screens look real, and then something the prompts cannot fix appears. Access control that has to hold across twenty screens. A Stripe integration that has to handle failure, not just the happy path. A schema that has to stay correct when two users hit it at once. That is the signal to graduate - not because Bolt failed, but because you have crossed from prototype into production, and those are different destinations. Creatr is one option for that last part, and it is a genuinely different shape of thing - not a tool you operate. It is a managed service: you describe the product, and a complete, deployed application gets built and handed to you as code you own, with the hard 30-40% done rather than deferred. Against the three Bolt failure modes specifically: keys and admin logic live server-side, not in a client bundle; access control is enforced on the server, so a React route check is decoration rather than your security boundary; and integrations are built with their failure paths - what happens when the payment webhook retries, when the email provider is down, when an API returns a 500. You can see how the two stack up directly on our [Creatr vs Bolt](/vs/bolt) page. Be honest about the tradeoff, because a review that only sells is not a review. Creatr is not DIY. You do not sit in an editor and prompt your way to a result, and if that experience is the point, or you only need a throwaway prototype, Bolt is the right call and Creatr is overkill. Creatr fits the opposite case: you need a real product in production, and you want to own the source code rather than rent a prototype that stalls at the security model. So - is Bolt.new worth it in 2026? For a fast prototype in capable hands, yes, and it is one of the best at that. As the system your business runs on, no - and the tell is that the money and the months both get spent after the demo works, not before. --- # https://getcreatr.com/bolt-vs-lovable # Bolt vs Lovable: Honest Comparison for Founders Who Need to Ship Bolt vs Lovable comparison for founders 2026 **Quick answer:** Bolt is the fastest path to running, code-transparent, stack-flexible output; Lovable produces the best-looking UI with the tightest Supabase integration. Both stall at the same 60-70% wall on access control, integration failure handling, and data correctness - so pick on visual style and stack, then plan for the 30% neither finishes. Around session 15, something changes. The Lovable build has been going well. The UI looks genuinely impressive - better than anything you would have gotten from six months of freelancer back-and-forth. You have shipped screens, iterated on flows, shown it to people who said it looked real. And then you hit something the prompts cannot fix. Access control that needs to hold across twenty different screens. A Stripe integration that needs to handle failure, not just success. A database that needs to stay correct when two users hit it at the same time. The explanation most founders land on at this point: wrong tool. So they switch to Bolt. This post is about what they find on the other side - and why the comparison most founders are running is the wrong comparison to run. | Dimension | Bolt | Lovable | | --- | --- | --- | | Best for | Fast prototypes, demos, code-literate builders | Polished UI, screen-first founders | | UI quality | Functional, less designed | Best-in-category, designer-grade defaults | | Stack flexibility | 50-plus languages and frameworks | Opinionated React and Supabase | | Code transparency | Shows the actual files | Hides machinery behind visual output | | Cost model | Metered, debug loops spike the bill | Subscription with build limits | | Where it stalls | Access control, integration failures, data model | Multi-role auth, RLS, billing edge cases | --- ## What Lovable Actually Is Before the wall, there is a reason Lovable [raised $330 million at a $6.6 billion valuation](https://techcrunch.com/2025/12/18/vibe-coding-startup-lovable-raises-330m-at-a-6-6b-valuation/) in December 2025. The tool is genuinely good at something specific. Lovable produces the best-looking UI output of any AI builder currently available. The default choices - spacing, component selection, hover states, empty states, typography - look like a designer made deliberate decisions about all of them. Put a Lovable screen next to a screen from a Series A SaaS product and a non-technical person cannot tell which one cost $200,000 to build and which cost twenty minutes. That is a real achievement, not a marketing claim. The iteration loop is tight. Ask for a change, get the change, without the model drifting into rewrites of things you did not ask to touch. For founders who think in screens - who understand their product by looking at it rather than describing it in prose - Lovable fits the way they think. The Supabase integration is the closest thing to magic in this category. Auth connects in one click. A database table becomes a UI table without a custom query layer in between. For apps where the complexity lives in the frontend - a SaaS with a clean, linear happy path, a visual dashboard, a prototype a designer wants to validate with real users - Lovable is the fastest tool in the category for getting there. That is the specific shape where it works. When the app is mostly UI and the backend is mostly Supabase defaults, Lovable is a strong choice and the strongest in the category. --- ## Where Lovable Stops Working The wall is not a UI problem. The UI keeps working fine all the way to the wall. The problem is everything behind it. The moment a second user role enters the picture, the tool changes character. A manager who should see aggregate numbers but not individual records. A client-facing view that shows a subset of what an admin sees. An external auditor who gets read-only access to a specific date range. Each of these is a separate prompt. Each prompt adds a check to the screen you are looking at when you type it. None of them audit the other twenty screens to verify the check holds there too. Row-level security in Supabase - the mechanism that enforces at the database level that one user's query cannot return another user's data - requires explicit policy definitions. Lovable does not write them unless you specifically ask. Most founders do not know to ask, because the concept is not obvious until something goes wrong. A researcher audited 50 vibe-coded apps across Lovable, v0, Bolt, Cursor, and Claude Code in early 2026. 88% had Supabase row-level security entirely disabled. Not misconfigured - entirely absent. In 24% of the apps, the authentication logic was inverted: authenticated users were locked out while unauthenticated users had full access. These were not unfinished apps. Many were live, in front of real users. The full list of failure modes - and what to check before you ship - is in our breakdown of [vibe coding security risks](/vibe-coding-security-risks). Stripe exposes the same pattern more clearly than any other integration. Getting a card charged in the happy path is one prompt and it works. What a real billing system needs is different: the webhook that fires when a subscription lapses, the retry logic when a payment fails, the customer portal for managing seats, the database state that reconciles after a webhook fires, the email that confirms the charge went through. Each of those is a separate prompt in Lovable. The tool treats each as a new feature. It does not hold the billing system as a connected whole that it is responsible for keeping correct. When webhook signature validation fails silently in production, the UI looks fine. The data is wrong. The founder finds out when a customer calls. There is a separate issue at the company level. In December 2025, the same month as the fundraise, Lovable's CEO described the product's ambition as becoming ["the last piece of software companies ever buy."](https://fortune.com/2025/12/18/lovable-ai-vibe-coding-last-piece-of-software-ceo/) Four months later, a security researcher disclosed that every Lovable project created before November 2025 had been exposed for 48 days. Any free account could read another user's source code, Supabase credentials, AI chat histories, and customer data. The researcher's description of the difficulty of the exploit: "This is not hacking. This is five API calls from a free account." It was the company's third major security incident in thirteen months. --- ## What Bolt Actually Is Bolt is the fastest tool in the category for getting to running code. The browser-based IDE starts building immediately, the first output appears in under a minute, and the platform supports over 50 languages and frameworks rather than Lovable's opinionated React and Supabase stack. For founders who want transparent access to the code being written - not just the visual output but the actual files - Bolt shows its work in a way Lovable does not. The speed advantage is real at the start. For prototypes, throwaway demos, hackathon projects, and proofs of concept where the goal is to have something running as fast as possible, nothing in the category matches Bolt's time to first output. The flexibility is also real. Bolt is not tied to Supabase. It is not opinionated about your stack. If you have an existing database, an existing API, or a technology preference, Bolt can work with it in a way Lovable cannot. For developers who are already code-literate and want AI assistance writing code faster rather than an AI that writes code on their behalf, Bolt sits closer to that use case. --- ## Where Bolt Stops Working Bolt built a whole product - [Bolt Cloud](https://bolt.new/cloud) - around what it framed as vibe coding's fatal flaw: apps that crumble under real-world traffic because they run on fragile infrastructure prone to bugs, downtime, and data loss. They were not wrong about the symptom. But the diagnosis stopped at infrastructure. The actual cause runs deeper: Bolt, like Lovable, starts building from whatever description you give it. The structural decisions that determine whether a production app works correctly - who can read which data, what happens when a payment fails, whether the Supabase keys in the compiled JavaScript are the admin keys or the public-safe anon keys - get made by the model based on common-case assumptions. The assumptions produce an output that looks correct in the demo. They surface in production, usually in front of real users. The cost structure adds a dimension that Lovable does not have. Bolt's metered pricing means that when a build loops - when the model rewrites working code to fix a bug and the rewrite introduces a new bug - the loop costs real money in a way that is hard to predict upfront. One developer documented spending over 500,000 tokens trying to fix a single authentication issue. Not building new features. Not improving anything. Fixing one thing that had been broken since the beginning. Token cost opacity is a consistent theme in founder feedback on Bolt: the credits consumed debugging a production problem often exceed the credits spent building the original feature. This is the pattern behind most [AI app builder hidden costs](/ai-app-builder-pricing-hidden-costs) - the bill is set by debugging loops, not by the build. The security profile mirrors Lovable's at the output level. A 2025 study found 45% of AI-generated code fails basic security tests. Bolt's output is included in that population. The same 88% RLS-disabled finding from the vibe-coded app audit covers apps built with Bolt alongside apps built with every other tool in the category. --- ## The Migration That Doesn't Solve the Problem Most founders who switch from Lovable to Bolt are not starting fresh. They export what Lovable built - usually React components and a Supabase schema - and take it into Bolt expecting Bolt to fix the things Lovable could not. What they find is that Bolt can see the code, can add to it, can change it. What it cannot do is retroactively make the architectural decisions that were not made at the start. The RLS policies that were never written are still not written. The webhook handling that was never built is still missing. The multi-tenant isolation that was never designed is still absent. Bolt can fix individual lines of code. It cannot fix a data model that was never designed for the thing you are actually building. This is the loop that founders describe when they have been through it. Lovable got to 70%. Bolt got to 75%. Back to Lovable for the UI. Back to Bolt for something Lovable could not handle. Neither tool has visibility into what the other did. The context that would have prevented the problem - the full picture of what the system is supposed to do, enforced consistently across every decision the model makes - was never established. It cannot be established in session 20 of a build that is already three months in. --- ## Why the Wall Is in the Same Place Altar.io published a direct comparison of Lovable, Bolt, v0, Replit, and Base44. Their finding: all five tools generate code that reaches 60-70% of a real product. The remaining 30-40% is where production systems break. We mapped where that wall sits across every major tool in [Lovable alternatives for business apps](/lovable-alternatives-business-apps). The reason the wall appears in the same place for both Lovable and Bolt is not a model problem. Both tools use capable models. The reason is a product decision. Both tools are optimized for time-to-first-output. You type, it builds, immediately. That speed requires starting before the tool knows what it is building. The architectural decisions that determine whether a business app works in production are not visible in the first output. They are made in the data model, before any code exists. Who can read which records. What happens when a payment fails. Whether the authentication is frontend-only routing or database-level enforcement. Whether the app has a single user namespace or tenant isolation baked into the schema. When these decisions are not made explicitly - when the tool starts from a description and makes common-case assumptions - the output looks right. It works in the demo. The authentication page loads. The dashboard shows data. The failure surfaces when a real user with real credentials does something the model did not model. Which is usually the second or third thing any real user does. A researcher scanning 1,645 apps from Lovable's own showcase found that 170 of them - 10.3% - had critical row-level security failures. These were publicly listed apps. They were working for their owners. The failures were invisible until someone looked. Switching from Lovable to Bolt does not change any of this. The tool changes. The approach both tools share does not. --- ## What Each One Is Actually Right For This is the honest version. Use Lovable when the complexity lives in the frontend. When you are building a SaaS with a clean, linear happy path. When the UI is the hard part and the backend is mostly Supabase defaults. When you think in screens, understand your product by looking at it, and want the fastest path to something that looks finished enough to show investors or test with early users. Lovable is the right tool for that specific shape of project and the strongest option in the category for it. Use Bolt when you want the fastest time to first output and you value seeing the code. When the project is a prototype, a demo, or an exploration rather than a production system. When you are code-literate enough to read what Bolt produces and identify what is missing before it causes a problem. When you understand that "fast first output" and "production-ready" are different destinations and you are explicitly aiming for the first one. Bolt is also the right choice if your stack is not React and Supabase - the flexibility is real and matters. Do not use either when the application has to be correct. Multiple user roles with different access levels, integrations that need to handle failure not just success, data that has to be right across multiple concurrent users, a business that will run on the system from the first week. Both tools will get you to 60-70% and stop. The 30% they miss is not the easy 30% - it is the access control, the integration failure handling, the data model correctness, the audit trail. The parts that are cheapest to build correctly at the start and most expensive to retrofit six months later. --- ## The Question Neither Tool Asks There is one question that separates tools built for prototypes from tools built for production systems. Does the tool ask what you are building before it starts building? Not in a vague sense - both Lovable and Bolt technically take a description. But does the tool surface the decisions that determine whether the output is correct for your specific situation? Does it ask who the users are and what each role can do? Does it ask what happens when an integration fails? Does it ask what data needs to be isolated, what happens at the edges, what a working version looks like in week four rather than week one? Lovable does not ask these questions. Bolt does not ask these questions. What both tools produce is the most common-looking version of whatever you described, built as fast as possible, starting immediately. For simple apps, that is exactly right. For business apps with real complexity, that approach produces the 60-70% wall that appears in every honest review of this category. The tools that work for business apps are the ones that treat the requirements conversation as the work, not as friction before the work starts. The architectural decisions get made in that conversation - before any code exists, when changing them costs nothing. After the build starts, changing them costs everything. If you are choosing between Lovable and Bolt, the choice matters less than whether either conversation happened. Pick the tool that fits your visual style and your stack preference. But understand that both tools are taking you to the same place - and plan accordingly for what comes after. --- # https://getcreatr.com/bubble-alternatives-2026 # Bubble Alternatives in 2026: Where Bubble Hits Its Ceiling and What to Use Instead **Quick answer:** The right Bubble alternative depends on why you are leaving. For a marketing site, use Webflow; for internal tools on existing data, Retool; for an AI-first prototype, Lovable or Bolt. For a production app with complex logic and multiple roles, custom code or a managed build service like Creatr's DeepBuild fits better than any single no-code tool. Bubble alternatives 2026 [Bubble](https://bubble.io) is [the most capable visual full-stack builder available without writing code](/bubble-review-2026). It has a genuine database layer, real workflow logic, a plugin ecosystem with thousands of integrations, and a track record of powering production products that have gone on to raise funding and serve real customers. The community is large, the documentation is thorough, and the learning curve - while real - produces actual capability on the other side. None of this is faint praise. The reason Bubble alternatives get searched so often is not because Bubble is bad. It is because Bubble has specific ceilings, and when you hit them, they are hard walls. --- ## What Bubble Actually Gets Right Before the alternatives, it is worth being precise about where Bubble earns its position. The core strength is the integrated stack. Bubble's data types, workflows, and visual editor all speak the same language. You define a data structure and it is immediately available in your workflows and visible in your editor without configuration. There is no gap between the database schema and the frontend - they are the same tool. For founders building data-driven products without a technical co-founder, that coherence is genuinely valuable. The plugin ecosystem extends Bubble into territory that most no-code tools cannot reach. Stripe, Twilio, Maps, authentication providers, real-time features - most of what a standard web app needs has a plugin that connects it without code. The Bubble community has been building these connectors for years, and the quality is variable but the coverage is wide. Bubble also has a real deployment story. Your app runs on Bubble's infrastructure, handles reasonable traffic, and is accessible at a custom domain. It is a finished product, not a prototype that needs another step before it can be shared. --- ## The Three Reasons People Leave ### Workload Unit Pricing Bubble's billing is structured around Workload Units - a usage-based metric that tracks server computation across workflows, database reads and writes, and API calls. The model replaces older capacity-based pricing, and the intent is sensible: you pay for what you use rather than reserving capacity you may not need. The problem shows up in practice during development. Debugging is workflow-intensive. Every test run, every failed condition, every iteration on a workflow consumes WUs against the same meter as production usage. Founders who are deep in a build phase - especially founders new to Bubble who iterate heavily to get logic working - find that their monthly bill reflects the debugging work, not just the user-facing product. There is no fixed ceiling on WU costs at standard plan levels. A month of heavy debugging can cost meaningfully more than a month of stable production traffic at the same plan. For teams building complex apps with involved logic, this unpredictability is a real operational problem - not a theoretical one. ### No Source Code Export Your Bubble app lives in Bubble. The data, the workflows, the visual components, the logic - none of it is portable to another environment in a form you can work with. Bubble can export your data as CSV. It cannot export your application as code. This is a deliberate architectural choice, not an oversight. Bubble's database and workflow system are proprietary abstractions. There is no underlying React codebase to hand to a developer, no SQL schema to migrate to another host. If you decide to move off Bubble - because the platform no longer fits your needs, because pricing has shifted, because you want a developer to extend the product - you are rebuilding from scratch. For products in early validation, this tradeoff is often acceptable. For a product that has found traction and is being treated as a long-term business asset, it is a significant constraint on what you can do with the thing you built. ### Performance Under Real Load Bubble runs on shared infrastructure. A straightforward app with simple data queries and moderate traffic performs adequately. As the app grows in complexity - recursive workflows, multi-condition searches across related data types, real-time features with multiple concurrent users - query times increase, and the performance degrades in ways that are difficult to optimize. The optimization tools available are limited. You can structure workflows more efficiently, reduce the number of database reads in a single operation, and add indexes on commonly searched fields. But you cannot rewrite the query execution layer, change the database engine, or scale the infrastructure independently. The ceiling on performance is imposed by the platform, and on the Starter and Growth plans, it applies to every app on shared resources. High-performance Bubble apps require dedicated infrastructure, which is available at enterprise price points. For many of the founders who hit this wall, the cost of the dedicated plan is the final push toward an alternative. --- ## The Alternatives, Mapped to What You Actually Need ### If You Need a Marketing Site: Webflow [Webflow](https://webflow.com) is not a Bubble alternative for building web apps - it is a Bubble alternative for the specific case where you need a marketing site, landing pages, or a content-driven presence and were considering Bubble because you needed something more flexible than a standard website builder. Webflow's visual editor operates closer to how CSS actually works than any other visual tool. The output is clean HTML and CSS - real, exportable, portable. The CMS is genuinely capable for blog content, case studies, and structured content. The hosting is fast. Webflow does not have a user authentication system, does not have a database layer for application data, and cannot build the kind of workflow logic that Bubble handles. The comparison only makes sense for the marketing-site use case. For that use case, it is the better tool - faster, more maintainable, and with better performance characteristics than a Bubble site used primarily as a marketing presence. ### If You Need Internal Tools and Dashboards: Retool [Retool](https://retool.com) is built for a specific problem: your company has a database or an API and needs a UI on top of it for internal use. Customer service interfaces, admin panels, data tables, operations dashboards - these are the Retool use cases. The difference from Bubble is the starting point. Retool connects to existing infrastructure. You point it at a PostgreSQL database, a REST API, or a Firebase project, and it builds query-driven interfaces on top. There is no Retool database to maintain. The data lives wherever it already lives. The tradeoff is that Retool produces Retool-looking interfaces. There is a ceiling on visual customization - everything is components in a grid, and there is no confusing it with a consumer-facing product. For internal tools where usability matters more than aesthetics, that ceiling is perfectly acceptable. For anything customer-facing, it is not. ### If You Need an AI-First Prototype: Lovable or Bolt [Lovable](https://lovable.dev) and [Bolt](https://bolt.new) are the most direct competitors to Bubble in the build-from-a-description category, but their model is different. Where Bubble is a visual builder you operate, Lovable and Bolt generate code from prompts. The output is an actual React application with a database - not a Bubble workflow but deployable source code. Lovable's particular strength is the visual output quality. It produces polished interfaces faster than any other tool in the category and has a solid Supabase integration that handles authentication and database setup without manual configuration. For getting to a working, shareable demo, it is the fastest path available. Bolt offers more transparency into the generated code and more stack flexibility. Founders who are code-literate enough to read what is being produced, and who want to hand something clean to a developer for extension, often prefer it. The relevant limitation of both - addressed more directly in the next section - is that the speed-to-output advantage comes with a production-readiness gap that is consistent across the category. ### If You Need a Production App With Complex Logic: Custom Code or a Managed Build Service For a product that has found traction, has multiple user roles with distinct permissions, and needs to behave correctly at scale - the no-code tools in this category are the wrong answer, and picking the best one does not close the gap. Custom development with a developer or engineering team is the most direct path, and for products past the validation stage, the cost of building correctly is lower than the cost of rebuilding from a no-code foundation that has reached its ceiling. A managed build service - where a team handles architecture, security configuration, and delivery rather than handing you a tool to operate - occupies the middle ground. You describe the product; the build is owned by the service. This is the model Creatr's DeepBuild runs on: requirements are treated as real work before any code is written, and the architectural decisions that AI builders defer are made explicitly before the build starts. We lay out the direct trade-offs - Workload Unit pricing, code ownership, and the performance ceiling - in [Creatr vs Bubble](/vs/bubble). --- ## The Wall That Applies to All of Them Every prompt-driven AI builder in 2026 - Lovable, Bolt, and the others - shares a consistent failure mode. They hit the same ceiling at complex logic, and the ceiling shows up in three predictable places. Multi-role access control. The first version of a user permissions system is easy to prompt. The version that correctly handles what a manager can see versus what their reports can see, applied to every relevant record in the database, is not a prompt problem. It requires explicit design before the build starts. AI builders do not ask for it. Complex workflow logic. A linear happy path through a workflow is easy to generate. The error states, the retry logic, the notification behavior when a payment fails, the data correction when an API call returns unexpected results - these require the builder to know what correct behavior looks like in each case. A prompt does not contain that information, and the generated output does not ask for it. Production-grade backend behavior. Rate limiting, proper error handling, secure API key management, database query optimization, logging that supports debugging in production - these are not features that prompt-driven builders include by default, and they are not visible in the demo. They surface after launch. This is not a solvable problem by picking the right tool. It is a category limitation. The tools that perform well past this wall are the ones that treat requirements as real work before writing code - not as the starting prompt for code generation. --- ## How to Decide: Questions to Ask Before Picking an Alternative Before moving to any of the tools in this post, the relevant questions are: **What is the actual problem with Bubble?** WU pricing unpredictability, vendor lock-in, and performance are different problems with different solutions. A tool that solves the pricing concern may not solve the portability concern. **What stage is the product at?** A product in validation has different requirements than a product with paying customers and team members who depend on it daily. The appropriate tool changes at different stages. **Who owns the ongoing development?** Tools that require a technical operator to maintain them - Retool, custom code, anything with an exported codebase - require someone with the skills to operate them. If that person does not exist in your team, the tool choice needs to account for that. **What does the product need to do in six months?** The features on the roadmap that the current tool cannot support are the ones to evaluate against alternatives, not the features that already work. Bubble is a real product that has shipped real businesses. The founders who leave it do so for specific reasons. The right alternative is the one that addresses the specific reason - not the one that scores best in a feature comparison that does not map to the problem you actually have. --- # https://getcreatr.com/bubble-review-2026 # Bubble Review 2026: Is It Still Worth It? Bubble review 2026 - is bubble.io still worth it **The short version:** Bubble is still worth it, and it is still the most capable visual full-stack builder available - a real database, real workflows, and a plugin ecosystem nothing in the AI-builder wave has matched. It hits three ceilings: consumption-based Workload Unit billing that gets harder to predict as usage grows, no source code export, and performance that depends entirely on how carefully you build. For internal tools and simple SaaS, none of those ever bite. For a funded startup building a durable product, the code-ownership ceiling is the one to think about before you start. Most Bubble reviews are written by people who either sell Bubble services or sell something that competes with Bubble. This one has a stake too - we build production software - so the fairest thing to do is be specific about what Bubble does better than the alternatives, and equally specific about where it stops. Every claim below links to Bubble's own documentation. --- ## What Bubble actually is [Bubble](https://bubble.io) is a visual programming platform for full-stack web and mobile apps. You get a drag-and-drop editor, a real database with data types and fields, a visual workflow engine for backend logic, scheduled and recurring workflows, an API connector, and a plugin marketplace. You publish to Bubble's hosting and it runs. The important context: Bubble predates the entire AI-builder wave by more than a decade. That maturity shows in ways that are hard to see in a demo and impossible to fake. The workflow engine handles conditionals, loops, custom events, and recursive scheduled workflows. The database supports privacy rules enforced server-side, not just hidden UI. There is real version control - branches, deployment to a separate live environment, rollbacks. There is an [agency plan](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans) built specifically for developers building apps for clients, which tells you how established the professional ecosystem around it is. That last point deserves weight. If you build in Bubble and later need help, you can hire someone. There is a decade-deep pool of experienced Bubble developers, a large [plugin marketplace](https://bubble.io/plugins), and a forum where most problems you will hit have already been solved by someone. Compare that to a tool that shipped 18 months ago. Ecosystem maturity is a real feature and Bubble has more of it than anything else in no-code. --- ## What Bubble genuinely does well **Complex logic without code.** This is the headline and it is earned. Multi-step conditional workflows, recursive background jobs, role-based data privacy, scheduled processes, API integrations with authentication - you can build all of it visually. Most tools that claim "no-code" mean "no-code until you need anything real." Bubble means it. **A real database, not a spreadsheet.** Data types, relational fields, server-side privacy rules, and a full Data API. Tools built on top of Airtable or Google Sheets hit a wall at a few thousand rows. Bubble's data layer is a real application database. **Depth over speed.** AI builders generate an impressive first draft in 90 seconds and then get progressively less useful as the app grows. Bubble is slower at the start and does not degrade the same way, because you are editing an explicit model of your app rather than prompting a model to guess at one. At month six, that trade looks very different than it does on day one. **You can hire for it.** Covered above, but it is the most underrated advantage. An abandoned Bubble app is a rebuildable asset. An abandoned app in a tool with 40 practitioners worldwide is not. --- ## Ceiling one: Workload Unit pricing Bubble bills compute through Workload Units, which the docs define as measuring ["the server resources needed to host, run, and scale apps built on Bubble."](https://manual.bubble.io/help-guides/workload) Every plan includes a monthly WU allowance. Page loads, workflows, searches, and bulk operations all draw it down. This model is a genuine improvement on what came before. The legacy "capacity" metric slowed your app down when you exceeded it. Workload does not throttle - instead you can [buy discounted workload tiers, or let Bubble automatically add units](https://manual.bubble.io/help-guides/workload) to handle traffic increases. Your app stays fast. That is the right design choice. The cost of that design choice is that the ceiling moved from performance to your invoice. Overages are billed as [a unit price applied to each additional 1,000 workload units](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans). An inefficient workflow that would previously have made your app sluggish now quietly bills you instead. Bubble publishes [an optimization checklist](https://manual.bubble.io/help-guides/workload/optimizing-workload/optimization-checklist) and [a workload efficiency guide](https://bubble.io/blog/workload-efficiency-101/), which is useful and also tells you something: WU efficiency is a skill you are expected to learn, not a default you get. Bubble's documented plan tiers are Starter, Growth, Team, and Enterprise, available as Web only, Mobile only, or Web + Mobile, with [monthly pricing running from $29 to $649](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans) depending on tier and plan type. The docs note that each plan includes a number of monthly workload units but do not publish the per-plan quantities, so check the [live pricing page](https://bubble.io/pricing) for current allowances before you budget. The practical advice: model your cost at 10x your launch usage, not at launch usage. --- ## Ceiling two: no code export This is the structural one, and Bubble is admirably direct about it. From the official [application and data ownership](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) page: > "Bubble apps can only be run on the Bubble platform; there's no way of exporting your application as code." And on ownership: > "Bubble retains ownership of the underlying code that powers your app." You own your design and your data. Bubble supports [exporting user-created data as CSV files](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) and offers a Data API for scripted access, and the company says it will "do our best to help you leave if you want to." That is a more honest posture than most platforms take. Bubble even commits that if it ever discontinues operations, its source code will be released under an open-source license. But the practical consequence is unchanged. There is no repository to hand a developer. There is no SQL schema to migrate. Your workflows are not portable artifacts. If you outgrow Bubble, or get acquired by a company with an engineering standard, or hire a CTO who needs to own the stack, the path forward is a rebuild - paid for twice, with your original build as the spec. We wrote about why this matters across the whole category in [do you own the code from AI app builders](/do-you-own-the-code-from-ai-app-builders). Whether that is a dealbreaker depends entirely on the answer to one question: is this app a tool your business uses, or is this app the business? --- ## Ceiling three: performance and scaling Bubble's docs state it plainly: ["Performance and scaling of a Bubble app are heavily impacted by how the app is built."](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling) That sentence is doing a lot of work. The specifics from Bubble's own guidance are worth knowing before you architect anything: less data fetched means faster pages, "having many small, simple pages will be faster than having fewer, complex pages," sorting and filtering should happen at the database level rather than through advanced filters applied after retrieval, and "chained queries run in series, not in parallel." Heavy calculations on page load and oversized single fields are named as problem patterns. None of that is unique to Bubble - the same principles govern any application. The difference is that Bubble abstracts the database layer away from you, so the feedback loop is slower. A developer writing SQL sees an N+1 query. A Bubble builder sees a repeating group that feels a bit slow, and does not necessarily know that a nested search inside it is the cause. Well-built Bubble apps perform fine. Casually-built Bubble apps get slow at scale, and diagnosing why requires expertise that beginners do not have yet. Our writeup on [no-code app scaling problems](/no-code-app-scaling-problems) covers the general shape of this. --- ## The honest counterpoint Everything above is real, and for a large number of apps none of it ever matters. If you are building an internal operations tool for 30 employees, you will not hit meaningful WU overages, you will never need to export code because you are never leaving, and your data volumes will not stress the platform. Bubble is not a compromise for that use case. It is the right answer, probably permanently, and rebuilding it as custom software would be a waste of money. The same holds for a lot of small SaaS. A niche B2B product with a few hundred paying customers and moderate complexity can live on Bubble indefinitely and be more profitable for it. The ceilings are real but they are ceilings, not walls you hit on day one, and plenty of businesses run their entire lives below them. --- ## Is Bubble worth it? Verdict by user type | You are... | Is Bubble worth it? | Why | | --- | --- | --- | | **Non-technical founder validating an idea** | Yes, strongly | You can build real logic yourself without hiring. Cheapest path to a working product that actual users can pay for. Ceilings are years away. | | **Building an internal business tool** | Yes, and probably permanently | Predictable usage, no exit requirement, no acquisition risk. Code export is irrelevant when nobody is ever leaving. | | **Funded startup building the core product** | With a clear plan | Excellent for getting to market and proving demand. Decide up front whether Bubble is the permanent home or the validation step - and budget for the rebuild if it is the latter. | | **Agency building client apps** | Yes, with disclosure | The agency plan exists for exactly this. Tell clients plainly that the deliverable lives on Bubble and cannot be handed over as code, before the contract is signed. | --- ## How Bubble compares to the practical alternatives | | Bubble | AI builders (Lovable, Bolt) | Custom development | Creatr | | --- | --- | --- | --- | --- | | **Build speed** | Weeks | Days | Months | Weeks | | **Complex logic** | Strong | Degrades as app grows | Unlimited | Unlimited | | **Code ownership** | No export | Varies by tool | Full | Full | | **Ecosystem / hireable talent** | Deep, decade-plus | Thin, new | Deepest | Managed for you | | **Cost model** | Subscription + workload units | Credits or tokens | Salaries or agency fees | Fixed project | | **Best for** | Internal tools, small SaaS, validation | Prototypes and demos | Funded, engineering-led products | Production apps you need to own | For a fuller breakdown of where each option fits, see [Bubble alternatives 2026](/bubble-alternatives-2026), our head-to-head [Creatr vs Bubble](/vs/bubble) comparison, or - if your project is closer to a content-driven site than an application - [Bubble vs Webflow](/bubble-vs-webflow-2026). --- ## Where we fit, honestly We build [Creatr](https://getcreatr.com), and our product DeepBuild delivers production software as code you own - a real repository, a real database schema, deployed on infrastructure in your name. That is the direct answer to ceiling two. If code ownership is the thing blocking you, that is the gap we exist to close. It is not the answer to every situation, and we would rather say so than pretend otherwise. If you are building an internal tool, if your usage is predictable, if you have no exit or acquisition scenario in view, or if you genuinely enjoy building in Bubble and are productive there - stay. The ceilings we described will not touch you, and moving to custom code would cost more and buy you nothing you need. Bubble is a mature, capable platform, and "is it worth it" is a question about your product, not about the tool. The decision is only urgent in one case: your app is the business, you expect to raise or sell, and someone will eventually ask to see the codebase. That question has a much better answer if you think about it now instead of at diligence. --- # https://getcreatr.com/bubble-vs-webflow-2026 # Bubble vs Webflow in 2026: Site vs App, and the Wall Both Hit Bubble vs Webflow comparison 2026 **Quick answer:** Pick Webflow if you are building a marketing site or content-driven pages for visitors, and Bubble if you are building an app with logins, a database, and logic. Bubble will get you to roughly 70% of a real product, then stall at the same wall every builder hits: multi-role auth, integration failure handling, and data correctness under load. People compare Bubble and Webflow as if they are two answers to one question. They are not. They answer two different questions, and most of the confusion comes from asking the wrong one. Webflow builds sites that people look at. Bubble builds apps that people log into and do work in. If you need the first, the second is overkill and frustrating. If you need the second, the first will not get you there no matter how many plugins and embeds you bolt on. So the real decision happens in two steps. First: site or app. That one is easy once you say it plainly. Second, and this is the part nobody tells you up front: even when you correctly pick Bubble for an app, you will build fast to about 70% and then hit a wall made of the four things that separate a demo from a product. This post is about both steps. | Dimension | Bubble | Webflow | | --- | --- | --- | | Built for | Web apps with logged-in users | Marketing sites and content | | App logic / backend | Full visual workflows and database | None native; needs embeds or external tools | | User accounts & roles | Real auth, basic roles via privacy rules | Memberships for gated content only | | Data correctness | Your responsibility to enforce | Not an app concern | | SEO & content | Workable but secondary | Strong; CMS-first | | Where it stalls | Multi-role auth, integrations, load | It was never going to be your app | | Pricing shape | Workload Units, scales with usage | Flat tiers per site | --- ## Step One: Are You Building a Site or an App? Here is the test. Does a stranger arrive, read or buy something, and leave? That is a site. Does a known user sign in, see data that belongs to them, change it, and come back tomorrow expecting it to still be there? That is an app. A dentist's homepage with services, a booking embed, and a blog is a site. The booking system behind that embed - where staff log in, see today's schedule, reschedule a patient, and the change has to be correct and visible to three roles at once - is an app. The marketing page for a SaaS product is a site. The product itself is an app. Webflow is built for the first. Its core is a visual designer plus a [CMS where you model content into Collections](https://help.webflow.com/hc/en-us/articles/33961307099027-Intro-to-the-Webflow-CMS) and bind it to dynamic pages. That is genuinely excellent for blogs, landing pages, case study libraries, job listings as content, and anything where the page is generated from structured content and shown to a visitor. The output is clean and fast, and SEO is a first-class concern rather than an afterthought. What Webflow does not have is application logic. There is no place to write "when this user submits this form, check their plan, charge their card, create three related records, and email the other party." You could once fake fragments of it with Webflow's native memberships, but Webflow sunset that feature - [now called User Accounts](https://webflow.com/feature/user-accounts) - in January 2026, pushing gated content to third-party tools like Memberstack and Outseta. The moment you need real multi-user state, you are gluing Webflow to external tools and maintaining the seams. That is a sign you picked the wrong base. So if the honest answer is "app," do not start in Webflow. You will spend three weeks discovering it will not build your app, then start over. ## Step Two: Bubble Is a Real App Builder [Bubble](https://bubble.io) is the other thing entirely. It ships a real database, a visual [workflow engine where events trigger sequences of actions](https://manual.bubble.io/core-resources/workflows), a [built-in user authentication system with password hashing and sessions](https://manual.bubble.io/help-guides/data/user-accounts), and a plugin ecosystem for connecting to outside services. You can build a marketplace, a CRM, a patient portal, an internal ops tool - actual software with logged-in users doing real work. And it is fast at the start. This is not a knock. A solo founder can model a few data types, wire up signup and login, build a dashboard, and have something a customer can actually use inside a couple of weeks. That speed is real and it is why Bubble has powered products that raised money and served paying users. The pattern is consistent. The first 70% comes quick. Then the curve flattens hard, and the remaining 30% takes longer than the first 70% did. The remaining work is not more screens. It is the load-bearing structure underneath, and Bubble does not build it for you. It gives you the tools and the responsibility. ## The Wall, Part One: Multi-Role Auth Is Not "Add a Field" Most app builders start the same way: add a "user type" field with values like "admin" and "member," and check it in a few places. This holds until it does not. Real access control is not one field. It is the answer to "who can see and do what, on which specific records, under which conditions." A clinic app has a front-desk role that can see appointments but not clinical notes, a clinician who can see their own patients, and an admin who can see everything. A client portal must guarantee that Client A literally cannot load Client B's data, even by editing a URL or hitting the API directly. In Bubble, the mechanism for this is [privacy rules, which instruct the server to only send or write data when conditions are met](https://manual.bubble.io/help-guides/data/the-database/protecting-data-with-privacy-rules). They work, but they are entirely your job to get right, rule by rule, on every data type, and a single missed condition is a data leak that looks like nothing in the editor. This is the same problem every real backend faces. In a coded stack you would lean on something like [Postgres Row Level Security policies](https://supabase.com/docs/guides/database/postgres/row-level-security) to enforce access at the database itself. The principle is identical: access has to be enforced where the data lives, not just hidden in the UI. The 60-70% demo hides data in the UI. The product enforces it at the source. That gap is where breaches live. ## The Wall, Part Two: Integrations Are Easy; Failure Paths Are Hard Connecting Stripe, sending email through a provider, calling some external API - the happy path takes an afternoon. The plugin connects, you fire a test, money moves, email arrives. Demo done. The product is everything that happens when that call does not return cleanly. The card charge succeeds but the webhook that confirms it never arrives. The email provider rate-limits you at 9am. The third-party API times out halfway through a multi-step [workflow](https://manual.bubble.io/core-resources/workflows), so you have created the order record but not the payment record, and now your database disagrees with reality. Two requests hit the same endpoint at once and you double-charge. These are not edge cases. At any real volume they are Tuesday. Handling them means idempotency keys, retry logic with backoff, webhook signature verification, reconciliation jobs that catch the records that drifted, and dead-letter handling for the calls that never succeed. None of this shows up in a demo because demos run the happy path once. All of it is the difference between an app that loses money quietly and one that does not. Builders make the connection trivial and leave the failure handling entirely to you, which is exactly the part that is hard. ## The Wall, Part Three: Data Correctness Under Load A demo has one user and ten records. The query is instant and always right because there is no contention and almost no data. Production has a hundred concurrent users and a table with two hundred thousand rows. Now the questions change. Did two simultaneous edits to the same record race, with the last write silently clobbering the first? Is the dashboard total correct, or is it summing a list that paginated and quietly stopped at the first chunk? Did the search that felt instant on ten records now scan the whole table on every keystroke? Bubble's pricing makes this visceral because compute is metered. The platform charges in [Workload Units, a measure of the work it does to power your app](https://manual.bubble.io/help-guides/workload/understanding-workload), and an inefficient query that nobody noticed at ten records becomes a line item at scale. So data correctness and cost stop being separate problems - the sloppy query is both wrong and expensive. Getting this right means proper indexing, avoiding full-table scans, handling concurrency, and structuring data so the common reads are cheap. That is database engineering, and the visual builder does not do it for you. If you want a deeper tour of this exact failure mode, we wrote one up in [no-code app scaling problems](/no-code-app-scaling-problems). ## So Which One Do You Pick? Run the two steps in order. If a visitor arrives, reads or buys, and leaves, and there is no logged-in workspace where known users manage their own data over time, pick Webflow. Build the site, lean on the CMS, ship it, and do not feel like you are settling. For a content-driven marketing presence, Webflow is the better tool and Bubble would just be friction. If users log in and do work, pick Bubble over Webflow without hesitation, because Webflow cannot build your app at all and Bubble can build most of it. Just go in with clear eyes: the first 70% will feel like you are flying, and then you will reach the wall - multi-role access enforced at the data layer, integrations that survive their own failure paths, and data that stays correct and affordable under load. That last 30% is not optional polish. It is the part that determines whether you have a product or a convincing demo. If you have already hit that wall in Bubble, the choice is to learn backend engineering well enough to do it yourself, hire someone who already has, or hand the build to a team that ships production apps and owns the hard 30%. That last option is what [Creatr's DeepBuild](https://getcreatr.com) exists for. The point of this piece is not the pitch, though. It is the map: know whether you need a site or an app, and if it is an app, know exactly where the road gets steep before you are standing on it. For a fuller breakdown of where each tool tops out and what to reach for next, see our guides on [Bubble alternatives in 2026](/bubble-alternatives-2026) and [Webflow alternatives in 2026](/webflow-alternatives-2026). The comparison was never Bubble versus Webflow. It is site versus app, and then, if it is an app, you versus the wall. Pick the right tool for step one, and respect step two before it surprises you in production. --- # https://getcreatr.com/build-booking-scheduling-app # How to Build a Booking and Scheduling App Without Code in 2026 **The short version:** If your needs are standard, an off-the-shelf tool like Calendly or Acuity covers single-resource booking cheaply. For custom logic, an AI builder like Lovable can generate the booking UI and availability display, but the hard part is not the calendar - it is reminder scheduling (needs a background job), multi-timezone correctness, concurrency locks that prevent double-booking, and cancellation policy charges. Spec that logic explicitly, or budget a managed build. How to build a booking scheduling app without code in 2026 A booking app is the most-requested specific app type from non-technical founders after CRMs. The category spans enough verticals - salon appointments, consultant calls, medical visits, fitness classes, home services, event venues, equipment rentals - that almost every service business eventually asks the same question: why am I still running bookings through a group chat and a shared calendar? The answer is usually that the generic scheduling tools ([Calendly](https://calendly.com), [Acuity](https://acuityscheduling.com), [Booksy](https://booksy.com)) do 80% of what the business needs and exactly miss the 20% that is specific to how that business operates. The salon that also needs to match specific staff skills to service types. The consultant who needs intake forms that route differently based on answers. The medical clinic that needs booking linked to patient records and insurance verification. These are not edge cases - they are the core operation of real businesses, and off-the-shelf tools are not designed around them. This post covers what a booking app actually needs, what the right approach is for building one without coding, and where the common build mistakes happen. --- ## What a Booking App Actually Is The word "booking" suggests simplicity - someone picks a time, confirms it, shows up. The underlying system is more complex than this in almost every real-world implementation. A production booking app manages five distinct concerns: **Availability.** When can this service, person, or resource be booked? Availability is not just a calendar of open slots. It includes operating hours, buffer times between appointments, staff or resource assignments, and blocked periods for maintenance, holidays, or other constraints. A booking system that does not model availability correctly either double-books or leaves slots incorrectly marked as unavailable - both of which produce customer experience problems. **Booking state.** A booking is not binary (exists or does not exist). It has states: pending confirmation, confirmed, in-progress, completed, cancelled, no-show. Each state transition may trigger actions: a confirmation email, a reminder notification, a billing event, a staff notification. The state machine for booking transitions is the core logic of the system and the part most likely to be incomplete in AI-generated code. **Payment.** Many booking types require payment at booking time, at service time, or both. The payment integration needs to handle deposits, full prepayment, post-service billing, refunds for cancellations (with correct policy enforcement depending on when the cancellation happened), and no-show charges. Each of these is a distinct payment flow that behaves differently from the others. **Communication.** Booking confirmation, reminders, and post-service follow-up all require outbound communication. Reminders alone - sending a message 24 hours before and one hour before an appointment - require a background job system that runs on a schedule, not just in response to user actions. Most AI builders generate the confirmation email and miss the reminder system entirely, because reminders are not triggered by a user action. **Reporting.** The business operator needs to see bookings, capacity utilization, revenue, and cancellation rates. This sounds simple and requires a data model designed for aggregation - the database structure that makes it fast to answer "how many bookings did we have last month, broken down by service type" is different from the structure that makes it fast to answer "is this slot available." --- ## The Decisions That Determine How Complex Your Build Is Before choosing a tool or approach, answer these questions. The answers determine how complex the build is and whether an AI builder can handle it or whether you need more architectural control. **Single resource or multiple resources?** A solo consultant booking calls has one resource: their time. A salon with eight staff members has eight resources, each with different skills, different working hours, and different services they can perform. A fitness studio has multiple room-and-instructor combinations that need to be booked as a unit. Single-resource booking is achievable with AI builders. Multi-resource booking with skill matching and availability dependency is architecture territory - it requires explicit data model design before any tool starts building. **Simple or conditional availability?** Simple availability is "this slot is open or it is not." Conditional availability adds constraints: this slot is open only if the previous booking was for service type X (because service Y requires a setup time that service X does not). Or: this slot is only visible to customers with booking tier B or higher. Or: this slot requires manual confirmation rather than automatic booking because the service has variable duration. These conditions are business rules. AI builders will implement them if you describe them completely. The challenge is that founders often do not know all their business rules until the system is being used by real customers - the edge cases surface in production. This is not a reason to avoid building, but it is a reason to plan for the iteration that happens after launch. **Real-time availability or periodic sync?** If the booking system is the primary calendar for your business, real-time availability is straightforward - the database is the source of truth. If the business also uses [Google Calendar](https://calendar.google.com), Outlook, or another external calendar, availability needs to stay in sync in both directions. A booking in your system should block the slot in Google Calendar. A block added manually in Google Calendar should close the slot in your system. Calendar sync is technically achievable - Google Calendar and Outlook both have APIs that AI builders can connect to. The reliability of that sync under real usage (multiple staff members, manual calendar edits, timezone handling) is the part that requires testing in production. **What does a cancellation cost?** Cancellation policy enforcement is one of the most commonly broken features in AI-generated booking systems. A cancellation policy that charges 50% if cancelled less than 24 hours before the appointment requires: knowing when the cancellation happened, knowing when the appointment is scheduled, calculating the time difference correctly across timezones, and triggering the right charge against the right payment method. Every step of this can be wrong in subtly different ways. The charge amount can be calculated on the wrong base. The timezone handling can produce off-by-one errors that charge customers incorrectly. The trigger can fire at the wrong time if the background job system is unreliable. Define this logic explicitly before building. --- ## What AI Builders Handle Well and Where They Break **They handle well:** - Single-resource booking with manual confirmation - Availability display from a database-backed calendar - Booking confirmation emails (not reminder scheduling) - Basic form intake with static routing - Customer-facing booking UI with a clean visual design **Where they consistently break:** *Reminder scheduling.* Most AI builders generate sending a confirmation email on booking and nothing else. Automated reminders require a cron job or similar scheduled task that runs independently of user actions. This is a backend infrastructure concern that prompt-driven AI builders frequently omit because it is invisible in the demo - you cannot see a reminder not being sent until 24 hours before an appointment that nobody reminded you about. *Multi-timezone handling.* A booking at 3pm made by a customer in London for a service provider in New York involves three timezones: the customer's display timezone, the provider's local timezone, and UTC for database storage. Getting all three right consistently - including in confirmation emails, calendar entries, and the booking record - requires explicit timezone logic that AI tools frequently handle inconsistently. *Overlapping booking prevention under concurrency.* Two customers trying to book the same slot at the same time requires a transaction lock on the availability check - the database operation that checks availability and creates the booking needs to be atomic, so that two simultaneous requests do not both see the slot as available and both successfully book it. This is a standard database concurrency pattern that AI builders sometimes get right and sometimes miss, with double-booking as the consequence. *Cancellation policy calculation.* As described above, the policy calculation touches billing, time calculation, and timezone handling simultaneously. The number of ways it can be wrong is high enough that explicit testing against every cancellation scenario is required before going live. --- ## The Tools and Their Fit **[Calendly](https://calendly.com/pricing) and [Acuity](https://acuityscheduling.com/signup.php?entry_point=acuity&btn=nav) (Off-the-shelf):** If your booking requirements are standard - one or a few resource types, standard availability, email confirmation, basic intake - these tools cover the use case without building anything. The cost is $8-16 per user per month. The cost of building something equivalent is many multiples of that. Use an off-the-shelf tool until you find the specific limitation that it cannot handle. **[Lovable](https://lovable.dev) (AI builder):** Single-resource booking with straightforward availability is achievable with Lovable. The limitation appears with reminder systems, multi-resource availability, and cancellation policy complexity. A Lovable-generated booking system covers the demo case and requires focused developer work on the backend infrastructure (scheduled tasks, timezone handling, concurrency locks) before it handles real production volume. **Custom build from specification:** The right choice when the booking logic is a competitive differentiator - when the specific way your business handles availability, matching, or cancellation policy is the thing that makes your service work better than alternatives. This is the case for specialty health clinics, multi-service venues, and businesses where the operational complexity is itself the product. --- ## A Working Specification for a Service Booking App If you are building a single-service booking system (one type of service, one or more staff members who can perform it), this specification covers the minimum requirements for a production-ready v1. **Data model:** - Service: name, duration, price, buffer time after - Staff: name, working hours by day, services they can perform - Time slots: generated from staff availability and existing bookings - Booking: customer info, staff, service, time, status (pending/confirmed/completed/cancelled/no-show), payment status - Customer: contact info, booking history **Booking flow:** 1. Customer selects service 2. System displays available slots (filtered by: service duration fits in slot, staff who can perform service is available, no existing booking for that staff member at that time) 3. Customer selects slot and submits contact info 4. System creates booking in pending status, sends confirmation email with option to confirm or cancel 5. Booking moves to confirmed on customer action or after X hours automatically 6. Reminder sent 24 hours and 1 hour before (background job required) 7. After appointment time passes, booking moves to completed or no-show **Payment triggers:** - Deposit at booking creation (if policy requires) - Balance at appointment time or completion - Cancellation charge calculation: (appointment time - cancellation time) checked against policy rules **What gets built after v1 validates:** Multi-staff scheduling, package bookings, service bundles, loyalty tracking, online intake forms, review requests. What gets built first is the minimum that allows real customers to book real appointments and the business to operate without a spreadsheet. That minimum is achievable in a few days with the right specification. The specification is the investment. The build is the execution. --- # https://getcreatr.com/build-client-portal-without-code # How to Build a Client Portal Without Code (And Where It Quietly Breaks) Build a client portal without code with separate logins and access levels **The short version:** a branded login and a document list is the easy 60-70% any no-code tool ships in an afternoon - the dangerous 30-40% is row-level isolation so Client A never sees Client B, granular roles, SSO/SCIM, secure document handling, and audit logging. | Requirement | What the easy/demo version does | What production actually needs | | --- | --- | --- | | Data isolation | One list block queries the whole table | Row-level rules at the API so a query only returns the caller's rows | | Field access | Whole record shown to the client | Field-level permissions hiding internal notes within a shared record | | Roles | Admin and user, two tiers | A matrix of roles across records and fields | | Authentication | Email and password login | SSO plus SCIM provisioning to deactivate departed users | | Documents | Static list with shared links | Signed, expiring URLs and defensible e-sign | | Audit trail | No record of access | Append-only server-side log of who accessed or changed what | | Verification | "Looks right" in the editor | Network-tab test confirms no other client's rows in the payload | A client portal is one of the most requested no-code builds, and the request always sounds the same: separate logins for each client, different access levels, a place to share documents and invoices so people stop emailing PDFs around. You can get the first version live in an afternoon. A branded login screen, a list of documents, a profile page. Softr ships a portal template, Noloco ships one, Bubble has a dozen. None of that is the hard part. The hard part is the sentence buried inside "different access levels": Client A must never, under any circumstances, see Client B's data. That single requirement is where most no-code portals quietly fail, and the failure is invisible until a client emails you asking why they can see someone else's invoice. --- ## The 60-70%: Login, A Document List, A Branded Shell Here is what comes easy, and it is genuinely useful work. You connect a data source - Airtable, a Postgres table, Google Sheets - with a `Clients` table and a `Documents` table. You add a sign-up or invite flow so each client gets their own login. You drop in a list block that shows documents, an upload block, maybe a status field so clients can see where a project stands. You style it with your logo and brand colors so it does not look like a spreadsheet. This is a real portal. For a freelancer with five clients who already trust you, it might be all you need. The tools are good at this layer, and you should not over-engineer past it if your stakes are low. The trouble starts the moment you have two clients and one shared list block. We covered the same pattern from the team-facing side in [building an internal tool without code](/build-internal-tool-without-code) - the easy 60-70% is always the screens, and the access model is the part that does not show up in a demo. --- ## The Nightmare: A List Block That Shows Everyone Everything Picture the leak. You build one "Invoices" page. It is a list connected to your `Invoices` table. In the editor it looks perfect because you, the builder, can see all the rows. You ship it. Client A logs in and sees their invoices - and Client B's, and Client C's, sitting right there in the same list. This happens because a list block, by default, queries the whole table. Visibility is a property of the data layer, not of the screen. If you do not scope the query to "rows where this row belongs to the logged-in user," the screen shows everything the underlying source returns. The dangerous version of this is the one that looks fixed but is not. Some builders let you hide rows with a front-end filter - the block only displays records matching the current user. The records still travel to the browser; they are just hidden by CSS or client-side logic. Anyone who opens the network tab, or hits the underlying API, sees the full table. Noloco is explicit about this distinction in its own docs: front-end filters are not security, and [record-level permissions enforce access at the API level instead](https://guides.noloco.io/users-and-permissions/user-roles-and-permissions/record-level-permissions). That is the line that matters. --- ## Row-Level Scoping Is The Whole Game The correct fix is to enforce, at the data layer, that a query can only ever return rows the requester owns. In Softr this is done with global data restrictions: you define record-level rules once - "users can only view records where the `Client` field equals their account" - and they apply across every block in the app rather than per screen. Softr's [user groups and permissions guide](https://docs.softr.io/core-concepts-overview/user-groups--permissions) walks through how view, create, edit, and delete restrictions stack, and notes that the stricter create/edit/delete restrictions sit behind the business plan. If you have your own database, the gold standard is Postgres Row Level Security. RLS attaches a policy to the table itself so that every query - no matter where it comes from - behaves as if it had a `WHERE` clause restricting it to the caller's rows. Supabase enables it by default on Table Editor tables and documents the policy patterns in its [Row Level Security guide](https://supabase.com/docs/guides/database/postgres/row-level-security). The important property: the restriction lives below the API, so a leaky front end or a hand-crafted request cannot route around it. The test is simple and you should run it on every portal you build: log in as Client B, open the browser network tab, and inspect the actual API responses - not the rendered page. If Client A's rows show up in the raw payload, you have a leak, even if the screen looks clean. This is the same class of problem we cover in [no-code security risks](/vibe-coding-security-risks): the demo looks secure because the builder sees everything by design. --- ## Roles Are Not Just Admin And User Real portals are not two-tier. A service firm portal usually needs: the client contact who sees their own projects, the client's finance person who sees invoices but not project files, your internal account manager who sees several clients, and your admin who sees everything. That is four distinct permission shapes, and they cut across two axes at once - which records, and which fields within a record. The field axis is the one people forget. A client should see a project's status and deliverables but not your internal margin notes sitting in the same record. That needs field-level permissions, not just row-level ones. Noloco separates these explicitly with [field-level permissions](https://guides.noloco.io/users-and-permissions/user-roles-and-permissions/field-level-permissions) for create/read/update per field, and Postgres offers the equivalent with [column-level security](https://supabase.com/docs/guides/database/postgres/column-level-security). Design this as a matrix before you build screens. Roles down the side, tables and sensitive fields across the top, and a clear allow/deny in every cell. If you add permissions screen by screen instead, you will end up with a portal where the rules are scattered across forty blocks and nobody can answer "who can see invoices" without clicking through all of them. --- ## SSO, Documents, And The Audit Trail Three things separate a hobby portal from one a real business will sign off on. **SSO and provisioning.** Smaller clients are fine with email-and-password. Larger ones will ask you to support their identity provider - log in with Okta, with Google Workspace, with their corporate SSO - and to deactivate a user automatically when that person leaves their company. That second part is SCIM provisioning, and it is distinct from login. WorkOS has a clear explainer on [how SCIM and SSO differ and work together](https://workos.com/guide/scim-vs-sso): SSO handles the authentication, SCIM keeps the user list in sync so a departed employee loses access without you touching anything. Most no-code builders support basic SSO; few handle SCIM, and that gap is often what blocks an enterprise deal. **Secure documents and e-sign.** A document list is easy. A secure document list is not. Files need signed, expiring URLs so a link shared in one client's portal cannot be replayed to fetch another client's file. If you store files in Supabase Storage, access is governed by the same policy engine as your tables - its [storage access control docs](https://supabase.com/docs/guides/storage/security/access-control) show how to gate downloads with RLS-style rules. E-signature usually means embedding a real provider rather than rolling your own, because a signature you cannot prove in a dispute is worthless. **Audit logging.** When a client asks "who downloaded this contract and when," you need an answer. That means an append-only log of who accessed or changed what, recorded server-side where a user cannot edit it. Most no-code portals have no audit trail at all, and you discover this exactly when you need it most - during a dispute or a security review. --- ## What To Decide Before You Build The order of operations matters more than the tool. Before you place a single block: 1. Write the permission matrix. Roles by records by fields. If you cannot fill in every cell, you do not yet understand the requirement. 2. Decide where access is enforced - data layer, not screen. Confirm your tool does record-level rules at the API, and verify it with the network-tab test. 3. Know your ceiling. If you need SCIM, hardware-key SSO, signed audit logs, or e-sign you can defend in a dispute, find out now whether the builder supports it or whether you will hit a wall at the exact moment a serious client signs. A client portal is a multi-tenant access-control problem wearing a friendly document-sharing costume. The screens are the easy 60-70%. The row-level scoping, the role matrix, the SSO, and the audit trail are the 30-40% that decides whether the portal is something you can put a real client's name on - or a leak waiting for the wrong login. If you have built the easy version and hit that wall, the honest options are to learn the permission model deeply, hire it out, or use a platform like [Creatr](https://getcreatr.com)'s DeepBuild that treats access control as a first-class part of the data model rather than a setting you bolt on per screen. Whatever you choose, decide it before a client sees the wrong invoice - not after. --- # https://getcreatr.com/build-custom-crm-without-code # How to Build a Custom CRM Without Code (That Actually Runs Your Business) **The short version:** A custom CRM fits your process where Salesforce and HubSpot do not, and AI builders like Lovable or Bolt can scaffold it fast. But the architecture must be decided before the build: separate fields for separate concepts, and row-level security at the database layer so each rep sees only their leads - it is disabled in 88% of vibe-coded apps and cannot be retrofitted. Get the data model and access model right first, or use a managed build. Build a custom CRM without code for your business in 2026 The sales director at a US jewelry trade business had been using a generic CRM for two years before he came to us with a simple question: which trade shows actually generate deals that close? He could not answer it. His CRM had a "pipeline stage" field and a "contact source" field - but they had been merged into the same dropdown. A contact tagged "JCK Las Vegas" might be at the "Proposal Sent" stage, or it might just mean that is where they came from. Nobody had kept the distinction clean. Two years of show data, and he could not tell whether the spring show in Vegas outperformed the regional show in Dallas. That is the problem with off-the-shelf CRMs. Not that they are expensive - though [Salesforce at $25 per user per month](https://www.salesforce.com/sales/pricing/) turns into $500-2000 per month for a small team once you account for implementation, admin, and customization costs. And not that they are generic - though HubSpot's free tier caps out fast, with automation features that jump to $45-800 per month the moment your team needs them. The real problem is that they were built for someone else's business, and making them fit yours requires either accepting the misfit or spending money you do not have on consultants who will charge you to work around limitations that should not exist in the first place. A custom CRM built for the way your specific business actually works is not a vanity project. It is often the difference between a sales process you can manage and one you cannot. --- ## What a Production CRM Actually Needs Before getting into how to build one, it is worth being precise about what "production CRM" means. Not a spreadsheet you relabeled. Not a Notion database dressed up with pipeline views. A system that runs your business day to day, that your team logs into every morning, that does not break when three reps are working it simultaneously. A production CRM needs five things that most tools either skip or implement badly. The first is custom fields designed around your actual sales process. Not the standard "contact name, email, phone, company" - those are table stakes. The fields that matter are the ones specific to how you sell. A jewelry trade business needs pipeline stage and contact source as separate fields, not combined. A B2B SaaS needs a "product tier of interest" field and a "current tool they use" field. A services firm needs "project type" and "referral source" tracked independently. Generic CRMs give you generic fields. Your business runs on the specific ones. The second is pipeline stages that match your actual funnel. Salesforce ships with stages like "Prospecting," "Needs Analysis," "Proposal/Price Quote." If your sales process is "Met at Show - Demo Scheduled - Demo Completed - First Order - Repeat Customer," that vocabulary mismatch is not cosmetic. Your team will shoehorn their real process into the wrong stages, and your reporting will tell you nothing useful. The third is role-based access that reflects how your team is actually structured. A five-person sales team where every rep sees every other rep's leads is a recipe for confusion and territorial conflict. A manager who can see aggregate conversion rates but not individual contacts is a legitimate requirement. An external partner who needs view-only access to a specific account segment needs that to work without you giving them admin credentials. These are not edge cases - they are how real businesses with real teams operate. The fourth is integrations that match your actual communication channels. WhatsApp follow-up rates for B2B are roughly 70% open rates versus 8% for email. If your sales process runs on WhatsApp and your CRM does not connect to it, your CRM is managing a shadow of your pipeline. The real follow-up activity happens in a chat app that cannot report on anything. Email integration, Google Calendar sync, and WhatsApp Business API connection are not nice-to-haves for businesses that actually use those channels - they are the difference between a CRM that captures your sales activity and one that captures a fraction of it. The fifth is reporting that answers the questions you actually have. Not generic charts. Specific reports: which lead sources produce deals that close, which pipeline stages have the longest average time-to-advance, which reps have the highest demo-to-close rate, which trade show generated the most revenue last year. These reports cannot exist if the underlying data model did not anticipate the questions. And the data model cannot anticipate your questions if it was designed for someone else's business. --- ## Why Salesforce and HubSpot Both Fail the Same Test The honest version of why Salesforce fails small businesses is not the price - though $25 per user per month plus a Salesforce admin at $60,000-100,000 per year is a real number that most small teams cannot absorb. The honest version is that Salesforce's power comes from its flexibility, and flexibility requires expertise to configure. Salesforce will do almost anything you need. The challenge is that making it do exactly what you need requires someone who knows Salesforce - not the product you are selling, not the way your sales process works, but Salesforce specifically. That person costs money and time you do not have at the start. The configuration overhead is not a one-time cost. Every time your sales process changes - you add a new channel, a new product line, a new role, a new stage - you either wait for your admin to make the change or you learn enough about Salesforce to do it yourself. Neither is fast. HubSpot's free CRM is genuinely free, and it is genuinely good as far as it goes. Contact records, basic pipeline, email logging - all there, no cost. The trap is that the features a growing sales team actually needs are not in the free tier. Automation that follows up with leads on a schedule, reporting that breaks down performance by source or rep, multi-team views with role-based permissions, sequences that send follow-up emails based on deal stage - these unlock at $45-800 per month depending on how many people need them. Most small businesses discover this around month three, when they have already built their process around HubSpot and now face a price increase they did not plan for. The more fundamental issue with both tools is the same issue that affects every off-the-shelf CRM: they were designed for the average business, which means they fit no specific business exactly. The jewelry trade business with the show-attribution problem was not asking for anything exotic. They wanted two fields kept separate and a report that joined them. HubSpot and Salesforce both technically support this. The implementation required either a custom field configuration that took a consultant two days to build or a workaround that muddied the data for everything else. A CRM built specifically for your business has none of those workarounds. Every field exists because your process requires it. Every stage name is vocabulary your team uses. Every report answers a question you actually ask. --- ## What "Without Code" Actually Means The phrase "build a CRM without code" is technically accurate and practically incomplete. You, as the person commissioning the build, do not write code. That is true. But someone has to make the architectural decisions that determine whether the system is correct - and those decisions are not the same as writing code. The architectural decisions for a CRM are things like: how is multi-tenant data isolated so that rep A cannot query rep B's contacts? Where does the pipeline stage live in the database - is it a foreign key to a stages table, or a string field that anyone can write any value to? How does the webhook from your email provider attach incoming replies to the right contact record? What happens when two reps try to update the same contact at the same time? None of these questions require you to write a line of code to answer them. They require you to think carefully about how your business works and convey that clearly before anyone starts building. The gap between "I want a CRM for my jewelry business" and "I want a CRM where pipeline stage and contact source are separate fields, where each rep only sees their own leads, where trade show events have their own booking links, and where the dashboard shows me show-level conversion rates" is not a coding problem. It is a requirements problem. This is where AI builders trip founders up. Tools like Lovable or Bolt will take a vague description and immediately start generating something that looks like a CRM. It will have a contacts table, a pipeline board, some stage labels. It will look functional. And 88% of the time, according to a 2026 audit of vibe-coded apps, the row-level security will be entirely disabled - meaning any authenticated user can query any contact in the database, regardless of which rep owns the record. For a CRM where rep isolation is a real business requirement, this is not a minor misconfiguration. It is a fundamental design failure that cannot be patched after the fact without rebuilding the access model from scratch. "Without code" means you do not write the code. It does not mean the architectural decisions go unmade. They either get made deliberately, before the build starts, or they get made by default by whatever common-case assumptions the tool applies. For a CRM managing real sales data for a real team, the difference between deliberate and default architecture is the difference between a system that works correctly and one that looks correct until you stress it. --- ## The SalesCRM Story: Why Separate Fields Changed Everything The jewelry trade business case is worth unpacking because it illustrates the kind of requirement that gets lost in every generic CRM, and that only becomes visible when you build something purpose-built. Pivu, the founder, had been using a standard CRM for two years. The problem was not that the CRM lacked fields - it had plenty. The problem was that "contact source" and "pipeline stage" had been combined in the same field. When a rep logged a contact as "JCK Las Vegas," that meant either "this contact came from the JCK Las Vegas show" or "this deal is at the JCK Las Vegas stage" - the semantics had drifted, nobody had enforced the distinction, and two years of data had become ambiguous. The sales director's question - which shows generate deals that close? - required joining two separate facts: where did this contact come from (the show), and where did they end up (the stage they reached before going cold or converting). With both facts in one field, the join was impossible. You could not filter "contacts from JCK Vegas" and then ask "how many of them reached First Order Placed" because the field did not cleanly mean either thing. When we built SalesCRM, "pipeline stage" and "contact source" became separate fields in the database from the first commit. Stage was a foreign key to a stages table with six defined values: New, Demo Scheduled, Demo Completed, First Request Submitted, First Order Placed, Active Customer. Source was a separate foreign key to a sources table with values the team controlled: trade show name, referral, partnership, inbound. The dashboard's "Lead Source Performance" chart was possible from the first day because the data model anticipated the question. This is not a sophisticated technical insight. It is a basic requirements conversation that did not happen during the original CRM implementation. The conversation costs nothing. The cost of not having it - two years of unusable attribution data - was real. --- ## What Breaks in AI-Builder CRMs There are three specific failure modes that show up when founders try to build production CRMs using AI coding tools like Lovable, Bolt, or Cursor without the architectural groundwork being laid first. The first is multi-user data isolation. A CRM is fundamentally a multi-user system. Multiple reps, different roles, potentially multiple clients or business units sharing an instance. The isolation between those users - who can see what, who can query whose contacts - has to be enforced at the database level to be trustworthy. Application-level filtering, where the code retrieves records and then filters them before displaying them, looks correct in a demo where you are the only user. It can be bypassed by anyone who knows how to hit your API directly. Row-level security, the database-layer mechanism that enforces access policies regardless of what the application code does, is absent in 88% of vibe-coded apps. For a CRM, this means your reps could query each other's pipelines by making direct database calls - or a security researcher could query your entire contacts database without logging in as any specific user. The second failure mode is automation triggers. A real CRM is not just a place to store contacts - it is a system that does things when certain conditions are met. Stage changes create follow-up tasks. New contacts get routed to the right rep. Deals that have not moved in ten days trigger a reminder email. These automations require a trigger mechanism - usually database webhooks or event systems that fire when specific records change. AI builders add automations as features when you ask for them, one at a time, without building the underlying event system that would make them reliable. The result is a collection of individual automations that each work in isolation but have no coherent foundation. When you add a new stage or change a routing rule, each automation has to be individually updated - there is no central logic that governs them all. The third failure mode is custom reporting. Generic AI builders produce generic dashboards. A bar chart of contacts by stage, a count of open deals, a table of recent activity. These look like reporting. They are not the reports your specific business needs. The reports that matter - show-level conversion rates, rep performance by lead source, average days per stage broken out by deal size - require both the right data model (separate fields for separate concepts, foreign keys to the right tables) and the right queries built around your specific business questions. An AI builder that started from a generic description cannot anticipate your specific questions. The reporting it produces reflects the questions that every CRM is expected to answer, not the questions your sales process actually generates. --- ## What a Custom CRM Build Actually Looks Like When we built SalesCRM for Pivu's jewelry trade business, the build started with a requirements conversation before any code was written. The conversation covered: who are the users and what does each role see? What are the pipeline stages, exactly, and what does each one mean? Where do contacts come from and how is that tracked? What integrations are non-negotiable - email, calendar, WhatsApp? What reports does the sales director need to answer the questions he actually has? The answers to those questions produced a data model. Pipeline stages as a foreign key to a stages table. Contact source as a separate foreign key to a sources table. Lead ownership tied to rep records, with row-level security policies at the database level enforcing that each rep's queries return only their leads. Trade shows as their own table, with booking links that auto-attribute new contacts to the show they booked through. A follow-up tasks table that fires on stage changes via database webhooks. The code written from that foundation was not the creative part. The creative part was the requirements conversation. The code was the execution of decisions already made. The final system included: a six-stage pipeline with Kanban and funnel views, automatic follow-up tasks by stage (2-business-day check-in for new leads, 24-hour demo reminder, 3-day post-demo nudge), per-stage email templates with merge fields, trade show booking links that handle time zone differences across shows, Google Calendar sync, per-rep lead visibility enforced at the database level, and a dashboard with show-level conversion reporting that answered the question that had been unanswerable for two years. It took less time to build than configuring Salesforce would have cost. It runs the business without a Salesforce admin. And every question the sales director asks now has an answer in the data. --- ## WhatsApp Integration: The Channel That Generic CRMs Skip Most CRM conversations focus on email because email has been the default B2B follow-up channel for twenty years. The data has shifted. B2B WhatsApp follow-up rates are around 70% open rates. Email open rates for B2B follow-up sequences average around 8%. If your business runs on WhatsApp - and most businesses selling to buyers in Asia, the Middle East, Latin America, or Africa already do - a CRM that does not connect to WhatsApp is not capturing your real sales activity. WhatsApp Business API integration in a custom CRM means two things. First, outbound: a rep can send a stage-appropriate follow-up message directly from the contact record, logged to the contact's timeline, tracked for response. Second, inbound: when a contact replies via WhatsApp, the reply attaches to the contact record. The conversation thread is in the CRM, not split across four people's WhatsApp accounts. The generic CRM answer to this is a third-party WhatsApp integration that costs an additional $50-200 per month and typically requires a separate platform that stores your message history outside your CRM. A custom CRM built with WhatsApp integration native to the data model keeps everything in one place. The contact record is the single source of truth - call logs, email sends, WhatsApp messages, stage changes, follow-up tasks, calendar appointments - all in one timeline. This is not a technical luxury. For businesses where WhatsApp is the primary follow-up channel, a CRM without it is running on incomplete data. The pipeline stages exist in the CRM. The actual relationship exists in chat. A custom build closes that gap. --- ## The Architecture Question You Need to Answer First Before you start any CRM build - with any tool, at any price point - there is one architectural question that determines whether the result will work: how is multi-user data isolated? This is not a question most founders know to ask. It is also not a question any AI builder will raise unprompted. The default behavior for every vibe-coded CRM is to handle data access at the application level - the code filters records before displaying them. This is correct as a user-facing experience. It is insufficient as a security boundary. The answer you want is: row-level security policies at the database level enforce that each user's queries return only the records they are authorized to see, regardless of what the application code does. This means that even if a bug exists in the application's access control logic, the database layer prevents unauthorized data from being returned. It is not a feature you can add afterward without rebuilding the access model. It has to be designed into the schema from the first table. If you are evaluating a CRM build from any provider and they cannot tell you how multi-user data isolation works at the database layer, the system does not have it. That is not a theoretical security concern for a CRM handling your actual customer contacts, deal history, and sales correspondence. It is a real vulnerability. The requirement is simple to state: row-level security policies, defined per table, enforcing that user A's queries return user A's records and not user B's. The implementation requires that the schema was designed with user ownership baked in from the start. You cannot retrofit this on a data model that was not designed for it. --- ## What You Get That Salesforce Cannot Give You A custom CRM built for your specific business produces something no off-the-shelf tool can: a data model that matches the way your business actually operates. Every field exists because your process requires it. Every stage name is vocabulary your team already uses. Every report was designed to answer a question you actually ask. The secondary benefit is speed. A CRM that fits your process does not require training your team to think in Salesforce vocabulary. The onboarding is "here is your pipeline, here are your stages, here are your follow-up tasks" - the same words they already use to describe their day. The third benefit is control. When your business changes - when you add a new product line, a new channel, a new role - you are not filing a support ticket or hiring a Salesforce admin. The system can change because the people who built it understand it fully and can modify it when the business requires it. The fourth benefit is cost. Not just upfront cost, though a custom CRM built with the right approach typically costs significantly less than a year of Salesforce licensing plus admin time. The ongoing cost is also lower: no per-seat fees that increase as your team grows, no feature tier upgrades when you need automation, no add-on costs for integrations with channels you already use. The trade-off is honest: you do not get the 800 integrations Salesforce supports, the ecosystem of consultants who know the platform, or the decades of enterprise feature development. What you get is a system that runs your specific business correctly - without the workarounds, the unused features, and the ongoing cost of configuration debt. For the jewelry trade business, the question that prompted the rebuild - which shows generate deals that close? - is now a one-click report. Two years of show data, properly attributed, properly staged, now answerable in seconds. That question was always answerable in theory. It required a data model designed to answer it. --- # https://getcreatr.com/build-directory-website-without-code # How to Build a Directory Website Without Code in 2026 How to build a directory website without code in 2026 **The short version:** the listing pages are easy - the hard part is paid-listing billing, submission moderation, keeping data correct across thousands of programmatic pages, and SEO that actually indexes. The standard no-code directory is a spreadsheet and a grid. You keep your listings in Google Sheets or Airtable, point a no-code front end at it, drop in a submission form, and you have "find a [dog groomer / coworking space / Shopify agency] near me" live in an afternoon. This part genuinely works. It is a template, and every "build a directory without code" tutorial stops right here because the demo looks finished. It is not finished. A grid backed by a spreadsheet is a content page, not a directory business. The things that make a directory worth running - businesses paying to be featured, submissions that are real and not spam, listings that stay correct as the dataset grows, and pages that Google actually indexes and ranks - are the 30-40% the spreadsheet stack was never built to do. A directory lives or dies on organic search and paid listings, which means the easy part is the part that matters least. This post walks through both halves: the template, and where the template runs out of road. This is a different animal from a marketplace. A marketplace is a two-sided transactional system with escrow and a payment that splits between strangers. A directory is content plus SEO plus paid placement. The hard problems are not held funds and dispute resolution - they are billing for visibility, moderation at scale, and data integrity across pages you never hand-write. | Requirement | What the easy/no-code version does | What production actually needs | | --- | --- | --- | | Listing pages | A grid bound to spreadsheet rows | Indexable pages with unique content and metadata | | Search and filter | Client-side filter on the loaded rows | Indexed queries over the full dataset, fast | | User submissions | An open form that appends a row | Validation, dedup, and a review queue before publish | | Paid and featured listings | A field you flip after a transfer | Stripe billing with an entitlement that expires | | Data quality at scale | Stale rows nobody re-checks | Deduplicated, current data the page can be trusted to show | | Programmatic SEO | Templated pages a builder emits | Split sitemaps, correct canonicals, passing Core Web Vitals | | Moderation and anti-spam | Manual deletion after the fact | A queue, rate limits, and spam scoring before publish | --- ## The 60-70% the Spreadsheet Stack Handles Well Be honest about what the easy path gets right, because it gets a lot right. A spreadsheet of listings, a no-code front end that renders them as cards, category and location filters, a detail page per listing, and a submission form that appends a row. For a directory with a few hundred entries that you curate yourself, this is genuinely enough to launch and start collecting traffic. The structure is real: you have a browsable catalog, deep links to individual entries, and a way for owners to ask to be added. The reason this works is that early on, a directory is small enough to manage by hand. You can eyeball every submission. You can fix a wrong phone number when someone emails you. Filtering 200 rows in the browser is instant. The dataset is small enough that none of the hard problems have teeth yet. The trap is that the template's ceiling is invisible until you hit it. Everything that makes the spreadsheet version pleasant - rows you can read, submissions you can review one at a time, filtering that happens after the whole dataset loads - stops working at exactly the scale where a directory starts to matter. The break is not gradual. You add a region, a city, a category, and suddenly you have 4,000 pages, an open form that bots found overnight, and a sitemap Google is ignoring. Here is where each piece breaks. --- ## Paid and Featured Listings: The Billing Problem The business model of most directories is visibility. A business pays to be featured, to sit at the top of its category, to get a verified badge, or to renew a listing that would otherwise expire. That is a recurring-billing problem, and it is the single thing the spreadsheet stack cannot fake. What the easy version does is a boolean. There is a `featured` column. Someone pays you over PayPal or a bank transfer, you flip the column to `TRUE`, and the card jumps to the top. This works for your first three paying customers and then becomes a part-time job. There is no record of when the feature expires, no automatic downgrade when it does, no proration when someone upgrades mid-cycle, and no way for the customer to manage their own plan. You are the billing system, and you do not scale. Production billing for a directory means a subscription or a timed entitlement, not a one-off charge and a manual flag. The pattern is: a payment creates a subscription, the subscription grants an entitlement ("this listing is featured until X"), a webhook updates your database when the subscription renews or lapses, and your render logic reads the entitlement, not a hand-set boolean. Stripe's [Billing subscriptions overview](https://docs.stripe.com/billing/subscriptions/overview) walks through the subscription lifecycle - incomplete, active, past_due, canceled - and the [subscriptions integration guide](https://docs.stripe.com/billing/subscriptions/build-subscriptions) covers wiring the webhooks that keep your entitlement in sync. If you are charging for tiers (featured, verified, premium placement), you want the entitlement to be the source of truth and the boolean column gone entirely. If you are coming from the spreadsheet world, the mental shift is this: payment is an event, not a state. The state is the entitlement it grants, and that state expires on its own. Getting this wrong is how directories end up with listings that stayed "featured" for a year after the customer stopped paying. We go deeper on this in [adding Stripe payments to an AI-built app](/add-stripe-payments-to-ai-built-app). --- ## User Submissions: Moderation and Dedup Before Publish An open form that appends a row is a spam magnet. Within days of getting any traffic, an open submission form attracts bot submissions, fake businesses, listings for the same business submitted four times with slightly different names, and outright SEO spam pointing at junk domains. If those go live automatically, your directory's quality - the only thing that earns trust and links - is gone. The easy version has no queue. A submission is a published listing. Moderation, if it exists, is you noticing something bad after it is already indexed and deleting it. By then Google has crawled it, and the cleanup is reactive forever. Production submission handling needs three things the form does not have. First, a review state: submissions land as `pending` and a human or a rule promotes them to `published`. Nothing user-submitted goes live unmoderated. Second, deduplication: before a submission is accepted, you check it against existing listings by name, address, phone, and domain, because the same business will be submitted repeatedly and duplicates wreck both the user experience and your structured data. Third, anti-spam at the door: rate limits per IP, a honeypot or challenge on the form, and a basic spam score on the content (link count, keyword stuffing, known-bad domains) so the obvious junk never reaches the queue. None of this is exotic, but all of it is server-side logic with a real datastore behind it - a review queue, a dedup check, a moderation log. A spreadsheet append has nowhere to put any of it. --- ## Data Integrity Across Thousands of Pages This is the problem that separates a directory that ranks from one that quietly rots. A directory's value is that its data is correct. When the listing says a business is open, it should be open. When it shows a phone number, the number should work. At 200 hand-curated listings, you maintain this by hand. At 5,000 listings across dozens of categories and cities, hand-maintenance is impossible and the spreadsheet has no mechanism to help. Stale data is the slow death. Businesses close, move, change hours, rebrand. A directory full of dead listings and wrong numbers is worse than no directory, and users who hit one bad entry stop trusting all of them. The spreadsheet does nothing to detect this - a wrong row looks exactly like a right row. Production data integrity means treating the dataset as data, not as a document. Concretely: a canonical record per real-world entity so the same business is not three rows; validation on every field so a "phone number" is actually a phone number and a URL resolves; a freshness signal so you know which records have not been re-checked and can flag or de-rank them; and ideally a periodic re-verification pass (re-crawl the source, ping the website, check the listing still exists). The deduplication you do at submission time is the same discipline applied continuously. A directory is a database problem wearing a content-site costume, and the spreadsheet hides the database problem until the data is already wrong at scale. --- ## Programmatic SEO That Actually Indexes A directory makes money from one channel: organic search. Someone types "vegan restaurants in Austin" and lands on your category-city page. That page was not hand-written - it was generated from a template over your data, which is what programmatic SEO means. The spreadsheet stack can emit thousands of these pages. What it cannot do is make Google index and rank them, and an un-indexed page earns nothing. Generated pages have a specific failure mode: they are thin and near-duplicate. "Plumbers in Springfield" and "Plumbers in Shelbyville" differ only by the city name and the listings, so Google sees them as duplicates and either picks one as canonical or drops most of them from the index. Volume without uniqueness gets you crawled and ignored. The fix is making each page carry genuinely different, useful content - real listings, real local detail - and telling Google clearly which URL is the one that counts, per [Google's guidance on consolidating duplicate URLs with canonicals](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls). Then there is crawl budget. A few thousand pages will not all get crawled if Google cannot find them efficiently. You need a sitemap, and because a single sitemap caps at 50,000 URLs, large directories need a [sitemap index splitting the URLs across multiple files](https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps), submitted per [Search Central's sitemap overview](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview). A sitemap is a strong hint to crawl, not a guarantee to index - indexing still depends on the pages being worth indexing. Two more things the template skips. Structured data: directory listings should carry [LocalBusiness structured data](https://developers.google.com/search/docs/appearance/structured-data/local-business) so Google understands each entry is a business with a name, address, and hours, which is what makes rich results possible. And performance: [Core Web Vitals](https://web.dev/articles/vitals) are a ranking signal, and a page that loads listings client-side from a spreadsheet API after the initial render tends to fail Largest Contentful Paint and shift layout while the data arrives. Server-rendered pages with the content present at first paint are what pass. None of this is optional for a directory whose entire business is ranking. --- ## What This Means If You Are Building One The honest split looks like this. If your directory is a few hundred curated entries and you are the only one adding them, the spreadsheet stack is the right tool and you should ship it today. Do not over-build a moderation queue for submissions you do not get. The moment any of four things becomes true, you have crossed into the 30-40%: you want to charge for placement, you open submissions to the public, your dataset grows past what you can eyeball, or organic search becomes the channel you live on. Each of those is a system the template does not have - billing with entitlements, a moderation pipeline, continuous data integrity, and indexable programmatic SEO. They are not prompt-iterations on the spreadsheet version; they are a different architecture underneath the same-looking grid. The pattern is the same one you hit building a [marketplace without code](/build-marketplace-app-without-code) or a [job board without code](/build-job-board-without-code): the demo is easy, the business is the part underneath. AI builders and no-code tools get you to a convincing 60-70% fast, then stall on auth, billing, data correctness, and the integrations that have to handle their own failure paths. That stall is not a sign you picked the wrong tool. It is the actual shape of the work, and it is where a service like [Creatr's DeepBuild](https://getcreatr.com) - which designs the data model, billing, and SEO architecture up front and ships the production app - is built to take over. Build the spreadsheet version. Use it to prove people want the directory. Then, before you charge or open submissions or chase rankings, design the 30-40% deliberately instead of discovering it the hard way when a bot fills your form or Google ignores your sitemap. --- # https://getcreatr.com/build-ecommerce-app-without-code # How to Build an E-Commerce App Without Code in 2026 **The short version:** If you sell a fixed-price catalog, use Shopify and stop. If you have custom pricing, vendor splits, subscriptions, or B2B approval flows, you are building an app - design the data model first, then use an AI builder like Lovable or Bolt for the UI, Supabase for auth and database, and Stripe for payments. The hard 30% the AI gets wrong: Stripe webhook handling, transactional inventory decrements under concurrency, multi-state order machines, and row-level vendor isolation. Review those before going live. How to build an ecommerce app without code 2026 If you already knew about [Shopify](https://www.shopify.com), you would not be searching for "build ecommerce app without code." You are searching because you tried Shopify - or looked at it closely enough to see the ceiling - and realized it does not do what your business actually needs. That is the right instinct. Shopify is a catalog-plus-checkout platform. It is excellent at what it does: take a list of products, add a price to each, accept payment, send a confirmation email. If your business model fits inside that shape, use Shopify and stop reading. But a specific set of business models do not fit that shape. Custom pricing by customer segment. Vendor revenue splits. Subscription boxes that also ship physical goods. B2B purchasing with approval workflows and purchase orders. These businesses are not storefronts - they are apps that happen to sell things. The tools you need, the architecture you need, and the decisions you need to make before building are completely different. This post is for those businesses. --- ## The Shopify Trap Here is what happens when a business with complex pricing logic tries to build on Shopify: the first version works. You find a theme, you install a few apps, you configure a checkout. Then reality arrives. Your wholesale customers need different prices than retail customers. Shopify has a workaround - price lists, B2B features on the Plus plan, third-party apps. You install the app. It works for most orders. Then a wholesale customer checks out with mixed cart items and the price list does not apply correctly. You file a support ticket. The app developer says it is a Shopify API limitation. Your vendor partners need to see their own orders and receive their portion of each payment. Shopify does not have vendor dashboards. You find an app. The app shows vendors their orders but does not handle payouts - you are doing that manually in a spreadsheet. The spreadsheet breaks when order volume exceeds what one person can reconcile. Your subscription product ships a physical item plus provides access to a service. Shopify Subscriptions handles the recurring billing. It does not handle the fulfillment state machine - the logic that tracks whether this month's box shipped, whether the customer is paused, whether a failed payment should hold the shipment or cancel the subscription. You are writing that logic in Shopify Flow, which is a visual scripting tool with enough limitations that you spend two weeks building something that would take a developer two days. The trap is not that Shopify is bad. The trap is staying inside it past the point where it fits your model. --- ## The Four E-Commerce Types Before choosing any tool, classify your business. The right tool depends almost entirely on which type you have. ### Type 1: Simple catalog with checkout You sell products with fixed prices. Customers browse, add to cart, check out. No custom pricing, no vendor splits, no subscriptions, no approval flows. Use [Shopify](https://www.shopify.com) or [Webflow](https://webflow.com) Commerce. Both handle this well. Shopify is better if you need a large app ecosystem or plan to sell across social channels. Webflow is better if design control matters more than out-of-the-box features. Do not over-engineer this. A custom app for a simple catalog is a mistake - it costs more to build, more to maintain, and gives you less than Shopify's existing infrastructure. ### Type 2: Multi-vendor marketplace Sellers list products on your platform. You take a cut of each sale. Sellers need dashboards to manage their listings and see their earnings. Payouts go to multiple sellers per transaction. This is not a storefront. This is an app. You need custom authentication so sellers and buyers have different views of the same data. You need a vendor dashboard that shows each seller only their own inventory and orders. You need split payment logic using [Stripe Connect](https://stripe.com) so your platform fee is deducted automatically before the seller's portion is transferred. None of this is available in Shopify's standard offering. Building it on top of Shopify through apps is technically possible but produces a fragile stack with recurring license fees and integration breakages. A purpose-built app with [Supabase](https://supabase.com) for the database (with row-level security enforcing vendor data isolation) and Stripe Connect for split payments is the right architecture for a marketplace. [Lovable](https://lovable.dev) or [Bolt](https://bolt.new) can generate the UI scaffolding - the product listing pages, the vendor dashboard layout, the order history views. The payment architecture and the row-level security policies need to be implemented correctly, which means either reviewing what the AI generated carefully or bringing a developer in for those specific pieces. Once you are holding funds and paying out sellers, the split-payment layer carries real compliance weight - the same money-movement problem we break down in [building a fintech app without code](/how-to-build-fintech-app-without-code). ### Type 3: Subscription plus physical Recurring billing tied to physical fulfillment. The subscription renews, which triggers a shipment. A paused subscription holds the next shipment. A failed payment triggers a retry sequence before canceling. A canceled subscription stops fulfillment but may need to honor the current billing cycle. The core tool here is [Stripe Billing](https://stripe.com) for the recurring payment logic - subscription creation, pause and resume, retry handling, proration on plan changes. The fulfillment state machine - the logic that connects payment events to warehouse actions - lives in a backend that responds to Stripe webhooks. This is the type most likely to be underestimated. The billing side is well-served by Stripe's no-code dashboard for simple cases. The fulfillment side requires a backend that handles the event stream from Stripe and produces the right state changes in your inventory system. An AI builder can generate a working version of this if you specify the webhook handling logic clearly. The test is whether it handles the failure cases: what happens when a payment fails on day 2 of the month, retries succeed on day 5, and a shipment was already queued for day 3. ### Type 4: B2B with custom pricing Each customer has a negotiated price list. Large orders go through a purchase order process. Someone in the buying organization needs to request the order; someone else needs to approve it before payment. Net-30 terms may apply instead of immediate card payment. This requires a database with a customer pricing table, a role system that distinguishes requesters from approvers within the same company, and an order state machine that includes a pending-approval state before confirmed. It also requires invoicing - generating a PDF invoice with correct line items and payment terms and attaching it to the order record. There is no Shopify configuration that produces this. There is no template. This is application logic that needs to be designed before any tool starts building it. AI builders can generate the UI for the purchase order form and the approval workflow view. The database schema for customer-specific pricing and the role hierarchy within buying organizations need to be specified explicitly. --- ## What a Production E-Commerce App Actually Requires Beyond the storefront, every e-commerce app that handles real transactions needs these systems working correctly. **Authentication and customer accounts.** Customers need persistent accounts. Their order history, saved addresses, and payment methods need to be associated with their identity across sessions. For B2B, multiple users share the same company account with different permissions. [Supabase Auth](https://supabase.com) handles this with email/password, social login, and magic links, plus row-level security that enforces what each user can read and write at the database level. **Order state machine.** Every order moves through states: pending payment, confirmed, processing, shipped, delivered, and possibly returned or refunded. Each state transition has a trigger (payment confirmed, warehouse confirms shipment, customer reports delivery issue) and a set of side effects (send confirmation email, update inventory count, notify the vendor). The state machine needs to handle the states it was not designed for - the payment that was authorized but not captured, the order that shipped but whose tracking number never updated, the refund that was initiated but not yet processed by the payment provider. **Inventory management.** Products have quantities. When a customer places an order, that quantity needs to be decremented before the next customer's request reads it. This is a concurrency problem - two customers cannot both buy the last unit. The standard solution is a database transaction that checks availability and decrements atomically. AI builders generate optimistic inventory checks that work fine for low traffic and fail under concurrent load. If you are building anything expected to handle real traffic, verify that your inventory decrement is transactional. **Payment processing with webhook handling.** [Stripe](https://stripe.com) processes the payment. Stripe also sends webhook events when payment states change - charge succeeded, payment failed, refund completed, dispute opened. Your app needs a webhook endpoint that receives these events, validates their authenticity, and produces the correct state changes in your database. The webhook handler is one of the parts most frequently broken in AI-generated e-commerce apps. Stripe's documentation on webhook signature validation is explicit - follow it exactly. **Vendor and seller management (for marketplace types).** Each vendor needs a profile, a list of their products, a view of their orders, and a record of their earnings and payouts. The data isolation between vendors - ensuring that Vendor A cannot see Vendor B's orders or products - needs to be enforced at the database level, not just by application-layer filtering. --- ## Where AI Builders Work and Where They Break [Lovable](https://lovable.dev) and [Bolt](https://bolt.new) are genuinely useful for e-commerce app development. The question is which parts. **Where they work well.** The product listing page. The product detail view with images, description, and add-to-cart. The shopping cart UI. The checkout form. The order confirmation page. The order history view for a customer. The admin dashboard layout showing recent orders and revenue totals. These are UI patterns that appear frequently in training data and get generated accurately. Starting a build with an AI tool for these pieces is faster than building them from scratch. **Where they break.** Complex pricing rules that involve customer segments, quantity breaks, or negotiated rates. Inventory decrement under concurrent load. Stripe webhook handling with correct signature validation and idempotency. Order state machines with more than four states and non-linear transitions. Row-level security policies that enforce vendor data isolation. These are the parts where the AI-generated code looks correct and behaves incorrectly under real conditions - either failing silently, producing wrong results, or breaking when two things happen at the same time. The pattern that works: use an AI builder to generate the UI scaffolding and the happy-path flows, then review and replace the payment handling, the state machine, and the data access layer with implementations that have been validated against the actual requirements. --- ## Decision Tree: What to Actually Build Answer these questions in order: **Does your pricing vary by customer?** If no, and you have a fixed-price catalog, use Shopify. If yes, you need a database with a customer pricing table. You are building an app. **Do multiple vendors or sellers list products?** If yes, you need vendor auth, vendor dashboards, and Stripe Connect for split payments. Shopify cannot do this at a reasonable cost. Build a purpose-built app. **Does your product recur on a schedule?** If yes, you need Stripe Billing plus a fulfillment state machine that responds to billing events. Design the webhook handler before you write any other code. **Do orders require approval before payment?** If yes, you need an order state that precedes payment authorization. This is a B2B purchasing workflow. Design the role hierarchy and the state machine before building. If none of the above apply, use Shopify or Webflow and spend your time on product and marketing instead. If any of them apply, you are building a real app. Start with the data model, not the UI. Define every entity (customers, products, orders, vendors, pricing rules), every relationship between them, and every state an order can be in. Then use an AI builder for the UI layer, Supabase for the database and auth, and Stripe for payments. Review the payment handling and the state machine before going live. That sequence produces a working product. Skipping the design phase and iterating your way toward it does not. --- # https://getcreatr.com/build-internal-tool-without-code # How to Build Internal Tools Without Code (And Why "Just for Us" Is Not a Lower Bar) **The short version:** Match the tool to the type: Retool or Metabase for data-heavy dashboards and admin panels, Airtable for intake forms, AI builders like Lovable or Bolt for simple tools with few users. "Just for us" is not a lower bar - the hard part is the multi-role permission matrix and data isolation, which must be enforced server-side and at the database level, not screen by screen. Map the real process with edge cases first; for business-critical tools, use a managed build. Build internal tools without code in 2026 The internal tool is usually the first thing a growing team tries to build without a developer. The logic is understandable. Nobody outside the company will see this. The users are the five people on the team who already know the context. If it is a little rough, they can work around it. They are not customers. They are colleagues. This reasoning is wrong in a specific way, and it is worth understanding why before you start building. --- ## Why "Just for Us" Is Not a Lower Bar The users of your internal tool are the people who run your business. When the tool breaks, the business slows down or stops. When the tool produces wrong data, decisions get made on wrong information. When the tool is slow or painful to use, your team works around it instead of through it - which means you do not actually have a system, you have a tool that nobody trusts enough to use. Customer-facing apps get rebuilt because users churn. Internal tools get rebuilt because they become part of the infrastructure and then something goes wrong that cannot be worked around. The additional complexity is access control. A customer-facing app typically has one or two user types. An internal tool often has five: the admin who can do everything, the manager who can see reports but not billing, the field rep who can enter data but not edit others' records, the client who gets a read-only view of specific data, and the finance team who needs exports but nothing else. This permission matrix is complex. In a vibe-coded tool where access control was added screen by screen rather than designed into the data model from the start, it breaks in ways that are invisible until something goes wrong. The bar for an internal tool is not lower. It is different. Less polish, more reliability. Less visual sophistication, more correctness at the data layer. --- ## The Five Internal Tool Types Most internal tools fall into one of five categories. The category determines the right approach. ### 1. Ops Dashboards An ops dashboard aggregates data from multiple sources - your CRM, your payment processor, your logistics system, your customer support queue - and presents it in a single view for whoever needs to see it. The main technical challenge is not the display layer. Showing numbers in a table is easy. The challenge is the data pipeline: getting reliable, real-time (or near-real-time) data from systems that were not designed to talk to each other, handling cases where a source is unavailable, and ensuring that the numbers you see actually correspond to the current state of the business. The tools that handle this well are configuration-based rather than AI-generated: Retool, Metabase, and similar platforms are purpose-built for connecting to data sources and presenting dashboards. They are not visually flexible - everything looks like the tool - but they are stable, reliable, and maintain consistent data connections in ways that AI-generated dashboards often do not. The AI-generated path works for ops dashboards only if the data sources are controlled: your own database, a small number of well-documented APIs, and a team that can maintain the integration as the sources change. For aggregating across ten external systems, configuration-based tools are more durable. ### 2. Data Entry and Intake Forms Forms that capture data from team members, vendors, or clients and write it to a central system. These are the simplest category to build without code. The complexity is mostly in the validation logic - what fields are required, what formats are accepted, what downstream actions trigger when a form is submitted - rather than the UI. AI builders handle this category reasonably well. The form renders. The validation works. The data goes into a database. The failure modes are in the edge cases: what happens when someone submits an incomplete form, what happens when the same record gets submitted twice, what happens when a dependent field is missing. These are the cases the AI tool did not model and the form will fail on in production. The practical approach: build the happy path with an AI builder, then explicitly test every edge case before you hand it to the team. Edge cases in internal forms are usually predictable from the context of how the form will be used. ### 3. Admin Panels An admin panel lets authorized users manage the data in the system - editing records, resolving conflicts, overriding automated decisions, managing user accounts. Admin panels are the category where security failures are most expensive. An admin panel that lacks server-side authentication on its endpoints is not just a bad UX - it is a security incident waiting to happen. Any team member, or anyone who can observe the API calls, can call admin endpoints directly without going through the UI. The correct approach for admin panels is to build with access control as a first-class concern, not an afterthought. Define who can do what before any code exists. Build the permission check at the API layer, not the UI layer. Test that non-admins cannot access admin endpoints by calling them directly, not by checking whether the UI hides the button. AI tools will build an admin panel if you describe one. They will frequently not add server-side authentication on the endpoints unless you specifically ask. Ask specifically. ### 4. Workflow Automation Dashboards Tools that let team members trigger, monitor, and manage automated workflows - sending bulk communications, processing batch jobs, running reports, managing queues. These are the tools that sit between your data and your business processes. They are less about display and more about action: a button that triggers a task, a queue that shows pending items, a log that shows what ran and what failed. The AI builder path here requires careful attention to state management. A workflow tool where clicking a button triggers an action needs to handle: what happens if the action fails, what happens if the user clicks twice, what state does the system show while the action is running, and what does the user see when it is done. These are not edge cases - they are the core behaviors that make the tool trustworthy. Explicit requirements for state management are the difference between a workflow tool that the team uses and one they go around because they do not trust it to do the right thing. ### 5. Reporting and Export Tools Tools that let team members pull reports from the database, apply filters, and export data in formats they can use elsewhere. The main pitfall here is data isolation. If a reporting tool returns all records for a given query with no consideration of which records the requesting user is authorized to see, you have a data leak inside your own organization. A field rep who runs a territory report should not be able to see records from another territory. A client who gets export access should not see other clients' data in the export. Row-level security at the database level is the correct enforcement mechanism. Application-level filtering can be worked around by anyone who knows how to query the API directly. Internal tools are used by people who know the system - they are more likely than external users to explore the API surface. --- ## The Stack That Actually Works For internal tools without a developer, the options that produce reliable production results are narrower than the general AI builder category suggests. **Retool** is the strongest option for data-heavy internal tools: dashboards, admin panels, reporting. It is configuration-based, not AI-generated. The UI ceiling is low - everything looks like Retool - but it connects to databases and APIs reliably, handles access control properly if you configure it, and does not require prompt iteration to maintain. The limits are visual flexibility and custom logic. **Airtable** with extensions covers a significant range of intake forms and simple workflow tools. It is spreadsheet-adjacent, which means your team already understands the mental model. The limits are around custom logic and more complex workflows. **AI builders (Lovable, Bolt, Base44)** are viable for internal tools where the data model is simple and the user count is small. The practical floor: build explicitly, audit the access control before you go live, and test edge cases before you hand it to the team. Do not assume the tool covered the security implications by default. **Managed development** is the right answer when the internal tool is actually a business-critical system. A tool that your operations team depends on to process orders, manage clients, or run financial operations is not a "quick internal tool" - it is core infrastructure. The build approach should match the criticality. --- ## Where Most Internal Tool Builds Fail Not in the technology. In the requirements. The team knows how the process currently works. They describe it to the tool - or to the developer, or to the AI builder - in terms of the current process. The tool builds what they described. Three months later, the process has changed slightly. The tool does not match the new process. The workarounds accumulate. The team starts keeping a parallel spreadsheet for the cases the tool does not handle. The internal tool is technically running but the team is doing half the work in the tool and half in the spreadsheet. This is not a technology failure. It is a requirements failure. The tool was built to a snapshot of the process at a point in time, without considering that the process would evolve or that edge cases would appear once the team started using it in real conditions. The fix is simple: before building anything, map the process with the people who will use the tool. Not just the happy path. The exceptions, the edge cases, the things that go wrong and need to be corrected, the decisions that require judgment rather than automation. Build for that version of the process, not the idealized version. The internal tool that actually gets used is the one that handles the cases the team actually encounters. The one that only handles the happy path is the one that gets worked around. --- # https://getcreatr.com/build-inventory-management-app-without-code # How to Build an Inventory Management App Without Code (Until Two People Sell the Last Unit) Build an inventory management app without code and handle stock correctly **The short version:** building the product table and low-stock alert is the easy part - the part that breaks is making the count stay correct when two sales hit the same SKU at once. Here is the entire happy-path inventory app, and you can build it before lunch: a `Products` table with a name, SKU, and quantity. A form to add stock. A view that flags any row where quantity drops below a threshold. Maybe an email when something runs low. That is a real, useful tool. The Google Workspace blog has documented building exactly this kind of low-stock tracker on a spreadsheet. For a single person counting stock in one room, it works. It stops working the moment two things happen at once. Two customers buy the last unit in the same second. A warehouse transfer and a sale touch the same SKU. A Shopify webhook and a manual edit land together. Inventory is not a screens problem. It is a data-correctness problem, and the easy 60-70% does nothing to solve it. | Requirement | What the easy/no-code version does | What production actually needs | | --- | --- | --- | | Decrement stock on a sale | Read the quantity, subtract one, write it back | Atomic conditional decrement so two sales never oversell the last unit | | Barcode entry | A text field you type the number into | A scanner pipeline that resolves UPC to SKU and registers each scan instantly | | Multiple warehouses | A location column on the product row | A stock record per product per location with atomic transfers | | Keep Shopify or POS in step | A one-way Zapier zap pushing quantity out | Two-way sync that reconciles conflicts and never loops | | Source of truth | Whichever system was edited last | One system owns the number with an explicit conflict-winner rule | | Concurrency under load | Works fine in a one-person demo | Holds correct counts when many writes land at once | --- ## The 60-70%: A Product Table That Counts Down The part the no-code tools are good at: - A products table with quantities, prices, suppliers, and categories. - Forms to receive stock and record sales, each adjusting the quantity field. - A low-stock view - filter where `quantity < reorder_point` - and an automated alert. - A dashboard showing total units, value on hand, and what is running out. This is genuinely worth building. If you run a small operation where one person touches inventory at a time, do not over-build past it. The trap is assuming this layer scales by adding more screens. It does not, because the thing that breaks next lives underneath the screens, in how the count actually changes. We wrote about this exact ceiling in [no-code app scaling problems](/no-code-app-scaling-problems): the prototype that works at ten records per day quietly corrupts itself at a thousand, and the reason is almost always concurrency. --- ## The Race Condition: Two People, One Last Unit This is the bug that defines inventory software. Walk through it slowly. You have 1 unit of a product. Two customers check out at the same instant. Both requests read the current quantity: 1. Both see "yes, stock available." Both compute the new value: 1 minus 1, which is 0. Both write 0. You just sold two units of a product you had one of. This is the classic lost-update problem, and it is well documented - when two transactions read the same quantity and both decrement it, the second write silently overwrites the first instead of stacking on top of it. The reason most no-code tools fall into this is that "subtract one from quantity" is usually implemented as read-then-write: fetch the row, compute the new number in the automation, save it back. Between the read and the write, anything can happen. Under any real concurrency, it will. The correct fix is to never read-then-write. You do the decrement atomically, in a single operation the database guarantees no other write can interleave with. There is a [good walkthrough of atomic increment/decrement in SQL and the locking involved](https://blog.pjam.me/posts/atomic-operations-in-sql/) that shows the difference in practice. Two patterns matter: - **Atomic update:** `UPDATE products SET qty = qty - 1 WHERE id = ? AND qty >= 1`. The database does the subtraction, and the `qty >= 1` guard means if stock is already gone, zero rows update and you know the sale failed. No interleaving, no oversell. - **Row locking:** wrap the read and write in a transaction and lock the row with `SELECT ... FOR UPDATE` so the second buyer waits for the first to finish. Postgres documents this in its [explicit locking guide](https://www.postgresql.org/docs/current/explicit-locking.html). Ask of any no-code tool you are evaluating: can your automation do a conditional atomic decrement, or does it read the value and write it back? If it is read-then-write, you will oversell. Not might - will, the first time you get two orders at once. --- ## Barcodes Are Not Just A Text Field The demo version of barcode support is a text input you type a number into. Real barcode scanning is a different problem. A USB scanner acts like a keyboard and "types" the code plus an Enter key, so it can work with a plain form - but only if focus is in the right field and nothing eats the Enter. Camera-based scanning in a browser is harder: it needs a scanning library, good handling of poor lighting and damaged labels, and a way to confirm the scan without making someone squint at the screen. Then there is the matching problem - a scanned UPC has to resolve to the right product even when one physical item maps to several SKUs, or several barcodes map to one product. There is also the speed expectation. A person receiving a pallet scans hundreds of items in a few minutes and expects each scan to register instantly, increment the right count, and surface an error the moment a code does not match. A form that takes half a second to save and clears focus after every entry feels fine in a demo and falls apart at that pace. None of this is hard to fake with one item in front of a camera, and all of it is the actual work on a busy receiving dock. --- ## Multi-Location Is Not "Add a Location Column" The moment you have two warehouses, your data model changes shape, and people get this wrong by adding a `location` column to the product row. Quantity is no longer a property of a product. It is a property of a product at a location. You need a separate stock-level record per product per location, transfers that decrement one location and increment another as a single atomic move, and rules for which location fulfills a given order. Shopify, which has solved this at scale, makes the constraint explicit in its [multi-location inventory docs](https://help.shopify.com/en/manual/products/inventory/setup/multi-managed-inventory): each location's inventory is tracked independently and cannot be pooled or shared across locations. If your no-code model has one quantity per product, retrofitting multi-location later usually means rebuilding the schema and every automation that touched it. --- ## Two-Way Sync Is Where Zapier Quietly Drifts This is the integration that breaks slowly enough that you do not notice until the numbers are wrong everywhere. The seductive shortcut is a one-way Zapier zap: when something changes in your app, push the new quantity to Shopify. It demos perfectly. Then a sale happens on Shopify itself, or in your POS, or a return gets processed, and that change never flows back. Your app and your store now disagree, and the gap widens with every transaction the zap does not see. Real inventory needs two-way sync, and two-way sync needs more than two zaps pointed at each other - point them carelessly and an update on one side triggers an update on the other, which triggers the first again, in a loop. Doing it correctly means writing to a real inventory endpoint and reconciling conflicts deliberately. Shopify exposes this through its [inventory level API](https://shopify.dev/docs/api/admin-rest/latest/resources/inventorylevel), where you adjust available quantity at a specific location rather than overwriting a global number - and you have to decide, explicitly, which system wins when two of them disagree about the same SKU. Most no-code "integrations" are the one-way version, and the drift is invisible right up until you oversell something you thought you had fifty of. This is the same class of failure we covered for storefronts in [building an ecommerce app without code](/build-ecommerce-app-without-code): the catalog and checkout are easy, and the source-of-truth question is the one that decides whether the whole thing holds together. --- ## What To Decide Before You Build Inventory rewards getting the model right early and punishes fixing it late. Before you build screens: 1. **Pin down concurrency first.** Confirm your tool can do an atomic, conditional decrement - not read-then-write. If it cannot, you have a hard ceiling on order volume, and you should know it now. 2. **Decide the source of truth.** One system owns the real number. Everything else syncs to it, two-way, with an explicit rule for who wins a conflict. Never one-way. 3. **Model location into the schema from day one** if multi-location is even plausible. Stock is product-at-location, not product. Retrofitting this is a rebuild. The product table and the low-stock alert are the easy, honest 60-70%, and for a small single-operator setup they may be all you ever need. The atomic decrements, the real barcode pipeline, the per-location stock model, and the reconciling two-way sync are the 30-40% that decides whether your counts stay true when the business gets busy. That is the part where no-code tools tend to stop, and it is the part where a platform like [Creatr](https://getcreatr.com)'s DeepBuild - which gives you a real database with transactions rather than a spreadsheet pretending to be one - earns its place. Either way: solve correctness before you scale volume, not after the first oversell. --- # https://getcreatr.com/build-job-board-without-code # How to Build a Job Board Without Code in 2026 How to build a job board without code in 2026 **The short version:** wiring Airtable, Webflow, and a sync tool into a browsable board is the easy part - the part that breaks is the billing, auth, and data correctness that turn a directory into an actual job board business. The standard no-code job board is three tools wired together: Airtable holds the listings, Webflow displays them, and a sync tool like Whalesync or Zapier moves rows from one to the other. You can have a browsable board with a submission form live in a weekend. This part genuinely works, and it is why every "build a job board without code" tutorial stops here. The problem is that a browsable board with a form is not a job board business. It is a directory. The thing that makes a job board a product - employers paying to post, applicants applying with real profiles, listings that stay correct, pages that actually rank - is the 30-40% that the three-tool stack was never built to do. This post walks through both halves: the part that is easy, and the part where the easy stack runs out of road. | Requirement | What the easy/no-code version does | What production actually needs | | --- | --- | --- | | Employers paying to post | A manual checkbox you flip after a transfer | Stripe billing with subscription and entitlement lifecycle | | Applicant accounts | A one-off form or email button | Real auth, sessions, and per-user authorization | | Resume files | Uploads in a public bucket | Per-user storage with signed, expiring, access-checked URLs | | Listing correctness | Sync lag between Airtable and Webflow | Current, deduplicated data the page can be trusted to show | | Notification email | A free relay on a form plugin | Authenticated sending domain with SPF, DKIM, and DMARC | | Programmatic SEO pages | Templated pages a builder emits | Split sitemaps, correct canonicals, and passing Core Web Vitals | --- ## The 60-70% the Standard Stack Handles Well Start with what works, because it really does work. [Airtable](https://airtable.com/) is a reasonable database for a few thousand listings. Each row is a job: title, company, location, salary band, tags, a description field. Webflow is a reasonable front end: a CMS Collection mirrors the Airtable schema, a Collection List template renders the cards, and filters let visitors narrow by category. [Whalesync](https://www.whalesync.com/connect/airtable-webflow) keeps the two in step with a real-time, two-way sync, so when you edit a row in Airtable the published page updates without a manual export. The submission side is just as quick. An Airtable form, a Typeform, or a Webflow native form drops a new record into the table. You review it, flip a "published" checkbox, and the sync pushes it live. For a curated niche board where you personally approve every listing, this is a legitimate operating model. Plenty of small boards run on exactly this and make money. So the easy version is real. The trouble starts the moment you want the board to run without you in the middle of every transaction - which is the moment it becomes a two-sided system rather than a directory. The same jump shows up in any [two-sided marketplace build](/build-marketplace-app-without-code): the demo validates, then the systems that have to interact correctly start fighting each other. --- ## Hard Part 1: Employer Accounts and Paid Listings The first wall is billing. A directory has one user: you. A job board has two sides, and one of them needs to pay you. Concretely, an employer needs an account, a way to post a listing tied to that account, and a checkout that charges them - a flat fee per post, a featured-listing upsell, or a subscription for unlimited posts. None of Airtable, Webflow, or the sync tool models "this company owns these three listings and has an active subscription." You can fake account state with a status field, but you cannot fake the payment flow. A real implementation needs Stripe, and not just a Payment Link. A per-post charge is a one-time payment, but "featured for 30 days" is a timed entitlement that has to expire, and "unlimited posts while subscribed" is a subscription whose lapse has to revoke posting rights. That last case is the one that breaks naive builds: when a card declines and the subscription goes past_due, your board has to stop accepting new listings from that employer and ideally unpublish the old ones. [Stripe's subscriptions documentation](https://docs.stripe.com/billing/subscriptions/overview) describes the lifecycle and the webhook events - `customer.subscription.updated`, `invoice.payment_failed` - that you have to handle for that to work. If you also want featured slots metered by impressions or applications, [Stripe's usage-based billing](https://docs.stripe.com/billing/subscriptions/usage-based) requires a backing Meter per metered price as of recent API versions; the old usage-records approach is gone. This is the part no sync tool reaches. Billing state lives in Stripe, posting permissions depend on billing state, and the gap between "row in Airtable" and "employer with an active, non-delinquent subscription" is exactly the gap between a directory and a product. --- ## Hard Part 2: Applicant Auth and Resume Uploads The other side of the board is applicants, and they bring their own hard requirement: identity. If applicants apply by emailing the company or filling a one-off form, you have no product - you have a contact button. A real board lets an applicant create an account, build a profile, upload a resume, and see the jobs they have applied to. That means authentication: real sessions, password resets, and crucially, an authorization boundary so applicant A can never read applicant B's resume or application history. That boundary is the single most common security failure in stitched-together apps. Resume files are personal data. If they live in a public bucket behind guessable URLs, anyone can enumerate them, and [broken access control sits at the top of the OWASP Top 10](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/) precisely because this mistake is so easy to make and so easy to miss. Webflow plus a form plugin gives you no model for "this file belongs to this user and only this user may fetch it." You need per-user storage with signed, expiring URLs and access checks on every read - the kind of object-level enforcement the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) spells out. Auth and file privacy are not features you bolt onto a directory. They are a layer the three-tool stack does not have a place to put. --- ## Hard Part 3: Data Quality and the Sync-Lag Bug Here is a failure that looks like a glitch and is actually an architecture problem. The Airtable-to-Webflow sync is eventually consistent. There is a window - usually seconds, sometimes longer under load - where the two systems disagree. For most content that does not matter. For a job board it produces a specific, embarrassing bug: an employer marks a role as filled, your applicant clicks the still-live Webflow card, and applies to a job that no longer exists. The data is correct in Airtable and wrong on the page that the user is looking at. That is not a cosmetic issue; it is a data-correctness bug baked into the two-database design. The problem compounds if you ingest listings rather than hand-curate them. The instant you scrape or aggregate jobs from other sources, you inherit deduplication: the same role posted to three sites becomes three rows unless you have a matching key and a merge rule. Airtable has no native dedup; you end up writing automations to hash titles and companies, and they will miss the near-duplicates ("Sr. Engineer" vs "Senior Engineer"). A board that shows the same job four times reads as spam to users and, increasingly, to Google. Data quality is the unglamorous core of a job board. The standard stack gives you storage and display but nothing that guarantees the displayed data is current, unique, and true. --- ## Hard Part 4: Email That Actually Reaches the Inbox A job board runs on transactional email: "your listing is live," "you have a new applicant," "your post expires tomorrow." At low volume any tool sends these fine. At volume, deliverability becomes its own discipline. The hard numbers are set by the mailbox providers. Since February 2024, [Google's bulk sender guidelines](https://support.google.com/a/answer/14229414) require any domain sending 5,000 or more messages a day to personal Gmail addresses to authenticate with SPF and DKIM, publish a DMARC record, keep spam complaints under 0.3%, and offer one-click unsubscribe. Gmail began ramping enforcement in late 2025, so non-compliant mail now gets delayed or rejected outright rather than just filtered. Yahoo adopted the same rules. A board that crosses 5,000 daily emails - not a high bar once you have applicants and employers both getting notifications - has to run on a properly authenticated sending domain, not a free-tier relay attached to a form plugin. None of Airtable, Webflow, or Whalesync handles SPF, DKIM, DMARC alignment, or bounce and complaint suppression. That is a dedicated email provider plus DNS configuration plus list hygiene, and getting it wrong means your "you have a new applicant" notifications quietly stop arriving. --- ## Hard Part 5: Programmatic SEO Pages That Actually Index The traffic engine for most job boards is programmatic SEO: a page per role, per city, per category, generated from the database. Done right, it is thousands of long-tail pages that rank. Done wrong, it is thousands of pages Google renders, considers, and declines to index. Three things separate the two outcomes, and all three are technical: **Sitemaps at scale.** [Google's sitemap documentation](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) caps a single sitemap at 50,000 URLs or 50MB uncompressed; beyond that you must split files and reference them from a [sitemap index file](https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps). A 200,000-page board with one oversized sitemap is a board Google partially ignores. **Canonicals.** Programmatic pages overlap constantly - "remote python jobs" and "python jobs remote" can render near-identical sets. Without correct [canonical URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls), Google treats them as duplicates, picks one itself, and may pick the wrong one. At scale, weak canonicalization is what turns a content library into a thin-content liability. **Core Web Vitals.** Thousands of slow, layout-shifting pages get crawled grudgingly. [Google's Core Web Vitals guidance](https://developers.google.com/search/docs/appearance/core-web-vitals) defines the LCP, INP, and CLS thresholds that a page-builder template, loaded with embeds and unoptimized images, frequently misses. There is also a hard ceiling worth naming: [Webflow's CMS plans cap collection items](https://help.webflow.com/hc/en-us/articles/33961370432275-Dynamic-content-limits) - on the order of a couple thousand on the CMS plan and up to roughly 20,000 on the higher tier. A programmatic board that wants tens of thousands of indexed pages outgrows the CMS that was rendering them, which is the same wall described in [no-code scaling problems](/no-code-app-scaling-problems): the tool that got you to launch becomes the thing you have to migrate off of. --- ## So What Should You Actually Build? The honest decision tree is short. If you are running a curated, single-niche board where you approve every listing and volume stays low, the Airtable plus Webflow plus Whalesync stack is the right call. Ship it this weekend, charge for posts manually, and do not over-build. The moment any of these become true - employers self-serve and pay through Stripe, applicants have accounts and upload resumes, listings are ingested rather than hand-added, email volume crosses a few thousand a day, or programmatic pages are your growth plan - you have left directory territory. You now need a real database with relations and access control, real auth, a billing integration with webhook handling, and SEO infrastructure that produces indexable pages. That is a web application, and stitching it from no-code tools means spending more time fighting the sync lag and the auth gaps than you would building the thing properly. This is the gap [Creatr's DeepBuild](https://getcreatr.com/) was built to close: it ships the two-sided system - auth, roles, Stripe billing, correct data, indexable pages - as one production web app rather than three tools that disagree with each other at the seams. Wherever you land, decide based on which half of the board you are actually building. The first 60-70% is a weekend. The last 30-40% is the business. --- # https://getcreatr.com/build-marketplace-app-without-code # How to Build a Two-Sided Marketplace Without Code in 2026 **The short version:** A marketplace is four interlocking systems - identity and trust, matching, payments, and communication - not one app. Low-stakes marketplaces (sub-$100 transactions) can be prototyped in Lovable or Bolt and extended by a developer. The hard part AI builders get wrong: database-level role isolation, Stripe Connect split payments with proper holds, dispute and refund paths, and matching that scales past the demo. Design the schema, payment flow, and trust gates before touching a tool, or use a managed build. How to build a marketplace app without code in 2026 A marketplace is the most-requested app type from non-technical founders and the one where AI builders fail most visibly. The failure is not random. Marketplaces are complex in a specific way - they require systems that interact with each other correctly, and the interactions are exactly what AI tools handle badly. Here is the concrete version of that complexity: a marketplace has at least two user types. Each user type has different views of the same data. Money flows from one side to the other, with your platform taking a cut, in a sequence that has to be correct even when individual steps fail. Trust between strangers has to be established before a transaction happens. The transaction has to produce the right state changes on both sides when it completes, and different state changes when it fails. None of these are hard to describe. They are hard to implement correctly without the explicit architectural decisions that give each piece its correct structure before any code is written. This post covers what those decisions are and how to build around them - whether you use an AI tool, a managed build service, or some combination. --- ## The Four Systems Every Marketplace Requires Before touching any tool, understand what you are actually building. A marketplace is not one app. It is four systems that need to work together. **Identity and trust.** Two strangers need to transact. Before money changes hands, each side needs to know enough about the other to feel comfortable. This means user profiles, verification flows, and in most marketplaces, some form of review or rating system. The identity system determines what each user type can see and do, and it establishes the trust signals that make transactions possible. **Matching and discovery.** The buyer needs to find the right seller, service, or product. The matching system is the mechanism that makes this possible - search, filters, recommended results, or an algorithmic matching engine. For simple marketplaces, this is a keyword search with category filters. For complex marketplaces (event production, professional services, specialized logistics), the matching logic is the core of the product's value. **Transaction and payment.** Money moves from buyer to platform to seller in a specific sequence: the buyer pays, the platform holds the funds, the transaction completes, the platform releases the seller's portion minus the fee. This is not a single payment - it is a payment flow with a hold state, a release trigger, and error handling for the cases where the transaction does not complete normally. **Communication.** Buyer and seller need to coordinate before, during, and after the transaction. In some marketplaces this happens outside the platform. In most marketplaces worth building, keeping communication on-platform is essential - it is the mechanism through which dispute resolution works and the way the platform maintains visibility into the relationship that its fee is supporting. These four systems are not independent. Changes to the identity system affect what the matching system can filter on. Changes to the transaction system affect what state the communication system needs to track. The interdependencies are exactly what makes building a marketplace harder than building a single-user app, and exactly what makes it harder to build incrementally through prompt iteration. --- ## What AI Builders Get Wrong About Marketplaces The failure mode with AI builders and marketplaces is consistent enough to describe as a pattern. The first prompt produces something that looks like a marketplace. There are two user types. There are listings. There is a way to contact a seller. It looks right in the demo. The founder shows it to potential users and the concept validates. The problems appear when the build goes deeper. **User role isolation breaks.** The AI builder creates two user types, but the data isolation between them is application-level - the code shows each user their own view of the data, but the database has no enforcement of who is allowed to see which records. A buyer can be made to appear as a seller through API manipulation. An admin can be impersonated. The role boundaries that look solid in the UI are not enforced at the data layer. **The payment split is wrong.** Connected accounts in Stripe - the mechanism that allows your platform to take a fee while sending the remainder to a seller - requires specific configuration that most AI builders do not implement correctly by default. The common output is either a direct payment to the seller (platform takes no fee) or a payment to the platform with a manual transfer to the seller (which breaks the held-funds model and creates tax complexity). The split payment flow with proper holds requires explicit implementation. **Dispute resolution has no mechanism.** When a transaction fails - the service was not delivered, the product was not as described, there was a miscommunication - the marketplace needs a path to resolve it. AI builders produce transaction flows for the happy path. The dispute path, the cancellation path, the partial-refund path are typically missing. In a live marketplace with real users, these missing paths are the ones that generate negative reviews and support requests. **The matching logic does not scale.** The search and filter system that works for ten listings does not work the same way for ten thousand. The AI builder optimizes for the demonstration case. The production case involves database queries that need indices, search logic that needs to be structured for performance, and filtering that needs to account for availability, location, rating, and category simultaneously. --- ## The Technical Decisions That Determine Whether Your Marketplace Works These decisions need to be made before any tool starts building. Changing them after the fact is expensive. ### Decision 1: Database Schema for Multi-Tenancy A marketplace has multiple user types, each with access to specific records. The schema needs to enforce this at the database level - not just filter it at the application level. The key entities and their relationships: - Users with a role field (buyer, seller, admin) - Listings owned by sellers - Bookings or orders that connect a buyer to a listing - Reviews attached to completed orders - Messages threaded on an order or inquiry The foreign key relationships between these entities determine what queries are possible. If a booking has foreign keys to both the buyer user ID and the seller listing ID, you can query all bookings for a buyer, all bookings for a seller, and all bookings for a specific listing efficiently. If the schema was generated by an AI tool without these relationships being specified, the relationships may be implicit (stored as JSON or text) rather than enforced - which means joins are expensive and consistency is not guaranteed. ### Decision 2: Payment Architecture Marketplace payments have three actors: buyer, platform, seller. The technical implementation of the fee split matters. **Stripe Connect** is the standard for marketplace payments. There are two models: Standard Connect: Each seller has their own Stripe account, connected to your platform. Payments go directly to the seller's account. You collect your fee through Stripe's application fee mechanism. The seller handles their own tax reporting for the funds they receive. Express or Custom Connect: Funds flow through your platform's Stripe account. You collect the full payment, take your fee, and transfer the remainder to the seller. You have more control over the UX and the timing of transfers, but more compliance responsibility. The choice between these has legal, tax, and operational implications. An AI builder will implement whichever one its training data suggested without asking you which model fits your marketplace. The right answer depends on your geography, your transaction volume targets, and how much compliance complexity you want to own. Once held funds, payouts, and KYC on your sellers are in scope, you are closer to a payments product than a listings site - the same territory we map out in [building a fintech app without code](/how-to-build-fintech-app-without-code). ### Decision 3: Trust Architecture What does a user need to do to be allowed to transact? The answer varies by marketplace type: - Identity verification (government ID, for high-stakes transactions) - Email verification (minimum bar for any real product) - Phone verification (step above email, common for services marketplaces) - Profile completeness (photo, bio, minimum reviews) - Manual review by an admin before a listing goes live The trust architecture determines the onboarding flow, the listing creation flow, and the transaction initiation flow. If a seller cannot list until their identity is verified, the verification system is a gate on the entire marketplace functioning. Building this as an afterthought means retrofitting a gate into flows that were designed without one. ### Decision 4: Message Threading Model Messages in a marketplace happen in one of three contexts: - Pre-transaction inquiry (buyer asks seller a question before booking) - Transaction coordination (buyer and seller coordinate on an active booking) - Post-transaction dispute (something went wrong and it needs to be resolved) These are different contexts with different participants (the admin may need to be included in dispute messages) and different persistence requirements (dispute messages may need to be retained for regulatory reasons). An AI builder will generate a generic messaging system. The context-specificity of marketplace messages is the part that usually needs explicit design. If messaging grows into a feed, profiles, and notifications, you are adding a social layer on top - which has its own real-time and moderation demands covered in [building a social app without code](/how-to-build-social-app-without-code). --- ## What Building Actually Looks Like Given the complexity above, the honest picture of what happens when non-technical founders try to build a marketplace with AI tools: **Simple marketplaces with low transaction stakes can be built with AI tools.** A local services marketplace - dog walkers, tutors, home cleaners - where the average transaction is under $100 and the primary risk is a bad experience rather than financial loss can be prototyped in Lovable or Bolt and extended by a developer. The security issues need to be addressed, the payment flow needs to be reviewed, but the base structure can come from an AI tool. **Complex marketplaces need architectural design before any tool is involved.** A B2B services marketplace, a professional platform with verification requirements, or anything where the average transaction is over $1,000 requires the database schema, payment architecture, and trust system to be designed explicitly before any tool starts producing code. Starting with a prompt and iterating toward these decisions produces the technical debt pattern - the app looks right from the outside and requires expensive structural changes when the real requirements surface. **The most successful marketplace builds we have seen follow this sequence:** 1. Define the four systems (identity, matching, transactions, communication) in writing before touching any tool 2. Document the data model - every entity, every relationship, every permission boundary 3. Document the payment flow - every step, every failure case, every state change 4. Build from the specification, not from improvised prompting The specification does not need to be a formal technical document. It can be a series of answers to the questions above, written clearly enough that the tool (or developer) building from it does not need to make assumptions. The marketplace that succeeds past the prototype is the one where the hard questions were answered before the build started - not the one that was built fastest and discovered the hard questions when real users arrived. --- ## A Real Example: What Got Built for Tarbot Tarbot is an Israeli event production marketplace - a multi-sided platform connecting event producers with vendors across catering, lighting, staging, photography, and logistics. The complexity: multiple vendor categories with different service types, a producer dashboard for managing event logistics, a vendor portal for managing availability and bookings, an AI-powered matching engine that recommends vendors based on event type and producer history, and a WhatsApp integration because Israeli event professionals communicate primarily through WhatsApp rather than email. This was not buildable through prompt iteration. The data model had seven entity types with complex many-to-many relationships. The matching engine required a search layer with weighted scoring across multiple attributes. The WhatsApp integration required server-side message handling with webhook validation. The payment flow required split payments across multiple vendor contracts within a single event. It was built in five days. Not by prompt iteration in an AI builder, but by designing the specification first - the data model, the permission system, the payment architecture, the integration requirements - and then building from the specification with an engineering process that owned the full stack. The result was a production marketplace with live vendor and producer accounts, real transactions, and real events. Not a prototype. Not a demo. A product. The five days happened because the specification was complete before building started. The product complexity was addressed in the design phase, where changing a decision costs nothing, rather than in the build phase, where changing a decision costs the time it takes to undo and rebuild everything built on top of it. --- # https://getcreatr.com/build-membership-platform-without-code # How to Build a Membership Platform Without Code in 2026 **The short version:** First decide if you need a membership site (gating content) or a membership app (tier changes what users can do). For sites, Kajabi, Circle, or Memberstack already do the job. For apps, use Supabase for auth and Stripe Billing for subscriptions, with an AI builder like Lovable for the UI. The hard part is the Stripe webhook handler that keeps your database in sync and server-side tier enforcement - client-side checks are cosmetic. Bring a spec of exactly what each tier permits and what happens when payment fails. How to build a membership platform without code 2026 Most articles about building a membership platform point you toward the same handful of tools. What they skip is the distinction that determines whether those tools will actually solve your problem - or leave you six months in, rebuilding from scratch. There are two fundamentally different things people call a "membership platform." One is a membership site. The other is a membership app. They share a billing model but almost nothing else. Picking the wrong category of tooling is the most expensive mistake you can make early on. ## Membership Site vs. Membership App A membership **site** gates content behind a paywall. Blog posts, video courses, PDF downloads, community forums - access depends on whether the user has an active subscription. The product is the content itself. The software's job is to check "does this person have a valid plan" before showing a page. A membership **app** changes what users can **do** based on their tier. Free users get three projects. Pro users get unlimited. Enterprise users get an admin dashboard, seat management, and SSO. The product is the functionality. Tier isn't a key that unlocks a door - it's a parameter that runs through every feature in the product. If you conflate these two, you'll spend weeks trying to force a content platform to behave like a SaaS product, and eventually give up. ## Membership Sites: The Right Tools Already Exist If you're building a content membership - courses, coaching, a community - the tooling is mature and genuinely good. [Kajabi](https://www.kajabi.com) is the most complete option for knowledge businesses. You get course hosting, drip content, a community, email marketing, and checkout in one product. The tradeoff is cost and some inflexibility on how things look. If your revenue model is "people pay to access my expertise," Kajabi handles it. [Circle](https://circle.so) is purpose-built for community. It supports discussions, direct messaging, live events, and course hosting. It integrates with Stripe for payments and has a mobile app builder. If the core product is the community - not a course library - Circle is the right fit. [Memberstack](https://memberstack.com) sits closer to the infrastructure layer. It adds authentication, payments, and content gating to an existing site built in Webflow, WordPress, or custom code. You keep full control of your design and add membership logic on top. Good choice if you already have a site and want to layer in subscriptions without rebuilding. Each of these tools is excellent at what it does. If your use case fits one of them, use it. The problems start when you need something they weren't designed for. ## Where Content Tools Break Down These platforms assume the membership logic lives at the content layer - which page you can view, which forum you can post in. They don't assume the membership logic lives inside the product itself. If you're building any of the following, you'll hit walls quickly: **SaaS with tiered feature sets.** Free tier gets read access. Pro tier gets write access plus API keys. Enterprise tier gets SSO, audit logs, and a dedicated subdomain. None of this is "can you see this page" - it's "what does this button do for your account specifically." Content platforms can't model this cleanly. **A directory or marketplace with verified-member access.** Members have profiles, post listings, search other members, and request introductions. The "content" is dynamic and member-generated. You're not gating static pages - you're controlling what each user can create and consume in real time. **A professional network where members connect.** Profiles, connection requests, direct messaging, member-only events - this is a product with state, relationships, and user-generated content. The subscription determines your tier in the network, not which static articles you can read. That connection graph and activity feed is a social layer, with its own real-time and moderation problems - we cover them in [building a social app without code](/how-to-build-social-app-without-code). **A B2B tool with seat-based billing.** A company buys five seats. An admin at the company manages who holds those seats. Each seat holder gets access to the company's workspace. This is multi-tenancy with a subscription layer on top. No content tool ships this. ## What a Real Membership App Actually Requires Building a membership app means solving several problems at the infrastructure level, not the content level. **Authentication and session management.** Users need accounts, login, logout, password reset, and optionally social sign-in. [Supabase](https://supabase.com) gives you this out of the box with a Postgres database underneath - every user row is linked to an auth record, and you can store tier, plan, and custom fields directly on the profile. **Role and tier-based access control.** Every protected action in the product needs to check the user's current plan. This isn't a middleware flag you add once - it's logic that runs in every query, every API call, every server action that touches restricted functionality. The tier needs to be in the database and checked server-side. Client-side checks are cosmetic. A determined free user will always find the unprotected endpoint if the backend doesn't enforce the rules. **Subscription billing with Stripe.** [Stripe Billing](https://stripe.com/billing) handles subscriptions, upgrades, downgrades, free trials, and failed payment recovery (dunning). The non-trivial part is not the initial checkout - it's the webhook handler. When Stripe fires `customer.subscription.updated` or `invoice.payment_failed`, your database needs to reflect that change immediately. Your access control logic reads from the database, not from Stripe directly. If the webhook handler breaks, users who cancelled still have access, and users who upgraded don't. **Usage tracking for metered features.** If your product has limits - five AI runs per month on free, unlimited on pro - you need to count usage per user per billing period and enforce the limit. This is a counter in your database, reset on each billing cycle, checked before the action executes. **An admin dashboard.** You need to see who your members are, what plan they're on, when they signed up, and when their next billing date is. You need to be able to manually change a plan, issue a refund, or suspend an account. If you're building on Supabase, a basic admin view on top of the users table covers most of this. ## Where AI Builders Help - and Where They Stop AI builders like [Lovable](https://lovable.dev) have gotten genuinely capable. You can describe a product and get a working prototype with a pricing page, sign-up flow, and dashboard shell in an afternoon. That's real value - it dramatically compresses the time from idea to something you can show. The gap shows up at the integration layer. Generating a pricing table is easy. Wiring the Stripe checkout so that a completed payment writes the correct plan to the user's database row - and then having every protected feature in the app actually read from that row - is where precision matters. Stripe's webhook events need to be verified, parsed correctly, and mapped to database updates without race conditions. Tier-based access control needs to be enforced on the server, not just in the UI. These are not impossible to get right with an AI builder, but they require careful specification and verification at each step. The founders who succeed with AI builders on membership apps are the ones who arrive with a clear spec - not just "I want tiers" but exactly what each tier permits, exactly what events should trigger a plan change, and exactly what the failure path looks like when a payment fails. ## Three Decisions That Shape Everything Before you write a line of code or prompt an AI builder, answer these three questions explicitly. **What does each tier get?** List the specific features and limits per plan. Not "more features" - actual feature names, actual numbers. Free: 3 projects, read-only API. Pro: unlimited projects, read-write API, priority support. Enterprise: Pro plus SSO, audit logs, custom domain. This list becomes your access control matrix. **What triggers an upgrade?** Is it a paywall when the user hits a limit? A CTA when they try to use a locked feature? Proactive in-app prompts based on usage? This determines your upgrade conversion architecture as much as your billing logic. **What happens when a payment fails?** Does the user immediately lose access? Do they get a grace period? Which features are degraded vs. fully locked? Stripe's dunning emails can recover a large share of failed payments if you configure them, but you still need a defined state for accounts in the dunning window. Getting these three answers written down - not in your head, in a document - is the work that determines whether the build goes smoothly or turns into six weeks of back-and-forth with an AI builder that keeps regenerating the same ambiguities. The tooling in 2026 is genuinely capable of producing a working membership app without a dedicated engineering team. The constraint isn't the tools. It's the quality of the specification you bring to them. --- # https://getcreatr.com/build-online-course-platform-without-code # How to Build an Online Course Platform Without Code How to build an online course platform or LMS without code **The short version:** Listing videos and taking a payment is easy; the hard part is secure content delivery, accurate progress tracking, defensible certificates, and dunning when a payment fails. You can build something that looks like an online course platform in an afternoon. A page that lists courses, a course page that lists lessons, a video player, a checkout button. Drop a few MP4 files in, wire up Stripe, and you have a demo that works. The demo is the easy 60-70% of the product. It is also the part that no longer differentiates anything, because every AI builder and no-code template ships it for free. The hard 30-40% is course-delivery mechanics: making sure paid video can't be ripped, that progress tracking is accurate enough to issue a certificate someone will put on LinkedIn, that drip and cohort gating fire on the right day, that quizzes grade correctly, and that a failed renewal doesn't silently cut off a paying student or silently keep charging a churned one. This post is about that 30-40%. If your question is "how do I gate who gets access," that is a different problem - access control and tiers - and we covered it in [building a membership platform without code](/build-membership-platform-without-code). Here we assume access works and focus on what happens after a logged-in student hits play. | Requirement | What the easy version does | What production actually needs | | --- | --- | --- | | Video delivery | Public MP4 from a bucket | Signed, time-limited URLs plus multi-DRM | | Progress tracking | A single 'complete' boolean | Event-based tracking modeled on SCORM/xAPI | | Drip / cohort gating | All lessons unlocked at once | Per-student scheduler, correct across time zones | | Quizzes / grading | Single-answer multiple choice | Partial credit, retakes, thresholds, pools | | Certificates | A PDF with the student's name | Unique ID plus a verifiable completion record | | Payment failure | Renewal silently fails | Dunning, retries, and webhook reconciliation | ## The Part That's Actually a Template Be honest about what's solved so you don't overpay for it. Course listing, lesson ordering, a rich-text description, an upload form, a basic video player, and a Stripe checkout are commodity. Teachable, Thinkific, Kajabi, Podia, and a dozen no-code stacks do this well. If your product is "I have a course and I want to sell it," one of those hosted platforms is almost certainly the right answer, and you should stop reading and go use one. You're still here because you want something they don't do: a custom enrollment flow, a different pricing model, your own branding all the way down, a community feature wired to course progress, or a delivery model the hosted tools can't express. That's a legitimate reason to build. Just go in knowing that the part you can see in a demo is the part that was never hard. ## Secure Video Delivery Is the Existential One For a paid course, the video is the product. If a buyer can download the file and reshare it, your business has a hole in the bottom of it. This is the single most underestimated piece when people build a course platform themselves. A naive build stores MP4s in a bucket and serves them with a public URL. That URL can be copied, shared, and scraped. Hiding the `