Adding Teams and Company Accounts to an AI-Built App: What Needs to Change?

TL;DR

• Separate a person's login from their membership in a company. The same person may need different permissions in different workspaces.
• Keep record ownership separate from authorship. Removing an employee should not silently delete the company's projects or documents.
• Define invitation, role-change and removal behaviour before building the member-management screen.
• Test with two companies, including forbidden reads and writes, file access, exports and an already-open session after removal.
• Scope the first release around the customer's actual team workflow. Adding company accounts does not automatically require new hosting or a full rewrite.

Start with the work the first company needs to share

For example, suppose you built a project-tracking app in Lovable. A customer now wants five employees to use it. They need shared projects, someone who can invite colleagues, and a read-only role for a reviewer. When an employee leaves, the projects must remain available to the company.

Write those requirements before asking for a team-management screen. A list of invited email addresses does not yet explain who owns a project, whether colleagues can edit it, or what happens to work created before the company account existed.

This is a hypothetical product scenario, not a Caemcore client case. The model and tests below are a proposed way to scope it, not a specification that fits every app.

Also distinguish your customers from your builders. Lovable's project-access settings govern access to the editor, source code and work in progress, separately from access to the published app. Inviting a colleague to build with you is not the same task as giving a customer's employees different rights over business records inside your product.

Separate the person, the company and the record

For this scenario, use the following model as a discussion document. The exact database tables can differ; the relationships need to be explicit.

The important change is that the person who created a project need not own its continued existence. Preserve an author reference for history while assigning the shared project to its company workspace. Check deletion rules too: removing a membership must not trigger deletion of company work through an old dependency on the user account.

Avoid putting one global role on the person. In our example, Alex can administer Company A while only reviewing work in Company B. A single is_admin flag cannot express that distinction without additional context.

This does not necessarily mean building identity management from scratch. Clerk's Organizations model, for example, supports users belonging to multiple organizations and supplies membership and active-organization context. The application still needs rules connecting that context to its own projects and actions. Evaluate the provider already in use before replacing it.

Define what each role can actually do

Write permissions as actions on records. For the example, an owner might manage members and transfer ownership, a member might create and edit company projects, and a viewer might only read them. Decide separately whether a viewer may download files or export all records. Reading one screen and downloading a company-wide export are different capabilities.

Require an explicit rule for granting roles. A member who cannot manage access should not be able to promote themselves by changing a submitted role value. An administrator should not gain powers in another company merely by switching a workspace identifier.

AWS distinguishes tenant isolation from ordinary authentication and role checks. Here, a tenant is the customer workspace whose resources must be kept separate. A successful login proves neither that the person belongs to this workspace nor that the requested project is inside it.

For every company-scoped operation, ask the developer to show the connection between the authenticated user, their current membership, the requested action and the record's company. Values sent from the browser can select a workspace; they must not establish permission by themselves. OWASP's authorization guidance calls for checks on every request and enforcement outside client-side controls.

For an app using Supabase, row-level security can enforce access rules inside Postgres. Ask which tables and operations the policies cover and which backend paths use privileged access. An administrative connection can bypass those policies, so a successful database-policy test does not prove every application route is protected.

Design joining and leaving before the invitation screen

For the first release, write a small invitation contract: which company issued the invitation, who may accept it, which role is offered, when it expires and who may cancel it. Specify the result when the recipient already has an account. An invitation should not silently create a second identity or overwrite membership in another company.

Include failure cases in the demo: a cancelled invitation, a reused acceptance link and acceptance while signed in as the wrong person. The point is to agree observable outcomes, not prescribe a particular invitation library.

Offboarding has a different requirement. Remove the person's membership in the company, preserve the company's records and leave unrelated memberships intact. Transfer the last owner's responsibility before allowing that owner to leave, or define a controlled recovery route.

