No Code App

No-code app

You are deciding whether to build an app on a visual platform, which platform, how to model it, and where the wall is. No-code is not "the easy way" — it is a trade: you buy speed-to-first-user and pay it back in logic ceilings and metered cost. Your job is to make that trade with eyes open.

Decide the exit before you build the entrance. If you cannot describe how you would leave, you are not building an MVP — you are building a hostage.

No-code wins on speed-to-first-user — a working app in days, no deploy pipeline. That is the only thing it reliably wins. It dies on deep conditional logic and on scale economics: many-branch workflows get unmaintainable, and metering turns a $29 bill into a $400 one without warning.

Step 0: is no-code even the right tool?

Run this gate before touching any builder. If any line is a clear yes, route out — do not rationalize staying.

No-code is the right tool when ALL hold: there is a real app UI (screens + data + logic), the logic is mostly CRUD + a handful of rules, time-to-launch matters more than scale today, and you accept the platform owns your runtime. If logic is the heart of the product (pricing engine, matching algorithm, real-time anything), no-code is wrong even if the UI is simple — write code.

Pick the platform

Match the platform to the app shape, then to the billing model you will have to defend in six months. Why this order: the billing model, not the feature list, is what kills no-code projects.

Rules:

• Default to Softr for anything that is "a nice front-end over a table." Flat-rate billing means a usage spike does not become a surprise invoice.
• Reach for Bubble only when the logic genuinely needs it. Bubble can do almost anything; that power is exactly why its WU bill is hard to predict. If you pick Bubble for a simple portal you are overpaying in money and complexity.
• If you find yourself fighting the builder to express logic, that is the signal to stop and reconsider ../nextjs/SKILL.md. The builder fighting back is the migration cliff sending a postcard.

Exact tiers and numbers change — see references/platform-limits.md. Do not hardcode prices into your design; design against the metering model.

Model the data first

Tables and relations come before a single screen. Why: screens are cheap to rebuild, a wrong data model poisons every workflow and every cost estimate on top of it.

Pick the backend by logic complexity, not by familiarity:

The hybrid pattern that scales: Airtable for human data entry/admin, Xano for API logic + performance + security.

Field-type and relation discipline:

• Normalize. One entity = one table. A bookings row links to customers and classes by relation, it does not copy the customer's name and email into every booking.
• Give every field its real type (date, number, single-select), not "text for everything." Wrong types make filters and aggregations expensive or impossible later.
• Watch the 50K-record/base cap on Airtable and the fact that on Bubble every relation traversal in a workflow is WU you pay for.

Bad → Good:

Bad  — one giant "Records" table, 40 columns, status in a text field,
       customer name + email + class title all duplicated per row.
       => filtering is slow, a rename means editing every row, WU/updates balloon.

Good — customers | classes | bookings(customer→, class→, date, status:single-select)
       => rename once, filter by relation, aggregate cleanly, predictable cost.

Sketch the model in plain text before you build it:

customers: { id, name, email, phone }
classes:   { id, title, starts_at, capacity, instructor }
bookings:  { id, customer: ->customers, class: ->classes, status: [pending|paid|cancelled], created_at }
payments:  { id, booking: ->bookings, amount, provider_ref }   # via stripe

Payments in any of these flows: see ../stripe/SKILL.md.

Build logic without footguns

The metering model punishes the obvious-but-wrong way of doing things. Build defensively.

• Keep workflows shallow. A 6-level nested conditional in a visual editor is unreadable and un-debuggable. If logic gets that deep, it belongs in code (Xano function or a real backend), not in the builder canvas.
• Batch writes; never loop an API call per row. A workflow that fires one external API call per record across 2,000 rows is 2,000 metered operations — this is the #1 cause of an exploded Bubble WU bill and Glide update overage. Batch, or move the loop server-side.
• Validate server-side, not just in the UI. Client-side-only validation in a no-code app is trivially bypassed; enforce rules in the backend (Bubble backend workflow, Xano endpoint) and gate writes with privacy/permission rules.
• Push expensive aggregation to scheduled jobs, not to every page load. Recomputing a dashboard on each view multiplies reads by traffic.

Bad → Good:

Bad  — On booking confirmed: loop over all 2,000 customers, call email API per row.
       => 2,000 metered ops every run; WU/update bill spikes; rate limits hit.

Good — On booking confirmed: write one row; a scheduled batch job sends queued emails.
       => one metered write per booking; sending is amortized and rate-safe.