Hiring a Bubble developer costs whatever the quote says plus Bubble's own plan: a freelancer is paid by the day or a fixed price, an agency by a quoted project fee. Bubble's paid plans started at $32 a month billed annually when I checked. A good brief for a small business app covers users, data, rules, screens, acceptance tests and ownership.
I cannot give a verified market rate for developers, because published rates vary with experience and project, so this tutorial treats day rates and fixed prices as inputs. What follows is a cost model you can fill with real quotes, the running costs Bubble adds, a brief template that makes quotes comparable, and acceptance tests that stop a "finished" app being a surprise.
The five costs of a Bubble app, not one
People ask what a developer costs and forget the other four lines. For a small business app, the first-year bill has five parts:
- The build. The developer's fee: a fixed price, or days times a day rate.
- The Bubble plan. A subscription that runs as long as the app does.
- Workload on top. Bubble measures usage in workload units; paid plans allow overage you may be billed for.
- Add-ons. Plugins, email sending, payments, maps and file storage, which have their own prices.
- Upkeep. Bug fixes, changes and Bubble platform updates after launch, plus your own time testing.
The build is usually the largest single item, but the plan, add-ons and upkeep recur, so across three years they can exceed it. The sum to compare is the three-year total, not the quote.
What Bubble charges, from its own page
Bubble's pricing page, read in November 2026, listed these in USD, with paid prices billed annually:
| Plan | Price a month | Workload units a month | AI credits a month | App editors |
|---|---|---|---|---|
| Free | $0 | 50K | 500 | Owner only (see below) |
| Starter | $32 | 175K | 1,000 | Owner only (see below) |
| Growth | $119 | 250K | 2,000 | 2 |
| Team | $349 | 500K | 4,000 | 5 |
| Enterprise | Contact sales | Custom | Unlimited | Custom limit |
The page says overage can be paid as you go on Starter, Growth and Team, and can be switched off, and that extra workload tiers exist but were not priced on the page. Monthly-billing prices were not shown. The free plan cannot enable overages. Bubble emails you when an app reaches 75 per cent of its workload units and again at 100 per cent, when overages begin, and the add-ons it lists are workload tiers, extra file storage at $3 per 100 GB a month and plugin subscriptions. Read Bubble pricing: Starter, Growth and Team plans and workload units for how workload is counted, and why bills spike and how to cap them before you let anyone design a data-heavy page.
For a small app, the Starter plan at 12 x $32 = $384 a year is often enough to run it once launched. The catch is the build. Bubble's manual says Free and Starter do not support collaborators, so a developer can work inside your app on those plans only with a Bubble Agency account, which the manual says does not count towards any plan's collaborator limit. Otherwise you need Growth at 12 x $119 = $1,428 a year (the owner plus one editor) while the work is under way, or the developer builds in their own account and transfers the app to you. These are plan figures; the developer's hours are separate.