Check an already-open session. Supabase explicitly warns that team membership stored in a JWT, the signed access token, is not updated until that token refreshes. A changed member list does not prove an old session lost permission. Ask how the implementation checks current access and what delay, if any, remains.

For confidential company work, prefer enforcement that refuses new protected operations after removal rather than relying solely on a long-lived role claim. Record any exception so the customer knows what removal actually does.

Carry company context beyond the dashboard

Inventory every place that can return or change company information: project screens, search, exports, file downloads, integrations and scheduled work. A background export needs to know which company's records it may include even though nobody is currently viewing that workspace.

OWASP's multi-tenant guidance covers verified tenant context, cache isolation and delayed work. Applied to this example, a queued report should retain its authorized company context and recheck time-sensitive recipient access before delivery. A cache entry must not return Company A's results to Company B.

Test workspace switching in two browser tabs as well. Clerk documents a specific distinction between per-tab active organizations and the shared session cookie. You do not need Clerk to have this requirement: a save action must target the company shown on the form, or ask the user to resolve a context change. It must not silently write into the workspace selected in another tab.

Files deserve their own check. Supabase distinguishes authenticated downloads from time-limited signed URLs. Its signed URLs remain valid until expiry despite Auth-key changes. Agree how issued links are handled when membership ends; removing a person from a list is not evidence that every previously issued download link stopped working. Files already downloaded cannot be recalled by an application permission change.

Decide which existing records become company records

Do not replace every user_id with a company identifier. Some references describe authorship; some records may still be private; others genuinely belong to the new company workspace.

For the hypothetical app, ask the customer to identify the projects that should become shared. Map each selected project and its documents, comments and history to the intended workspace. Keep personal projects separate unless their transfer has been explicitly agreed. An email domain is not sufficient evidence of record ownership.

Rehearse that mapping in an isolated environment. Use named test records whose destination is known. Confirm that both an authorized colleague and an unrelated user get the expected result after migration. A matching total project count would not reveal that two companies received each other's projects.

Before the live switch, define where new projects and edits go during the transition. Choose an agreed write pause or a method for capturing changes, and explain how post-switch records survive a rollback. Moving existing data and enabling new team accounts are related delivery tasks, not interchangeable ones.

Accept the feature with two companies, not one administrator

Use this rehearsal with synthetic accounts and files in a non-production environment. For the example, create Company A and Company B. Alex owns A and is a viewer in B. Morgan is a member of A only. Casey owns B and has no membership in A.

The developer should record the request, affected record and result for each check. A hidden button or a screenshot of the correct dashboard is not enough evidence.

1. Join the intended workspace. Invite a new test user to A as a viewer. Confirm the accepted membership and test the cancelled, reused and wrong-account cases. No membership in B should appear.
2. Share work without sharing a login. Morgan creates a project in A. Alex can use it under the agreed role. The project keeps Morgan's authorship and A's ownership. Test that a viewer cannot edit or grant themselves a stronger role.
3. Cross the company boundary deliberately. As Casey, attempt to retrieve, change and export A's test project through direct requests. Include its file and a search for its distinctive title. Also try attaching A's document to B's project. These attempts must not disclose or modify A's data.
4. Keep roles separate across tabs. Open A and B as Alex. Confirm that owner rights in A do not enable edits in B. Save from a form left open while switching the other tab; the action must not land in the wrong company.
5. Remove a member while they are signed in. Remove Morgan from A, then attempt a new read, edit, export and file request from the existing session. Check queued notifications and previously issued links against the agreed removal policy. Alex must still find the company's project.
6. Transfer responsibility without losing work. Transfer ownership of A to another authorized member before Alex leaves. Confirm that A remains manageable, its records remain intact and Alex's separate membership in B is unchanged.
7. Reconcile the migrated sample. Verify each selected project's company, related records and history. Check that deliberately retained personal projects remain private. Repeat the original individual-user workflow as a regression test.

This is a feature-acceptance exercise, not a complete security assessment. Extend it for the app's real roles, integrations and sensitive operations. Keep the repeatable checks with the project so later changes can be tested against the same boundaries.

