Freelancer, no-code or agency: who should build your app?
10 min read
Key takeaways
- No-code is the right answer for validating a need, equipping a small team or launching a first low-volume product.
- AI app builders deliver real code you can take away, but someone has to be able to review it, secure it and maintain it.
- Before choosing, check five points: code ownership, scaling, app store publication, data hosting and the skills you have available.
- Moving from no-code to custom almost always means rewriting: prepare for it from day one by keeping your data, journeys and business rules documented.
Five years ago, the question was simple: no developer, no app. Today, a founder can put an app together in Bubble in a few weeks, or describe an idea to an AI builder and get a clickable prototype by the afternoon. That is real progress, and we recommend it regularly.
But these three options do not buy the same thing. No-code buys speed of learning. AI buys speed of writing. Custom development buys control. The right choice depends on what your project needs in eighteen months, not on what is fastest this week.
Our article freelancer, no-code or agency compares who builds the app. This one compares what it is built with, and what each choice costs you later.
Three ways to build, in one sentence each
No-code. You assemble the app in a visual editor (Bubble, FlutterFlow, Adalo, Glide…) and the editor hosts it. You see none of the code, or very little.
AI app builders. You describe what you want in plain language, a tool such as Lovable writes the code, and you correct it through conversation. The result is real code, which you can usually export.
Custom development. A team designs the architecture and writes the code, with React Native, Flutter or native, on infrastructure you choose. AI assistants are now part of its toolkit, but a human decides and reviews.
The comparison
| No-code | AI builder | Custom | |
|---|---|---|---|
| First prototype | A few days to a few weeks | A few hours to a few days | 4 to 8 weeks for a mobile MVP |
| Code ownership | None to partial, depending on the tool | Code usually exportable | Full, if the contract says so |
| Recurring cost | Subscription that rises with usage | Subscription and credits | Hosting and maintenance (15 to 20% of the initial cost per year) |
| Complex business logic | Quickly unreadable | Possible, fragile without review | Designed for it |
| Native features (Bluetooth, offline, background) | Limited to the tool’s extensions | Variable | No limit |
| Data hosting | Chosen by the vendor | Often chosen by the vendor | Chosen by you |
| Skills required | Logic, no code | Being able to read code | A team |
No column wins everywhere. Your project’s profile decides which row matters.
No-code: when it is the right choice
We recommend no-code without hesitation in three situations.
You are testing a hypothesis. You do not yet know whether anyone will use or pay for the service. Spending 30 to 60 person-days of development to find out makes no sense if a visual tool can give you the answer in three weeks.
It is an internal tool. Request tracking, a directory, an inspection form for a small team. Volumes are low, the users are your colleagues, and tolerance for a standard interface is high.
The product is mostly content and forms. A catalogue, simple booking, a members’ area. No-code tools are very good at this, and the gap with custom development does not justify the budget.
The tools have also made progress on mobile. Bubble states that its native apps run on React Native and can be published to the App Store and Google Play, with a paid plan needed to go live. FlutterFlow offers deployment to both stores and source code download from its Basic plan. Adalo includes app store publication from its Builder plan.
The right way to use no-code: decide from the start which question the tool must answer (“do people book?”, “does the team give up paper?”) and the date on which you will look at the answer. A prototype without a question becomes a product by accident.
AI app builders: real code, but who reviews it?
AI builders change one important point compared with classic no-code: they produce code you can take with you. Lovable, for example, offers two-way sync with GitHub, in a repository that is private by default, and code download on paid plans. Its pricing page states that you own the code of your projects.
That is a real advantage for migration. But owning code does not mean being able to evolve it. Three limits come up almost every time.
The code works in a demo, not necessarily in production. The main journey works; error cases, expired sessions, concurrent access and role-based permissions are often handled superficially. These are precisely the points a real user hits first.
Security is not checked by default. A builder can expose a database with overly broad access rules without anything flagging it on screen. If the app handles personal data, a review by someone who knows what to look for is not optional.
Every fix by prompt adds a layer. After a few hundred iterations, the project’s structure reflects the history of the conversation rather than an architecture. Taking it over then costs almost as much as rewriting it.
Our position is simple: AI is excellent for producing a prototype that serves as a living specification, and very useful in the hands of a developer. It does not yet replace the person who answers for what goes into production.
The five limits to check before choosing
1. Code ownership and vendor lock-in
This is the most important question and the one least often asked. Bubble’s manual is clear: you own your app’s design and data, Bubble owns the underlying code, and a Bubble app can only run on Bubble. You can export your data as CSV, but the logic has to be rebuilt elsewhere. FlutterFlow, by contrast, pushes a Flutter project to GitHub that you can take over.
In practice: if the vendor doubles its prices, changes its terms or removes a feature, what is your way out, and how long does it take?
2. Scaling and performance
Platforms increasingly charge by usage. Bubble counts in “workload units”: 175,000 a month on the Starter plan, 250,000 on Growth, with paid extra tiers. A product that works consumes more, and the bill follows your success. The optimisation levers, meanwhile, remain the ones the vendor exposes.
3. App store publication
Being technically publishable does not guarantee being accepted. Apple’s rules reject apps that are merely a repackaged website (guideline 4.2) and apps created from an app generation service unless the content owner submits them (guideline 4.2.6). Also budget for developer accounts: 99 dollars a year with Apple, 25 dollars once with Google. We cover the other rejection reasons in our article on the App Store and Google Play.
4. Data and GDPR
With a hosted tool, the vendor chooses where your data lives. Bubble’s manual states that dedicated servers in Europe come under the Enterprise plan, and that transfers outside the EU rely on standard contractual clauses. That is not an obstacle for every project, but a large corporate client, a public body or a health app may require it. Our guide to GDPR and mobile apps details what to check.
5. The skills you have
No-code requires logical rigour, not code. AI requires being able to read code. Custom development requires a team, in-house or external. Choosing an option without the skill it assumes is the most common cause of failure.
The cost over three years, not three months
No-code subscriptions look trivial next to a development quote. As of 15 November 2026, according to their pricing pages: Bubble at 32, 119 or 349 dollars a month billed annually, FlutterFlow at 29, 60 or 113 dollars a month billed annually, Adalo at 65 or 200 dollars a month billed monthly.
On the other side, the median reported by La Fabrique du Net for an app built by an agency is €30,000, and around €15,000 for an MVP. Maintenance of a custom app then represents 15 to 20% of the initial cost per year.
$1,428One year of Bubble Growth at the listed annual rate ($119 × 12)
≈ €15,000Median for an MVP built by an agency (La Fabrique du Net)
15–20%Annual maintenance cost of a custom app
On paper, no-code wins comfortably. The calculation changes on three points:
- Time spent. If you build it yourself, your evenings and weekends have a cost. If you pay a no-code specialist, the bill gets closer to conventional development.
- Usage. Workload tiers and AI credits pile up when the product takes off, just when you are least in a position to negotiate.
- The rewrite. If the product works, it almost always comes. It is not a failure, but it should be in the plan from the start.
The real cost of no-code is therefore not the subscription. It is the rewrite you had not budgeted for. To place a custom budget, our article on how much a mobile app costs details the tiers.
Moving from no-code to custom without losing everything
Let us be honest: with a tool such as Bubble, you do not migrate, you rewrite. With FlutterFlow or an AI builder, the recovered code can serve as a base, but it usually needs restructuring. Either way, what you keep has enormous value, provided you have prepared it.
What you can recover: the data (CSV export or API), the journeys validated by real users, the screens that work, the usage figures, and above all the list of what did not work.
What gets lost: business logic buried in visual blocks or prompts, if nobody has written it down elsewhere.
Four habits, from day one, sharply reduce the cost of the rewrite:
- Document every business rule in one sentence in a shared document: prices, calculations, statuses, permissions. It is your future requirements document.
- Keep a clean data model: clearly named tables, with no “temporary” fields that last a year.
- Measure usage with an analytics tool independent of the platform, so the history survives the migration.
- Set exit signals in advance: a number of users, a monthly cost, an impossible feature. When two signals are reached, you scope the rewrite.
Well prepared, rewriting a validated MVP fits the usual timeline: 4 to 8 weeks for a mobile MVP on one platform, 3 to 4 months for a full iOS and Android app. It starts from real data, which makes it far safer than a first project. Choosing the target technology is covered in React Native, Flutter or native.
Our decision grid
Choose the tool that answers your current question, and write down today what you will do when it is no longer enough.
- You do not yet know whether the need exists: no-code or an AI-generated prototype, with a question and a date.
- Internal tool for a small team, low volume: no-code, for the long term.
- You want to show something to investors or users next week: an AI builder, accepting that it is a mock-up.
- Sensitive data, heavy integrations, native features, or a product that must last several years: custom from the start, keeping the first scope small as explained in our MVP method.
- Your no-code version works and is starting to struggle: a custom rewrite, starting from your data and your validated journeys.
Going further: our mobile app development page explains how we take a no-code or AI prototype and turn it into a production app, from scoping to store release.
Sources
- Bubble, pricing page (accessed 15/11/2026)
- Bubble, manual: application and data ownership
- Bubble, manual: GDPR
- FlutterFlow, pricing page (accessed 15/11/2026)
- FlutterFlow, documentation: Push to GitHub
- Adalo, pricing page (accessed 15/11/2026)
- Lovable, pricing page
- Lovable, documentation: GitHub integration
- Apple, App Store Review Guidelines (guidelines 4.2 and 4.2.6)
- La Fabrique du Net, mobile app agency rates (November 2026)
