Bubble's own manual says that "the migration of your app away from Bubble's hosting is not possible". That one sentence decides more about a web app project than any portfolio. The agency you hire picks a stack, and the stack decides whether you can ever leave the agency, the host or both.
This guide is for founders and operations leads comparing web app development companies for a SaaS product, a client portal, an internal tool or an onboarding flow. It covers how to match a stack to the kind of app you need, what you must own on day one, and a handover test you can run before you sign. The facts come from the Stack Overflow 2025 Developer Survey, UK and US copyright law, the GDPR, OWASP, Google's DORA programme and the vendors' own documentation.
What a web app development agency builds, and why the type matters
"Web app" covers very different products. A marketing site is mostly read. A web app is mostly written to: users sign in, enter data, upload files, approve things and expect the app to remember. That shifts the risk from design to data, permissions and uptime.
The four kinds we see most often in briefs have different failure points, so they need different questions.
| App type | Who uses it | Where it usually fails | Ask the agency to show |
|---|---|---|---|
| SaaS product | Paying customers, many companies | One customer seeing another's data; billing edge cases | The tenancy model and how it is tested |
| Client portal | Your clients, with your staff | Permissions per client and per document; adoption | The role matrix and the invite flow |
| Internal tool | Your own staff | Spreadsheet logic copied without its rules; no audit trail | How existing rules are captured and logged |
| Onboarding or application flow | Prospects and new customers | Drop-off on long forms; lost half-finished entries | Save-and-resume and field-level validation |
Source: our own summary of common failure points; not a survey
If you are deciding whether to build an internal tool at all, our internal tools statistics collect the published data on engineering time and low-code adoption. For portals, the client portal adoption statistics show what usage looks like after launch, which is the number a portal is really judged on.
Stack fit: four questions that matter more than the framework
Most buyers cannot judge a framework, and they do not need to. Four plain questions cover what matters.
Can you hire for it later? The Stack Overflow 2025 Developer Survey found PostgreSQL used by 58.2% of professional developers, React by 46.9%, TypeScript by 48.8% and Next.js by 21.5%. ASP.NET Core sat at 21.3%, Django at 11.7% and Laravel at 9.3%. All of these have a large hiring pool. A framework the agency wrote itself has a pool of one.
Can it run somewhere else? The Next.js documentation lists a Node.js server and a Docker container as deployment options with support for all features, and static export as limited. That means a Next.js app built on Vercel can move to another host. A no-code platform that hosts the app itself may not allow that at all, as Bubble's manual states.
Who holds the data? GOV.UK's Service Manual, written for public-sector teams but sound for anyone, tells teams to "make sure you always have full control of any data you store" and to avoid "getting locked in to long contracts for specific tools and providers". Ask where the database lives, whose account it is in, and how you would export it.
Where is the ceiling? Visual builders and low-code backends are quick for the first version. The question is what happens when you need a feature they do not support. Our comparison of Wized against custom code walks through where that ceiling sits for a Webflow front end.
| Stack | Hiring pool | Can run on another host | Lock-in to watch |
|---|---|---|---|
| Next.js or React with PostgreSQL | Large (React 46.9%, PostgreSQL 58.2%) | Yes, Node.js or Docker | Hosting-specific features, managed auth |
| Django, Laravel or ASP.NET Core | Medium to large (11.7%, 9.3%, 21.3%) | Yes | Usually low |
| Low-code front end on custom backend | Smaller | Front end often tied to its builder | The builder's own logic layer |
| Fully hosted no-code platform | Platform specialists | Bubble: not possible | The whole app |
Source: Stack Overflow Developer Survey 2025, professional developers; Next.js deployment documentation; Bubble manual
Our bias, stated. We build marketing sites in Webflow and applications in Next.js, so a guide that recommends portable, widely used stacks also happens to recommend ours. Our recommended MVP tech stack for 2026 lists the layers we would pick and three we would not start with; this guide does not repeat it.
Ownership: code, accounts and data
Three things have to be yours, and each fails in a different way.
The code. Under the UK's Copyright, Designs and Patents Act 1988, section 11, the author of a work is the first owner of its copyright, and only an employee's work belongs to the employer by default. An agency is not your employee. In the US, 17 U.S.C. § 101 limits commissioned "works made for hire" to nine categories, such as translations, tests and atlases, and software is not one of them. In both places the code stays with the agency until a signed contract assigns it to you. Ask for the assignment to take effect on each payment, not on final delivery.
The accounts. Code you own is of little use if the repository, the hosting, the database and the payment account sit in the agency's name. GitHub's documentation says a repository transfer brings its issues, pull requests and wiki with it, and redirects old links. It also says webhooks, secrets and deploy keys stay attached, so a transferred repository can still hold credentials the agency created. It is cleaner to create the organisation yourself on day one and invite the agency in.
The data. If the agency can see personal data, for example user records in a client portal, it acts as a processor. GDPR Article 28(3) requires a contract that, among other things, says the processor "deletes or returns all the personal data to the controller" when the work ends, at the controller's choice.
| Account | Why it matters | Paid tier needed for production |
|---|---|---|
| Code repository organisation | Holds the code, history and pipeline | Depends on team size |
| Hosting | Runs the app; holds environment variables | Vercel: Hobby plan is non-commercial only; Pro is $20 per developer seat a month |
| Database | Holds every customer record | Supabase: free projects pause after one week of inactivity; Pro from $25 a month |
| Payments, email, domain, DNS | Revenue, password resets, the address itself | Varies by provider |
| Error tracking and logs | How anyone finds out the app is broken | Varies by provider |
Source: Vercel Hobby plan documentation and Supabase pricing page (vendor pages), read 2026-10-28
The handover test: run it before you sign, and again at the end
Every agency says its handover is good. You can check, and the check costs one day of an independent developer's time.
The idea borrows from the Twelve-Factor App, a widely used set of principles for web services. Its test for configuration is "whether the codebase could be made open source at any moment, without compromising any credentials". The handover test asks a wider version: could a developer who has never seen this project run it, change it and recover it using only what the agency hands over?
Before you sign. Ask the agency for the handover pack from a past project, with client details removed: the README, the environment variable list, the runbook and the architecture note. If they cannot show one, they do not have a habit of writing one.
At the end of the project. Give a fresh developer, ideally not someone the agency suggested, access to the repository and your accounts, and one working day.
| Step | Pass looks like | Fail looks like |
|---|---|---|
| Clone and run locally | Running within an hour from the README alone | Needs a call with the original developer |
| Set configuration | Every variable listed with its purpose; no secrets in the code | Values found by reading code or asking |
| Deploy to a new environment | Pipeline runs from your account to a new preview or staging | Deploys only from the agency's machine |
| Restore the database | A backup restored to a copy, with the date checked | Nobody knows when the last backup ran |
| Rotate one secret | Changed in one place, app still works | Key is hard-coded or shared across services |
| Remove agency access | App keeps working after their accounts are removed | Something breaks because it ran under a personal login |
Source: our handover checklist; the configuration rule follows the Twelve-Factor App
The restore step matters more than it looks. Supabase's Pro plan, for example, keeps daily backups for seven days, and point-in-time recovery is an add-on at $100 a month per seven days of retention (vendor pricing page). If your app cannot lose a day of data, that is a decision someone has to make and pay for, and the handover test is where you find out whether anyone did.
Delivery evidence: what to ask for instead of a portfolio
A portfolio shows screens. A web app lives or dies on how changes reach production and how fast problems are fixed.
Delivery metrics. Google's DORA programme defines five software delivery metrics, last updated in January 2026: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. An agency does not need to publish them, but it should be able to say how often it deploys a typical client app and what happens when a release fails. "We deploy at the end of each sprint" and "we roll back with one click" are real answers.
Security. The OWASP Top 10:2025 puts broken access control first, followed by security misconfiguration and software supply chain failures. In a portal or a multi-tenant SaaS, broken access control means one client reading another client's files. Ask how permissions are tested, not whether the login page is secure.
AI-written code. The Stack Overflow 2025 survey found 84% of developers use or plan to use AI tools, 51% of professional developers use them daily, and more developers distrust their accuracy (46%) than trust it (33%). Using AI is normal. The question is what review and tests every change passes before it is merged, whoever or whatever wrote it.
Reading proposals from web app development companies
Once two or three proposals are on the table, compare them on what they leave out.
Discovery before build. A proposal that prices the full feature list with no paid discovery has guessed at your scope. Our SaaS MVP development company guide, scheduled shortly, sets out ten questions on scope and pricing; this guide does not repeat them.
Named people. "Our team" is not an answer. Ask who writes the code, who reviews it, and who replaces them if they leave.
Support after launch. Web apps need patching. Ask what a month of maintenance covers: dependency updates, security fixes, uptime monitoring and a response time.
A written exit. The contract should say what you receive, in what form and by when, whether you leave after launch or in year three. If the handover pack is defined in the contract, the handover test has something to test against.
We quote per project, and we would not publish a price for a web app without seeing the brief, because a two-role internal tool and a multi-tenant product with billing are different jobs.
What this means for choosing a web app development agency
Shortlist on stack fit first: a stack you can hire for and host anywhere. Then check ownership: code assigned on payment, every account in your name, a processor clause if personal data is involved. Then run the handover test on a past project before you sign, and on yours before the final invoice. An agency that is comfortable with all three is one you can stay with because you choose to, not because you cannot leave. Our web apps service page explains how we scope a build.