Does this need an extension or a rebuild?

Start by tracing one company-owned project through creation, editing, export and member removal. Ask the developer to identify the assumptions that prevent the required behaviour and show where they live.

An extension is a credible option when the existing identity provider can remain, company ownership can be introduced consistently, and the affected access paths can be updated and tested without replacing unrelated workflows. Existing screens, hosting and payment integrations may remain useful.

A deeper redesign deserves investigation when personal ownership controls almost every operation, access rules conflict across the codebase, or records cannot be assigned to companies without changing core relationships. Even then, replacing the membership or data-access layer is a different scope from rebuilding the whole product. Our fix-or-rebuild decision guide explains how to ask for evidence behind that larger recommendation.

Neither choice automatically requires a separate database for each company. OWASP describes shared-table, separate-schema and separate-database approaches, each with enforcement and operating requirements. Choose the boundary the customer actually needs, then test it. A database count is not an acceptance criterion for this feature.

Keep the first release narrow. If the customer needs shared projects and two working roles, do not automatically add departmental hierarchies, custom role builders or a new billing system. For a company-paid plan, specify which workspace the subscription covers and who may manage it; an employee leaving should not accidentally become a subscription-cancellation event.

Ask the proposal to identify retained components, changed data relationships, existing-record migration, access tests and rollout responsibilities. The useful deliverable is a team workflow that passes those conditions, not just an invitation screen or a repository described as multi-tenant.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Built it on no-code or AI tools and it stopped changing? We start with an audit, not a quote. 30 minutes, free: what we keep, what we rebuild, what blocks launch, the range and the timeline.

You get that whether we work together or not.

FAQ

Do company accounts require single sign-on?

No. Company membership and single sign-on answer different questions: which workspace a person belongs to, and how they prove their identity. Clerk documents invitations and enterprise identity connections as separate onboarding options. Ask the customer whether signing in through its identity provider is a purchasing requirement. Price and test that integration separately rather than assuming every team account needs it.

Can a contractor see just one project instead of the whole company?

Yes, if the access model includes a project-level relationship or equivalent restriction. Specify the allowed project and actions, not only a role called guest. Test the restriction in search, files and exports as well as the project screen. A role that grants workspace-wide reading is not suitable merely because its label sounds limited.

Should pending invitations count as paid seats?

That is a product and billing decision. State whether a seat means an invitation, an accepted membership or a paid entitlement assigned by an administrator. Define what happens when an invitation expires or a member is suspended. Keep the displayed seat count and billing calculation based on the same rule; do not let the invitation screen choose the pricing model accidentally.

What happens to a personal paid account when the user joins a company?

Agree which subscription pays for future use and which records, if any, move into the company workspace. Joining a company should not silently transfer private projects or create overlapping charges. Provide a reviewable transfer step for selected records and confirm what remains personal. The required behaviour depends on the product's existing plans, not just its new membership table.

Can our support team access a customer workspace?

Treat support access as a separate, explicitly authorized capability. Define who can grant it, its scope and duration, and the actions recorded for review. Prefer a limited view or synthetic reproduction where that resolves the issue. Do not give every customer administrator platform-wide support powers, and test how temporary access is withdrawn.

Sources

• Lovable, Control project access. Checked 13 September 2026.
• Clerk, Organizations. Checked 13 September 2026.
• AWS, Tenant isolation. Checked 13 September 2026.
• OWASP, Authorization Cheat Sheet. Checked 13 September 2026.
• Supabase, Row Level Security. Checked 13 September 2026.
• OWASP, Multi-Tenant Application Security Cheat Sheet. Checked 13 September 2026.
• Supabase, Serving assets from Storage. Checked 13 September 2026.

The project-tracking app, example memberships and acceptance rehearsal are hypothetical. They illustrate a proposed requirements review, not Caemcore client results or a complete security assessment.