⚡ AI Analyst
Lovable for agencies: how to run client dashboards on shared credits instead of seat fees, cap spend, and hand the project over cleanly.
Money Flock
Recommended Contents
Comments
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
Every agency that builds software for clients eventually becomes a landlord. The work sits in your account, under your login, on your monthly invoice, and the client holds nothing but a link. That arrangement is comfortable right up to the moment a client asks for the keys, or leaves and takes the rent with them.
So the real question behind Lovable for agencies is not whether the tool can build a client dashboard. It can, and quickly. The question is who holds the lease. Who owns the workspace, who pays for the credits the client burns, what the client can see when they log in, and what actually happens on handover day.
This guide answers those four questions against Lovable's own documentation and its live pricing page, both read on 25 September 2026. It covers the three delivery models agencies use, the roles and audiences that make client access safe, the credit ceilings that protect your margin, and the exact setting that turns a finished project into the client's property.
Lovable's own definition of the collaborator role. This is the seat a client gets, and it is deliberately narrow. Source: docs.lovable.dev/features/people, read 25 September 2026.
There is no agency tier on Lovable's pricing page. Search for "lovable for agencies" and you land on white label WordPress shops, because the phrase has been squatted by a different industry. What exists on Lovable is two separate things that people blur together.
The first is the partner program, where you get listed as an Expert or a Solutions partner and Lovable sends work your way. That is a channel, not a delivery method, and it has its own rules and its own commission maths. MoneyFlock covered it in the Lovable Partner Program explained.
The second is what this article is about: running your own client delivery on the platform. That one is built out of five primitives, and if you understand them you have understood agency work on Lovable completely.
Those five cover the whole job. Everything else, including design templates and single sign on, is a convenience layered on top.
Most delivery platforms punish you for adding people. Lovable does not, and the difference shows up directly in gross margin on a retainer.
Lovable's own pricing FAQ answers "Do you charge per seat or per user?" with a single word: neither. Plans are priced by the credits they include.
Read that carefully, because it inverts the usual agency arithmetic. Adding a client to your workspace costs nothing on the subscription. What changes is how fast the shared credit pool drains, because every prompt anyone sends, including an external collaborator working on their own project, draws from the workspace that owns the project. The client does not spend their credits. They spend yours.
Here is how the plans line up for agency work, read from lovable.dev/pricing on 25 September 2026.
| Plan | Entry price | What it unlocks for client work | Member ceiling |
|---|---|---|---|
| Free | $0 | Workspace private projects, 5 lovable.app domains, editor role only, 5 email invites a day | 200 with an owner, admin or editor role |
| Pro | $25 a month for 100 credits | Custom domains, viewer and admin project roles, per member credit limits, remove the Lovable badge | 200 with an owner, admin or editor role |
| Business | $50 a month for 100 credits | Team workspace, role based access, internal publish, personal projects, SSO, security center, design templates | No member limit by default |
| Enterprise | Platform fee, volume pricing | SCIM directory sync, audit logs, restrictions on who publishes and invites, data residency for Git sync | Custom |
Both the Pro and Business ladders run eleven rungs up to 10,000 credits a month, at $2,250 on Pro and $4,300 on Business. The Business ladder is roughly double the Pro ladder through the middle of the range and converges at the top with a 14 percent saving marked on the largest rung. The full pricing breakdown has the whole ladder, and what an MVP really costs in credits has the consumption side.
Free, Pro and Business plans all include 5 daily build credits that reset at 00:00 UTC and do not roll over. Free caps them at 30 a calendar month. Pro and Business have no monthly cap.
For an agency running several small client projects, those uncapped daily grants are not a rounding error. Five credits a day across a month is roughly 150 credits of build work that never touches your paid allowance, provided the work is spread out rather than crammed into a weekend. That is the single cheapest thing on the platform and most agencies leave it on the table.
Five decisions, in the order you have to make them. Get the first one wrong and the last one becomes a negotiation instead of a button.
A paid Lovable subscription applies to one workspace only. If you want a separate workspace per client, each one needs its own subscription. That is the fork in the road, and it is easier to take deliberately on day one than to unwind in month six.
One agency workspace holding every client project is cheaper, keeps all credits in one pool, and lets you reuse work across projects. A workspace per client isolates billing and data, which matters when you are handling financial records and the client's compliance team asks who else can see them. If that question is live on your account, read whether Lovable is safe for financial data before you answer it.
Project roles are not all available on every plan, which is the detail that trips up agencies still on Free. Viewer and admin are paid plan roles. Editor is the default and the only project role a free workspace can hand out, which means on Free you cannot give a client read only access to a project. You can only give them edit rights or nothing.
Lovable's own project role table. Viewer and admin are paid plan roles, editor is the default everywhere, and every project has exactly one owner. Source: docs.lovable.dev/features/projects/overview, read 25 September 2026.
When you invite someone who is not already in your workspace from a project's Share dialog, Lovable adds them as an external collaborator. They can see basic workspace information, open the projects shared with them from a Shared with me tab, and open the Plans and credit usage tab where every billing control is disabled for them. They cannot initiate or approve a charge against your workspace, and they cannot see the People tab at all, so they never see your other clients' names.
On Business and Enterprise workspaces you can go further. A Privacy and security setting called External project collaborators caps the highest project role anyone outside the workspace can hold: none allowed, viewers only, editors and viewers, or all. Set it to viewers and a slipped click by a junior cannot hand a client edit rights on a live project.
This is where most agency client dashboards quietly fail their own security promise. Publishing a Lovable app makes it live at a URL. By default that URL is public, and "nobody knows the address" is not access control.
Business and Enterprise plans let you choose who can view the published site. Workspace publishes it internally, so only logged in workspace members can open it. Custom lets you compose the audience: the whole workspace, specific members, groups, and named people outside your workspace invited by email. Those outside invitees are marked with an EXT label in the audience list, they log in with the invited address, and their access does not expire.
That is the mechanism for a genuine client dashboard. The client opens the app with their own login, sees only what you published, and never gets near the editor, the project chat or the code. Project access and website access are independent settings in Lovable, and keeping them independent is the whole point.
Since collaborators spend your workspace's credits, an enthusiastic client on an editor role is a billing risk. Lovable gives you two controls for this on Pro and above: a default monthly credit limit that applies to every member, and a per member override set from the People tab.
When a member hits their limit they cannot use more build credits until the first of the next month, UTC. Set the ceiling at the number your retainer actually prices in, and the overage conversation stops happening after the fact.
The People tab also carries a User insights panel per member showing credits used in the last 7 and 30 days, the projects they created, and the projects they collaborate on with per project usage. That is your invoice evidence, already itemised.
A Lovable project can be moved from your workspace into the client's from Project settings, under Move workspace. The project keeps its history and its settings. Three things change, and all three belong in your handover checklist.
To move a project into a client's workspace you have to be a member of that workspace with permission to create projects there, so the client invites you in, you move the project across, and you leave. From that moment the client's subscription pays for the app's credits, which is usually exactly what both sides wanted.
Every agency arrangement on Lovable is a variation of three shapes. Pick one per client and write it down.
| Model | Workspace owner | Who pays for credits | Client access | Handover path |
|---|---|---|---|---|
| Build in house, client never logs in | Agency | Agency | Published URL only, no Lovable account | Move workspace, or export the code |
| Client as external collaborator | Agency | Agency | One project, viewer or editor, plus the published app | Move workspace with collaborators transferred |
| Client owns the workspace | Client | Client | Everything in their own workspace | Nothing to hand over, you leave |
The economics differ more than the table suggests. On model one you carry the credit cost and can mark it up, which is clean until a client's app runs heavy Cloud usage and the run credits stop being predictable. On model two you carry the cost but the client generates part of it, which is the worst of both unless you set per member limits. On model three your revenue is pure labour, your margin is safe, and you lose the recurring line item.
Model three is also the one that ends the awkward conversation about what happens if you stop paying. An app on a downgraded or cancelled plan stays live and connected custom domains keep serving, but if you built the client a workspace restricted or custom audience site and then drop below Business, Lovable will not publish changes to it. The live version stays online and you get a message saying publishing to workspace requires a Business plan. Your client's dashboard freezes at the last version you shipped.
If you want the numbers behind pricing a build rather than a retainer, the real unit economics of selling a Lovable app works through credit cost, payment rails and breakeven.
Inviting a client from the People tab makes them a member of your workspace with a real role. Inviting them from a project's Share dialog makes them a collaborator scoped to that project. The second is almost always what you meant. Collaborators cannot be invited from the People tab at all, which is Lovable telling you the same thing.
A published Lovable app is public by default, and restricting who can view it requires Business or Enterprise. If your proposal promises a private client portal and your workspace is on Pro, you have promised something your plan does not do. Either move the sensitive view behind the app's own authentication or price the Business plan into the engagement.
Website access settings keep working after a downgrade. Publishing changes to them does not. Cancel down to Pro at the end of a project and you keep a live client dashboard you can no longer update. This is the one plan interaction worth putting in your own runbook.
Every prompt from an external collaborator draws on your workspace pool. A client who discovers the chat box and spends an afternoon in it is spending your money. Set a default limit for the workspace and an override for that person before you send the invite, not after the first surprising usage chart.
The Lovable badge on a published app can be removed, but only on Pro and above. If the workspace later moves to a plan that does not include it, the badge comes back the next time the project is published, and sites already live stay unchanged until you republish them. That is a specific, checkable behaviour, and it is worth checking before you write "fully white labelled" in a proposal. Being a certified Expert is a certification, not an endorsement from Lovable, and it is worth describing it that way to clients too.
The handover, in Lovable's own words. The Transfer project collaborators checkbox is off by default, and the project's access setting resets to the destination workspace's default. Source: docs.lovable.dev/features/projects/settings, read 25 September 2026.
Four things worth re-checking before your next client proposal goes out.
No. Lovable's pricing documentation states plainly that plans are priced by the credits they include, not by seats, and that inviting more members does not change your subscription cost. What changes is how quickly the group uses the workspace's shared credits. Free and Pro workspaces do cap membership at 200 people holding an owner, admin or editor role, with viewers and external collaborators not counted. Business and Enterprise have no member limit by default.
Not if they are an external collaborator. Collaborators see only the projects shared with them, through a Shared with me tab, and they do not see the People tab, so your member list stays private. They can open the Plans and credit usage tab to see the plan and balance, with every billing control disabled. If you need a harder boundary than that, use a separate workspace per client and accept the separate subscription.
Partly. You can remove the Lovable badge on Pro and above, connect the client's own custom domain on any paid plan, and publish to a restricted audience on Business. What you cannot do is hide that the app was built on Lovable from anyone who inspects the code, and the badge returns on the next publish if the workspace drops to a plan without that feature.
Move the project into the client's workspace from Project settings, under Move workspace, after they invite you into it. The project keeps its history and settings. Decide deliberately whether to tick Transfer project collaborators, and re-check the project's access setting afterwards because it resets to the destination workspace's default. If the client wants the code rather than the project, exporting to GitHub and Vercel is the other route.
There is a partner program with Expert and Solutions tracks, which is about Lovable referring work to you and is separate from how you run delivery. You can find certified Experts, including TJ Alam's Expert listing, in the public partner directory.
The landlord analogy holds all the way to the end. You can rent the client a room in your building, which is the collaborator seat, or hand them the deed, which is the workspace move. What you should never do is let them find out which one they have on the day they want to leave. Decide it in the proposal, price it into the plan you buy, and the handover stops being a negotiation. If you are weighing the platform as a whole before committing client work to it, the full 2026 Lovable review covers the trade offs, and building with Lovable on a Business plan is what unlocks the team workspace, role based access and audience controls this article relies on.
TJ Alam is a certified Lovable Expert (Website Builder track), founder of Digi Flock Enterprises, and built tjalam.com and cyberdance.in on Lovable. He is listed in the Lovable partner directory.
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.