A complete guide to how business applications get built without a developer today - from the basic terms through a comparison of the approaches to the point where no-code stops being enough. A hub for every detailed article on the subject.
Five years ago, “we need our own system” meant six months of development and a budget a small company couldn't justify. Today there are five different routes to the same result, and the differences between them are close to invisible to a non-technical person - right up until they aren't.
This guide is a hub. It works through every term floating around the subject, says honestly where each approach runs out of road, and links to a detailed article at each chapter if you want to go deeper.
1. What no-code is, and what it isn't
No-code is a way of building applications where instead of writing code you assemble ready-made, tested blocks - databases, views onto data, forms, automations. The output isn't source code but configuration, which the platform runs on your behalf.
The most common misunderstanding: no-code doesn't mean “simpler applications”. It means a different division of labour. Thinking about what the system should do and how the data relates stays with you - you just don't have to translate it into a programming language.
The second misunderstanding: no-code doesn't mean everything is possible. There are requirements no ready-made block covers. Good platforms provide an escape hatch for those (a custom automation node, a webhook, an API), so you solve one exception rather than the whole application.
In detail: What is no-code and how does it work.
2. No-code, low-code, vibe coding - three points on one axis
Three terms marketing uses interchangeably, even though they describe different things. The easiest way to keep them straight is one question: how much source code do you own and have to maintain at the end?
| No-code | Low-code | Vibe coding | |
|---|---|---|---|
| How much code you own | None | Partly | All of it |
| Who uses it | A non-technical person | A developer or advanced user | Someone who reads code |
| Maintenance | The platform | You, for your part | You, all of it |
| Suits | A business system | A system with one exception | A prototype, a one-off |
In detail: Low-code vs. no-code vs. vibe coding and No-code vs. vibe coding.
3. AI app builders: what they genuinely do
Tools like Lovable, Bolt and v0 turn one sentence into a working screen in minutes. There's nothing fake about it - they really do it and they're very good at it.
The limit shows up the following day. A generated screen doesn't settle where the data physically lives, who backs it up, who hosts the app, or how to arrange that a salesperson can't see purchase prices. Those three layers - data, permissions, operations - are what separate a prototype from a system.
Both tools generate the screen. The difference is what's underneath it.
A prototype answers “what would this look like”. A system also has to answer “where is the data, who hosts it, and who gets to see the prices”.
A practical rule of thumb: a prototype is fine right up until it contains data you'd be sorry to lose.
In detail: Lovable, Bolt, v0 and friends.
4. The question most companies skip: who maintains it
Writing software was never the expensive part. Maintenance is - the years in which laws, processes and people change. AI made day one cheaper and left the other thousand days untouched.
A typical first year for a generated app: day one live, month two a rate change hard-coded somewhere, month six a new colleague needing restricted access, month twelve something breaks and nobody on the team understands the code.
Three questions to ask before building anything important on generated code:
- Who here will read this code when something goes wrong?
- How many changes do we expect in a year, and who makes them?
- What happens when that person leaves?
In detail: AI will write your app. Who's going to fix it?.
5. How no-code works under the bonnet
To decide whether no-code is enough for you, it helps to know what it's made of. In practice, always five layers:
Databases and relations. The foundation of everything. A job knows which client it belongs to, an invoice which job, a timesheet what it attaches to. Without this you don't have a system, you have a set of lists.
Views. The same data shown differently depending on who's looking - table, kanban, calendar, timeline, chart, gallery. Sales and delivery look at the same thing through a different lens.
Forms and data capture. How data gets in from outside - from a client, from your website, from a colleague in the field.
Automations. Rules in the shape trigger → condition → action. This is where a system becomes something that works on its own.
Permissions. Who sees which databases, which records and which columns. Not an extra feature but a rule that has to hold everywhere.
In detail: A data model that grows with your team and Automation: the complete introductory guide.
6. Template or your own model?
The most common fork in the road. A three-question test settles it in five minutes:
- Do you do it the same way as your competitors? A standard process can carry a ready-made template.
- How many things do you keep in spreadsheets on the side? Four or more means you have your own system in spreadsheets and a template won't fix it.
- How often does your process change? Twice a year is a different situation from once in five years.
The most common outcome is neither extreme - it's “start from something ready-made and adapt it”. Which is exactly why the most important property of a system is the one nobody mentions in a quote: whether the data model can be changed after you've started working in it.
In detail: Template or custom app? A three-question test.
7. Where no-code genuinely isn't enough
The honest chapter. No-code isn't always the right answer. It doesn't make sense when:
- The software is your product. You sell it or it's your competitive edge - then you have to own all of it.
- You need non-trivial calculations or algorithms. Route optimisation, simulation, machine learning over your own data.
- You have extreme volumes or latency requirements. Millions of transactions a day aren't no-code territory.
- You need specialist hardware. Industrial buses, readers, devices with their own protocol.
- You have your own development team. Then development is internal capacity, not an external cost.
For everything else - CRM, job tracking, a helpdesk, an internal portal, invoicing, deadline management - no-code is now usually a faster and cheaper route to the same result.
8. How to start
The fastest route from decision to something working has four steps:
- Describe what the system should do, in plain language. Not technically. “I want to know who the client is, when the installation is, who's on it and whether it's been invoiced.”
- Have it produce a plan and review it. The structure of databases and relations is the one thing worth checking properly.
- Start smaller than you want to. Most people add a module at the outset that nobody opens after two weeks.
- Involve people sooner than feels natural. It saves rebuilding views.
In detail: I built our business system in an afternoon and Getting started with Apexloop.
Common questions about no-code and AI development
Is no-code suitable for a larger company?
Yes. What decides isn't headcount but the nature of the requirements. A fifty-person firm with ordinary operations (jobs, clients, invoicing, documents) is an ideal no-code case. A five-person team building a product with a unique algorithm needs development.
What happens to our data if we leave the platform?
Data must be exportable at any time in a structured format and at no extra charge. Ask about it before you sign - of a no-code platform and of a custom development supplier alike. An evasive answer is itself an answer.
Do we need someone technical?
Not to build it. To work out what your main entities are and how they relate, yes - but that's work for someone who understands your process, not for a programmer.
How long before the system is usable?
A first working version tends to be hours to a day. A version the team is happy with, two to three weeks of ordinary use and gradual tuning. The gap isn't technological - it's that the process gets refined while you run.
Can we combine no-code with our own code?
Yes, and it's common. The vast majority of the application stays code-free, and one specific exception is handled through webhooks or an API. The difference from custom development is one of proportion - you own one exception, not the system.