Short answer: use no-code when the software is mostly forms, lists, simple rules and connections between existing tools, when demand is unproven, or when the process is still changing. Build custom when the logic is the product, when per-user platform pricing will outgrow the cost of owning the application, when performance or data control matters, or when you need to own the code. Many sensible projects start on one side and move to the other deliberately.
What the terms mean
| Approach | What you work with | Who builds |
|---|---|---|
| No-code | Visual editors for pages, databases, workflows and automations | A founder, an operations person or a platform specialist |
| Low-code | Visual building plus scripts, queries or custom components where needed | A technically minded builder or a developer working faster |
| Backend services for developers | Hosted database, authentication and storage, with your own front-end code | Developers. Your application code stays yours and portable |
| Custom development | Application code in a mainstream language and framework, on infrastructure you control | Developers |
The third row is often filed under low-code but behaves differently from the first two. It removes backend chores while leaving you with ordinary code, so most of the lock-in concerns below apply to it only lightly.
What no-code and low-code platforms are good at
- Marketing sites, landing pages and waitlists. A site builder is faster, cheaper and easier for a marketer to update than a hand-coded site.
- Internal tools over existing data. Approval forms, inventory lists, simple CRMs, admin screens over a database or spreadsheet.
- Automation between tools you already use. When a form is submitted, create a record, send an email, post a message. Automation platforms do this in an afternoon.
- Simple portals. Clients log in, see their records, upload a document.
- Validation. A working first version in front of real users within weeks, for the price of a subscription. If you are at this stage, read how to test an idea before paying for development first.
- Processes that are still moving. If the workflow changes every month, the person who runs it can change the tool without raising a ticket.
A less obvious strength: the person who understands the problem builds the solution, so nothing is lost in translation. For a small internal tool, that can outweigh every technical argument.
The five ceilings
1. Logic complexity
Platforms are built around a model: records, forms, lists, triggers. Inside the model, work is fast. Outside it, such as multi-step calculations, scheduling with constraints, rules with many exceptions or anything transactional, you build workarounds from chained automations and hidden fields. These are harder to read, test and debug than the equivalent code, and few platforms offer version control or automated testing comparable to what developers rely on.
2. Performance and volume
You do not control the database, the queries or the servers. With modest data this never matters. With large tables, complex filters, heavy concurrent use or long-running background jobs, pages slow down or limits are reached, and your options are to restructure within the platform's rules or to upgrade a plan.
3. Pricing that scales with users
Many platforms charge per user, per record or per unit of workload. That is fair value for a team of ten. It looks different for a customer-facing product. An illustrative calculation, with an assumed price of $10 per external user per month:
| Users | Per month | Per year |
|---|---|---|
| 50 | $500 | $6,000 |
| 500 | $5,000 | $60,000 |
| 2,000 | $20,000 | $240,000 |
Real pricing models differ widely, and some platforms are far cheaper per external user than this. The point is the shape: platform cost grows in step with users, while the hosting cost of a custom application grows much more slowly. Put your own platform's prices into a table like this at ten times your current usage before you commit.
4. Data portability
Most platforms let you export records as CSV or through an API. Check the details: whether file attachments, relationships between tables, user accounts and change history come out too, and whether export is available on your plan. Passwords generally cannot be exported from any system, so a migration usually involves asking users to reset them.
5. Lock-in
Some platforms do not let you export the application as source code. Your data can leave; the screens, workflows and logic cannot, and would have to be rebuilt. You also depend on the vendor's pricing, feature decisions and continued existence. None of this is a reason to avoid no-code. It is a reason to know the exit before you enter, and to avoid building a business-critical system on a platform whose terms you have not read.
Custom code has lock-in too. An application written by one freelancer in an unusual framework, with no documentation and hosting in their personal account, locks you in more tightly than most platforms. The protection is the same in both cases: mainstream technology, accounts in your company's name, documentation and an exportable data model.
Side-by-side comparison
| Factor | No-code / low-code | Custom development |
|---|---|---|
| Time to first version | Days to a few weeks | Typically two to five months for a first release |
| Upfront cost | Your time, or roughly $3,000–$15,000 for a specialist build | Tens of thousands of dollars and up; see web app costs by type |
| Running cost | Subscription, often growing with users, records or usage | Hosting plus maintenance; largely independent of user count at small scale |
| Who can change it | A trained non-developer | A developer |
| Complex logic | Workarounds; hard to test | Ordinary code with tests and version control |
| Performance tuning | Limited to what the platform exposes | Full control |
| Native mobile features | Limited | Available, at the cost of a mobile build |
| Security and compliance posture | Inherited from the platform; verify it meets your requirements | Yours to design, and yours to maintain |
| Ownership | You own your data; the application lives on the platform | You own code, data and infrastructure, if the contract says so |
| Maintenance burden | Platform handles servers and updates | You or your vendor handle security updates and hosting |
The upfront figures are planning estimates, not quotes. The last row matters more than it looks. Custom software is an ongoing commitment, and for a small tool the platform taking that burden away is worth real money.
Decision table by situation
| Your situation | Better choice | Why |
|---|---|---|
| Unproven idea, limited funds, workflow is forms and lists | No-code | Evidence first. Rebuild with revenue or funding behind you |
| Internal tool for under about 30 staff, simple rules | No-code or low-code | Per-user pricing is tolerable and staff can adjust it themselves |
| Connecting two or three existing tools | Automation platform | Hours of work. Revisit if volumes or error handling become a problem |
| Process changes monthly | No-code | Software fixes a process in place. Let it settle first |
| The logic is the product: matching, pricing, scheduling, calculation | Custom | Your differentiator should not be a stack of workarounds |
| Customer-facing product expecting thousands of users | Custom, or no-code only as a validation step | Per-user pricing and performance ceilings arrive together |
| Mobile app needing offline use, background work or device features | Custom | Outside what most builders support |
| Regulated or sensitive data with specific hosting or audit requirements | Custom, or a platform you have verified against those requirements | You must be able to answer where data lives and who can access it |
| Deep two-way integration with an ERP or legacy system | Custom | Needs queues, retries, conflict rules and logging |
| Marketing website | Site builder | Custom code here is usually wasted budget |
| No-code app already working, with one specific limit | Hybrid | Replace the part that hurts; keep the rest |
The hybrid: no-code front, custom back end
The choice is not all or nothing. Several combinations work well:
- Site builder for marketing, custom code for the application. The public site lives on the main domain and the application on a subdomain. Marketing edits pages without a developer, and the application budget goes to the application.
- No-code interface over a custom API and database. The heavy logic, integrations and data live in code you own. A low-code tool supplies internal screens over it, which is an inexpensive way to get an admin panel.
- Custom product, automation platform for the edges. The product sends a webhook; an automation tool handles the chat notification, the spreadsheet row and the CRM update. Non-critical glue stays cheap and editable by non-developers.
- Custom service for one hard problem. A no-code application calls a small custom service for the calculation, document generation or integration it cannot do itself. This is often the cheapest fix for a single ceiling, and a small API and integration project in scale.
The rule that keeps a hybrid healthy: the system of record, meaning the database that holds the truth, should sit where you have full control and clean export. Interfaces around it can be replaced one at a time.
Migration path from no-code to custom
A planned migration is a normal project. An unplanned one, started the week the platform stops coping, is a rescue. The steps:
- Name the constraint. Write down what is actually failing: cost per user, a missing capability, speed, a customer requirement. If you cannot name it, you do not need to migrate yet.
- Treat the existing app as the specification. This is the great advantage of having started with no-code. The workflows are proven and the edge cases are known. Record every screen, rule and automation, then mark what is unused. Migrations are a good moment to drop features.
- Design the data model and export early. Map every table and field to the new schema. Test the export, including files and relationships, long before cut-over.
- Decide between replacing in slices and replacing at once. If the platform has an API, the new system can take over one area at a time while both share data. If not, plan a single cut-over with a rehearsal.
- Rebuild the core first. Port the workflow that carries the business. Leave peripheral automations on the automation platform if they work.
- Plan the user transition. Accounts are re-created, passwords are reset, links change. Tell users in advance and keep the old system read-only for a period.
- Run in parallel briefly, then switch off. Paying for two systems for a month is cheaper than discovering a gap with no fallback.
As a planning figure, rebuilding a proven no-code application costs about what the same scope would cost as a new custom build, minus most of the discovery and design uncertainty. The effort method in our custom software cost guide applies, with data migration as an extra line.
How to keep a no-code build migration-ready
- Keep a tidy data model: clear table names, one meaning per field, real relationships instead of copied text
- Open every platform and third-party account in your company's name
- Use your own domain from day one so links and email survive a move
- Document automations in plain language as you build them
- Test a full data export once, early, including attachments
- Check the platform's terms for export rights and notice periods on price changes
- Track platform cost per user monthly so the crossover point does not surprise you
A note on bias
BBR builds custom software, so our incentive is obvious. Our stated position on the custom software development page is the same as here: generic needs should be bought, unsettled processes should wait or use a no-code tool, and custom code is for the parts that are specific to you and central to how you operate. For startups choosing a foundation, the guide to picking an MVP stack covers where no-code fits among the other options, and our internal tools page describes when a back-office system justifies custom work.