The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowDay rate, fixed price or agency: how the three differ
| Model | You pay | Risk sits with | Best for |
|---|---|---|---|
| Freelancer, day rate | Days worked x rate | You, if scope grows | Exploratory work, small changes, ongoing support |
| Freelancer, fixed price | One agreed figure | Developer, if the brief is clear | A well-described first release |
| Agency, project quote | Fixed or phased fee, usually higher | Shared; contract-dependent | Larger apps, deadlines, continuity if one person leaves |
Agencies usually cost more per day because they carry project management, review and cover for absences. Freelancers cost less but are a single point of failure: if your developer is ill or busy, the app waits. Neither is better; choose by what you can afford to lose. A rule of thumb: the more your business depends on the app, the more you should pay for continuity.
A worked cost model with labelled assumptions
Say a B2B software reseller wants an internal app where sales staff log quotes, attach a customer, apply a discount rule and send a PDF. The brief estimates 12 build days. The rates below are assumptions to be replaced by quotes; nothing here is a market figure.
Build: 12 days x day rate D = 12D (D from your quotes)
Bubble: Starter, 12 x $32 = $384 a year
Add-ons: PDF and email sending = A (from the developer)
Upkeep: 2 days a year x day rate = 2D a year
Your time: 20 hours testing x $40 = $800
Year 1 total = 12D + $384 + A + 2D + $800 = 14D + $1,184 + A
If a freelancer's day rate were $400, D = $400 and year one is 14 x $400 = $5,600, plus $1,184, plus add-ons: about $6,800 before add-ons. A $500 day rate gives 14 x $500 = $7,000, so $8,200. Change D to your quote and the number is yours. The structure shows two points: the day rate drives nearly everything, and your own testing time is a real line. Cutting scope by two days saves 2D, which beats any negotiation on the rate itself. One more line to watch: if your developer has no Bubble Agency account, budget Growth at $119 a month for the build months instead of Starter, since Starter cannot add collaborators.
Building the three-year view
Add years two and three, which exclude the build. Using the same assumed D = $400: plan $384, upkeep 2D = $800, add-ons A per year. That is $1,184 + A a year. Over three years the recurring part is about $3,552 + 3A, on top of $4,800 for the build and $800 of testing: roughly $9,150 + 3A. The recurring costs are now 39 per cent of the total, which is the number to weigh against renting an equivalent product. The comparison is the subject of software subscriptions versus one custom tool: five-year costs, and it often shows that a custom app wins only when no existing product covers the workflow.
The brief: eleven headings that make quotes comparable
A fixed price needs a fixed scope. Send every developer the same document so quotes can be set side by side:
1. Purpose One paragraph: who uses the app, to do what, replacing what.
2. Users Roles (for example, sales rep, manager, admin) and how many of each.
3. Data Things the app stores (customers, quotes, products) and fields on each.
4. Screens A list: login, quote list, new quote, quote detail, admin.
5. Rules If-then logic: discount over 10% needs manager approval.
6. Integrations Email sending, PDF, payments, accounting export, single sign-on.
7. Permissions Who can see or edit what; one customer must never see another's.
8. Out of scope Mobile app, reporting dashboards, data import, anything else not listed.
9. Acceptance The tests that decide "done" (see below).
10. Ownership Account in client's name; app, content and documentation belong to client.
11. Timeline Milestones and the payment attached to each.
Heading 7 deserves care in any app that holds more than one client's data. Bubble has privacy rules that restrict what each user can see, and getting them wrong is a classic failure: see Bubble privacy rules: stop clients seeing each other's data. Ask every candidate how they would test it.
A filled-in brief extract
Here is how headings 2, 5 and 7 might read for the reseller's quote app, as an illustration:
2. Users
Sales rep (up to 12): create and edit own quotes.
Sales manager (2): see all quotes, approve discounts.
Admin (1): manage products and prices.
5. Rules
- A quote total includes the product price x quantity, less discount.
- Discount up to 10%: no approval. Over 10%: status "Awaiting approval".
- A quote cannot be sent while awaiting approval.
- Sent quotes cannot be edited; a new version is created.
7. Permissions
- A rep sees only quotes they created.
- Managers see all quotes.
- Only admins see the cost price of a product.
Notice how many questions this answers before a quote is written. A developer reading it can estimate days with far less padding, and the permission lines double as test cases.
Acceptance tests: the clause that prevents disputes
Acceptance tests are plain statements the app must pass before you pay the final instalment. Write them from the rules and permissions. Examples for the same app:
- Log in as a rep. Create a quote with a 12 per cent discount. The status must read "Awaiting approval" and the Send button must be disabled.
- Log in as a manager. Approve that quote. The rep can now send it.
- Log in as a second rep. You must not see the first rep's quotes in any list, search or link.
- Sign in as a rep and open the browser's address bar with another rep's quote link. The app must refuse access.
- Send a quote. The recipient receives an email with a PDF whose total matches the screen.
- Create 200 test quotes. The quote list must load in under three seconds.
Run every test yourself on the staging copy, with a written pass or fail. A developer who welcomes this is confident in the work; one who resists is telling you something.
Where quotes come from and how to compare them
Bubble runs its own directory of Bubble-certified experts at bubble.io/agencies, filterable by agency, freelancer or coach, with a form for being matched to one; freelance marketplaces list Bubble developers too. Certification is a starting filter, not proof, so look at each developer's past Bubble apps and ask to see one live. When you have three quotes, put them in a table:
| Criterion | Developer A | Developer B | Agency C |
|---|---|---|---|
| Price and basis (fixed or days) | |||
| Days or hours assumed | |||
| Revision rounds included | |||
| Acceptance tests accepted as written | |||
| Permissions approach (privacy rules) | |||
| Live example of similar app | |||
| Support after launch and its price | |||
| Who owns the account and the app | |||
| Bubble Agency account (lets them join a Starter app) |
The two cheapest-looking quotes often differ by what they leave out. A quote with no testing time or no documentation is cheaper because it expects you to find the problems.
Ownership: set it up on day one
The point is simple and easy to forget. Create the Bubble account yourself, on your business email, and pay for the app from it: Bubble's manual defines the owner as the account that pays. Then invite the developer as a collaborator, remembering that Free and Starter allow this only for developers with Bubble Agency accounts, while Growth allows the owner plus one editor. That way the app, its data and the billing belong to you from the first day. If the developer would rather build in their own account, agree in writing that they will hand it over with Bubble's transfer feature, which takes effect immediately, before the final payment. Then confirm in the agreement that the app, its content and any documentation are yours on payment. Also ask what happens if the developer disappears: can another Bubble developer take over the app from your account without needing the first one's permission? With your account as owner, the answer is yes.
Ask, too, what you cannot take with you. An app built on a no-code platform runs on that platform, so moving to different software later usually means rebuilding. Your data can generally be exported, but check Bubble's current documentation rather than assuming. That is not a reason to avoid Bubble; it is a reason to budget for the app's lifetime on it. The same trade-offs against another builder are in Bubble versus Lovable: control, cost and upkeep.
Milestone payments that match the risk
Paying everything at the end invites a rushed handover; paying everything upfront removes your bargaining position. Tie instalments to things you can check. Using the illustrative fixed price of $4,800 for the reseller's quote app (12 days at an assumed $400):
| Milestone | Share | Amount | What you can verify |
|---|---|---|---|
| Agreement signed, data and screens confirmed | 20% | $960 | Written data list and screen list match your brief |
| Working draft on a staging copy | 30% | $1,440 | You can log in as each role and create a quote |
| Rules and permissions complete | 30% | $1,440 | Your acceptance tests for rules and roles pass |
| Live, documented, handed over | 20% | $960 | All tests pass on the live app; documentation received |
Notice the last instalment is 20 per cent, large enough to matter, and arrives only after documentation. If a developer asks for 100 per cent upfront on a first project with you, ask for a smaller first milestone and build trust in steps.
Two more briefs, scoped differently
A wholesale distributor's repeat-order portal
Say a distributor has 80 trade customers who email orders. The app would let each customer log in, see their usual items and reorder in three clicks. Users: customers (80), sales staff (4), admin (1). The risky headings are permissions (one customer never sees another's prices, because trade prices differ) and integrations (orders must reach the accounting system). Out of scope for release one: online card payments and stock levels. A developer reading this can quote a first release without guessing, and the out-of-scope line prevents the usual drift into a full web shop. A sensible acceptance test: log in as customer A, copy the address of one of A's orders, log in as customer B and paste it. B must see an error.
An HR consultancy's onboarding tracker
An HR consultancy wants a client-facing checklist: a new starter's tasks, who owns each, due dates and a status. It holds employees' personal details, so permissions and data protection matter more than screens. The brief should say what personal data is stored, who can see it, how long it is kept and how a record is deleted on request. Ask the developer how they would handle deletion and exports, and ask a qualified adviser about your obligations if you serve customers in regulated markets. The build may be small, perhaps six days, but the privacy testing is the real work.
Questions to ask each developer before you pick one
- Show me a live Bubble app you built that handles user logins. You are looking for real roles and real data, not a demo page.
- How will you stop one user seeing another's data? A good answer names privacy rules and how they are tested.
- What will this cost me in workload units each month? A good answer gives an estimate with assumptions, and says what the plan allows.
- How do you handle changes after the quote? Look for a change-request process with a price, not "we will see".
- What do I receive at handover? A list of pages, data types, workflows and plugins, ideally with a short recorded walkthrough.
- What happens if you are unavailable for two weeks? A freelancer should name a backup; an agency should name a second person.
- Which plugins will you use, and who maintains them? Plugins from third parties can be abandoned; ask for fewer.
Their answers matter more than the price. A cheap quote from someone who cannot answer question 2 is an expensive quote in disguise.
A change-request template for scope that moves
Scope will move, because you will think of things once you see the app. Agree how in advance, and use a short form for each change so costs stay visible:
Change request no. [number]
Requested by: [your name], [date]
What I want: [one or two sentences]
Why: [the problem it solves]
Developer's estimate: [days or hours] and [price]
Effect on timeline: [days]
Approved: [yes / no] [date]
Keep the forms in one document. After three or four, you can see whether the fixed price is holding or the project is quietly becoming a day-rate one. A rule that works well: any change over half a day is written down and priced before work starts.
Documentation you should receive at handover
- A list of data types and their fields, with a one-line meaning for each.
- A list of pages and which roles can reach them.
- A list of workflows (what triggers them and what they do), including any scheduled jobs.
- A list of plugins and API connections, with the account each uses, in your name.
- The privacy rules in plain English: who sees what.
- A short recorded video of the developer using each main feature.
- Instructions for common edits: changing a price, adding a user, editing an email template.
Another Bubble developer should be able to pick the app up from these notes. If they could not, your continuity depends on one person's memory, which is the risk you were trying to avoid when you chose to pay for continuity.
A realistic mistake: the app that worked for one user
A pattern seen in small projects: the developer demonstrates the app logged in as an admin, it all works, the owner pays, then the first real staff member logs in and sees every colleague's data, or cannot see anything at all. Nothing was wrong with the screens; the permissions had never been tested with real roles. The fix costs more after launch than before. Your defence is the acceptance test list above, with one test per role, run by you before final payment.
A second pattern: usage costs. An app that lists thousands of records on one page, or runs searches on every keystroke, burns workload units. The developer should be able to estimate monthly workload for your expected use, say 12 reps each creating 10 quotes a day, and say which plan it fits. If they cannot, ask them to test with realistic data before launch.
Before you hire: the cheaper tests of whether you need a custom app
A custom app suits workflows no off-the-shelf product covers. Before spending, spend a day on three checks:
- Search for the product. Many "custom" needs are met by an existing quoting, booking or portal tool at a monthly fee.
- Try a first draft yourself. Bubble's free plan and AI app builder let you test the idea. Building a customer portal from a description shows how far that goes.
- Consider a lighter tool. For a simple client portal, Softr versus Bubble compares cost and limits.
If a draft shows the idea works and you still need the real thing, you arrive at the developer with a prototype, which shortens the brief and often the price.
The one-page check before you sign
- The brief has all eleven headings, and every developer has the same version.
- The quote states fixed price or days, assumed hours and revision rounds.
- Acceptance tests are in the agreement, one per rule and per role.
- The Bubble account is mine, and the developer is a collaborator.
- My three-year cost, including plan, add-ons and upkeep, is calculated.
- Payment is tied to milestones, with the last instalment after acceptance.
- Post-launch support is priced, with a named response time.
If any line is empty, send the developer one more email. If you would like a second opinion on whether the app is worth building, my AI implementation consultation covers exactly that kind of scoping.
Hiring a Bubble developer: common questions
Should I hire on a day rate or a fixed price?
Use a fixed price for a brief you can describe precisely, and a day rate for exploratory work where scope will change. A fixed price protects your budget only if the brief has acceptance tests, because without them the developer and you may disagree about what done means. Cap day-rate work with a weekly spend limit.
Who owns the app after the developer finishes?
Bubble's manual defines the owner as the account that pays for the app. Pay from your own account and add the developer as a collaborator, which needs Growth or above unless they have a Bubble Agency account. If they build in their own account, Bubble lets them transfer the app to you at handover. Put ownership in the written agreement too.
What does Bubble itself cost on top of the developer?
Bubble's pricing page in November 2026 listed a free plan, Starter at $32, Growth at $119 and Team at $349 a month, each billed annually, with workload units and AI credits that rise by plan. Paid plans can pay workload overages as you go or switch them off, and extra file storage is $3 per 100 GB a month, so ask the developer to estimate monthly workload.
Can I build it myself instead?
For a simple internal tool, possibly. Bubble offers an AI app builder and a free plan to try. Hire when the app handles client data, payments or permissions, where mistakes are costly and a developer's experience pays back quickly.
Further reads
- How to Brief a Developer on a Custom AI Workflow You Need — Briefing a developer on a custom workflow.
- Hire a Squarespace Designer or Use Blueprint AI? What Each Costs — The same hire-or-DIY question for a website.
- How Much Does AI Cost a Small Business in 2026? — Where an app sits in a whole AI budget.
- Is a 1:1 AI Consultation Worth It for a Small Business? — When outside help pays for itself.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Bubble pricing page (bubble.io/pricing), Bubble manual pages on collaborators and privacy, and Bubble's expert directory (bubble.io/agencies), read on 5 November 2026. Freelancer and agency figures are illustrative assumptions, not market data.