The moment a finance team stops being one person with a side project, the question changes. It is no longer "can I build this?" It is "who is allowed to change the numbers, who signs off before anyone outside the team sees them, and what happens to the app when the person who built it leaves?"
Those are workflow questions, not build questions, and they are the ones Lovable quietly answered over the last three weeks. Drafts arrived on 7 September 2026, groups let you scope a published dashboard to named people, and the People tab now shows per-member credit spend and decides who inherits a project when someone is offboarded. None of it is glamorous. All of it is what turns a personal tool into something a team can actually run on.
This article is about running a small finance team on Lovable: how to structure the workspace, which role each person should hold, how drafts change review, and the two places where the model will bite you if you assume it works like Git. Every claim below was read from Lovable's own documentation and pricing page on 26 September 2026. For what each plan costs, see our separate breakdown; this piece is about the workflow, not the price list.
Workspace, Project, Draft: Getting the Three Layers Right
Most teams get into trouble because they treat a Lovable workspace like a folder. It is closer to an account. Three things follow from that, and each one has a consequence a finance lead should care about.
A subscription applies to one workspace. Credits belong to the workspace that owns a project, and every prompt draws from that shared pool no matter who typed it. So the workspace is the billing boundary, the access boundary and the budget boundary at the same time.
A project sits inside a workspace and has its own owner and its own access list. One person owns each project, and workspace owners can open every project regardless.
A draft sits inside a project. It is a copy of the project with its own chat, preview and edits, and nothing in it reaches the project until someone accepts it.
The practical shape for a finance team of three to ten people is one workspace, one project per tool, and drafts used for anything that changes what a number looks like. Resist the urge to give each analyst their own workspace. A separate workspace means a separate subscription, a separate credit pool and no shared visibility, which is the opposite of what you want.
Who should hold which role
Lovable has five workspace roles, and the plan you are on decides which of them exist.
- Owner. Billing and domain claims run through the primary owner, marked Owner* in the member list. Only owners can promote someone else to owner, and inviting a second owner requires a Business or Enterprise plan.
- Admin. Everything except adding, removing or promoting owners. Available on paid plans.
- Editor. The default, and the only role available on every plan. Editors can build, and they can also invite and remove viewers and external collaborators and approve project access requests, which is more delegation than most teams expect.
- Viewer. Read-only. Paid plans only, which means a free workspace cannot give anyone look-but-do-not-touch access at all.
- Collaborator. Created only by inviting a non-member to a single project from that project's Share dialog. Collaborators cannot see the People tab, so your member list stays private to the team.
Two of those deserve a decision rather than a default. The first is the second owner. A finance team that runs its close process on an internally published dashboard should not have one person holding the only owner seat, and a second owner is a Business-plan feature. The second is viewer access, which is how you give an auditor or a manager a look at the project without giving them the ability to prompt against the shared credit pool.
Roles are not seats, and this is the part most people get wrong. The pricing FAQ answers the question "Do you charge per seat or per user?" with "Neither. Plans are priced by the credits they include, not by seats." Adding a sixth analyst does not raise the subscription. It drains the pool faster, which is a different problem with a different fix.
Per-Member Credit Limits, and Why They Are the Real Budget Control
Because credits are shared, one person exploring an idea at eleven at night can spend what the team needed for month-end. If you have not yet worked out what your team actually burns in a month, our breakdown of how Lovable credits are consumed is the place to start. Lovable's answer to the shared-pool problem is a per-member monthly credit limit: a workspace default that applies to everyone, plus individual overrides set from the People tab.
Three details decide whether this is useful to you.
- It counts build credits only. Run credits, the ones consumed when Lovable hosts your app and runs its backend, belong to the project rather than to the person who built it, so they never count against anyone's limit.
- Hitting the limit is a hard stop. A member who reaches it cannot use more build credits until the first of the next month, UTC. There is no partial reset and no self-serve override by the member.
- Bulk import is Enterprise-only. On Business you set the workspace default once and override individuals one at a time, which is fine for a team of ten and painful at fifty.
Alongside the limit, the People tab gives you User insights: click any member row and you get credits used in the last 7 and 30 days, the projects they created, and the projects they collaborated on with per-project usage. It is read-only, and for a finance lead it is the closest thing to an itemised bill by person and by tool. That is the report you want before you decide whether the tooling budget is going to the right place.
A sensible starting policy: set a workspace default that is roughly the team's monthly allowance divided by the number of builders, then raise it for the one or two people who actually ship. Review it against User insights after the first full month rather than guessing twice.
Drafts: The Review Step Finance Work Has Always Needed
Before drafts, every edit landed directly in the project. If two people wanted to try different things, one waited or remixed the project, and consolidating afterwards was manual. Drafts fix that, and the mechanics are worth learning precisely because they are not quite Git.
A draft is a copy of the project with its own chat, preview and edits. You build in it, then either accept it, which adds its edits to the project, or delete it, which discards them. Accepting does not publish. Your live app changes only when someone publishes the project from the main version, and a draft has no publish button of its own.
For a finance team that separation is the whole point. An analyst can rebuild the variance page in a draft while the dashboard the leadership team opens every morning stays exactly as it was. Nothing is at risk until a human accepts, and nothing is visible until a human publishes.
What it costs, and what it does not
Creating, updating, accepting and deleting a draft do not use credits. You pay only for the messages you send inside a draft, and a message costs the same there as it does in the main version. There is no review tax. That matters, because a review step people are charged for is a review step people skip.
How a two-person review actually runs
Everyone with edit access to the project sees the same drafts, and each draft shows who is currently working in it. If you open a draft someone else is in, Lovable suggests creating your own instead. Once more than one person has made a draft, the switcher splits into All drafts and My drafts.
Before you accept, Lovable shows a one-line summary of what the draft changes, followed by the edits themselves. That summary is kept: it appears labelled Draft summary on the accepted change in the project chat and in version history. For a team that has to explain in November why a figure changed in September, a durable per-change summary written at the moment of the change is more useful than it sounds.
One sequencing detail. If the project has moved on since the draft was created, the draft's row shows a grey Updates available dot. You do not have to update before accepting; Lovable updates first and then accepts. And if several drafts are accepted at once, they are processed one at a time, with an Accepting drafts card above the chat showing the order, which you can reorder or remove from.
The Two Things That Will Catch a Finance Team Out
Drafts are safe for the app and not safe for the data. This is the single most important paragraph in this article.
A draft shares your real backend and your real data
A draft does not get a backend of its own. It uses the project's built-in backend: the same database, the same files, the same settings. Lovable's own documentation puts it plainly: if you edit or delete a record your app already has, it changes for your published app too, and deleting the draft does not undo it.
Read that against a finance workload. Testing a reconciliation rule against last quarter's actuals in a draft is not a sandbox. If the prompt ends up writing to those rows, the rows are changed everywhere, and the draft is not an undo button. The documentation's advice is the right advice: create your own records to test with. In practice that means seeding a handful of clearly-labelled dummy entities and pointing every experiment at those, which is the same discipline anyone who has worked near a production ledger already has.
Some backend changes can only be made in the main version
A change to how the shared backend is configured reaches the published app immediately, so Lovable refuses to make these from inside a draft:
- Backend functions. You can edit the code in a draft, but it deploys only from the main version, after you accept.
- Sign-in methods, including social login providers.
- Secrets, the values your app uses to reach other services.
- File storage settings, such as whether a bucket is public.
- Payments, including enabling payments and creating products and prices.
- Email sending, including your domain, templates and whether the app sends at all.
Ask for one of these in a draft and Lovable tells you to make the change in the main version, then carries on with the rest of your request. Database tables and columns are a middle case: Lovable prepares the change in the draft and applies it when you accept, so a page that reads a not-yet-existing table will show an error in the draft preview, and that error is expected. Additions work this way; renaming or removing a column does not, and Lovable will reach the same result by adding rather than destroying.
One more limitation worth knowing before you build a process on drafts: they do not support Git sync yet. A draft is not a branch in your connected repository, and its code reaches the repo only after you accept it. If your team's control story depends on the repository, the draft is invisible to it until acceptance. Our guide to exporting a Lovable project covers what the repository sync does and does not give you.
Publishing to Some People and Not Others
A finance team's output is usually not meant for the whole company. Lovable separates website access from project access, so publishing never exposes the editor, the code or the chat, and it gives you three audiences: public, the whole workspace, or a custom list.
Restricting the audience requires a Business or Enterprise plan. On those plans you can also create groups, then publish to a group rather than naming people one at a time. Lovable's own documentation offers the example unprompted: restrict access to sensitive dashboards, for example financial reports for leadership only.
If you are delivering dashboards to external clients rather than to colleagues, the model is different and we covered it separately in our guide to client work on Lovable. For an internal team, groups are worth setting up even in a small team, because they survive staff changes in a way that named lists do not. Add someone to the Leadership group and every dashboard scoped to that group follows. Membership changes take effect immediately, a person can belong to several groups, and you can export group membership to CSV with who added whom and when, which is exactly the artefact an access review asks for.
Two behaviours to plan around. Project collaborators always keep access to the published app regardless of the website audience, so the audience list is not the whole access picture. And people outside the workspace who are invited to a restricted site by email are marked EXT in the audience list, and their access does not expire on its own.
The downgrade behaviour is the argument that actually decides the plan question. A restricted site stays live if the workspace drops to Free or Pro, but Lovable will refuse to publish changes to it, showing a message that publishing to the workspace requires a Business plan while the old version stays online. The dashboard does not go dark. It freezes at the last shipped version, which for a monthly reporting pack is arguably worse, because nobody notices immediately.
Offboarding: The Part Nobody Plans Until They Have To
Someone builds the close checklist, then moves to another company. What happens to the app is decided by settings you either chose in advance or did not.
When you remove a member, their workspace access and every project access is revoked immediately, and Lovable asks who should inherit the projects and folders they owned before it completes the removal. The default hands them to the remaining member with the highest role, owners first, then admins, then editors, with ties going to whoever joined earliest. You can pick someone specific instead, and you can tick a box to unpublish the transferred projects in the same step.
Four exceptions are worth writing into your own runbook.
- Restricted projects do not move. They keep the departing member as owner and have to be transferred by hand by a workspace owner, and a published Restricted project stays online.
- Personal folders go to an owner, never to the recipient you chose. Where there are several owners, the earliest-joined one receives them.
- Connections stay behind in the workspace with their existing access settings. Admins and owners can delete them, but nobody is prompted to.
- Bulk removals give you no choice. Removing several members at once, a member leaving on their own, and SCIM deprovisioning all transfer projects automatically.
Separately from removal, the primary owner can transfer primary ownership to another member or to an outside Lovable account, and that option exists on every plan. Do it before you need it, not during a handover week.
Two habits make all of this cheap. Keep the number of Restricted projects deliberately small, because each one is a manual step later. And run User insights on anyone leaving before you remove them, so you know which projects they touched rather than guessing from the dashboard.
A Workable Setup for a Finance Team of Five
Putting the pieces together, here is a configuration that holds up without being heavy-handed.
- One workspace for the finance function. One subscription, one credit pool, one place to look.
- Two owners. The finance lead as primary owner for billing, and one other as insurance. This is the clearest reason the team needs Business rather than Pro.
- Editors for everyone who builds, viewers for everyone who only reads. Nobody sits at admin unless they are managing membership.
- A workspace default credit limit, with overrides for the one or two people who actually ship. Review after the first full month against User insights.
- Groups for Leadership and for Finance, with any dashboard carrying unreleased numbers published to a group rather than to the workspace.
- Drafts for any change to how a number is derived or displayed, with a named second person accepting. Never the same person who built it.
- A small set of clearly-labelled dummy records that every experiment points at, because a draft shares the real database.
- Workspace discovery turned off unless you want it. On Business and Enterprise it is on by default, which means anyone on your company's email domain can find the workspace and request to join.
That last one catches people. It is under Privacy and security, and it is worth a look on day one rather than the day someone unexpected appears in the access-requests list.
Is Business Actually Necessary?
Honestly, not always, and it is worth being clear about where the line sits. If you are still deciding whether to build on Lovable in the first place, our full review works through that question; this section assumes you have already said yes and are choosing a plan.
A finance team of two or three who build internal tools nobody else opens can run on Pro. Pro gives custom domains, user roles and permissions, per-member credit limits and design systems, and drafts are available on every plan including Free. If that describes you, stay there.
Business earns its place at the point where access control becomes the job rather than a detail. Team workspace and role-based access, internal publish so a site is only reachable by logged-in workspace members, personal projects, SSO, the security centre and design templates are the Business line items, and groups and audience-restricted publishing sit behind it. A second workspace owner does too.
The test is simple. If there is any dashboard in your team that some colleagues should see and others should not, you need Business, because restricting a published app's audience is gated there and the downgrade path freezes your publishing rather than warning you. If everything you build is either private to the team or fine for the whole company, Pro is enough.
If you want to start building and decide later, you can open an account and try the draft workflow on the free plan, since drafts are not gated. When the access question arrives, upgrade then. And if you would rather have the workspace, roles and publishing model set up correctly the first time, you can find a certified Lovable Expert through the partner directory.
The Short Version
- The workspace is the billing, access and budget boundary all at once. One workspace per team, not per person.
- Credits are shared and plans are not priced per seat, so per-member credit limits are your real budget control. They cap build credits only, and a member who hits the cap waits until the first of the next month.
- Drafts are free to create, update, accept and delete. Only the messages inside them cost credits, so a two-person review step costs nothing extra.
- A draft shares the project's real database. Test with records you created, not with last quarter's actuals.
- Secrets, payments, sign-in methods, email sending, storage settings and backend function deploys all have to happen in the main version.
- Accepting a draft does not publish it. Publishing is a separate, deliberate act from the main version.
- Restricting who can see a published dashboard needs Business. On a downgrade the site stays up but stops accepting changes.
- Decide who inherits projects before someone leaves, and remember Restricted projects and personal folders do not follow the rule you chose.
None of this is exciting. It is the difference between a tool one person maintains and a tool a team owns, which is the difference that decides whether the thing is still running in six months.
References
Lovable, Explore changes with drafts, documentation read 26 September 2026
Lovable, Manage workspace members from the People tab, documentation read 26 September 2026
Lovable, Groups, documentation read 26 September 2026
Lovable, Introducing drafts, blog post published 7 September 2026
Lovable changelog, entries dated 3, 4, 7, 9 and 21 September 2026, read 26 September 2026
Lovable pricing page, plan cards, feature lists and credit-tier dropdowns read in a browser on 26 September 2026
About the Author
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in on Lovable and works on finance and trading software. You can find his Expert listing 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.