You built a tool that solves a real problem for one business. Another business wants it. It feels as though you should be able to add another login and start charging.
That second customer changes the question. Can the product keep two businesses separate, support their different users, and handle routine work without you editing the database every time?
A second business is more than a second user
Consider a hypothetical AI tool that searches a company's proposals. For the first business, every signed-in person may be allowed to search the same documents. For the second, the application must know which business each request belongs to and enforce that boundary throughout the system.
That includes uploaded files, search indexes, AI retrieval, exports, background jobs, and support tools. A company selector in the interface is useful navigation. The server still needs to check that the person making the request belongs to the selected company and has permission for that action.
One person may also belong to two businesses. Treating an email address as if it identifies exactly one company can create awkward product restrictions and permission mistakes.
Choose a separation model deliberately
You could run a separate deployment for each customer, or build a shared application that manages multiple organizations. There are also arrangements between those two choices.
Separate deployments can simplify some boundaries while multiplying upgrades, monitoring, and support work. A shared application can make common improvements easier to deliver, but requires carefully enforced organization boundaries. Neither choice removes the need for permission checks and operational discipline.
For a Supabase-based product, row-level security can enforce database access rules. It is one part of the design: file access, privileged server operations, and other services still need attention.
Write down the ordinary customer lifecycle
Before building a sophisticated administration dashboard, describe what must happen when a customer joins, changes their team, and leaves:
- Who creates the organization and becomes its first administrator?
- How are teammates invited, assigned roles, and removed?
- Who owns the subscription, and what happens when payment fails?
- How does a customer export their information or request deletion?
- How can support investigate an issue with appropriate, limited access?
Some early operations can be manual. The important distinction is whether that manual work has an owner, a repeatable procedure, and appropriate access controls. An undocumented database edit by the founder is difficult to turn into reliable customer support.
Prove the second customer can operate independently
Use two fictional organizations with dummy documents and different team roles in a test environment. Verify both allowed actions and denied actions, including direct requests outside the interface. Remove a member, switch between organizations, and run background processing for each.
Then assess whether the product can onboard and support a small pilot without constant intervention. Include operating costs and the work needed to maintain customer-specific settings. A successful technical demo does not establish that a subscription business will be profitable.
Five prompts to use with your AI coding assistant
Before you begin: Use the same project conversation for all five prompts. Inspect first, approve the plan yourself, and never test against live customer data or secrets.
These prompts assume your assistant can inspect the relevant project. Ask it to say clearly if it cannot. Use the prompts one at a time, reviewing each response before moving to the next step.
1. Map
Find all single-organization assumptions in users, records, permissions, settings, uploads, integrations, jobs, and billing. Explain the current architecture with file references.
2. Audit
Identify missing organization membership, tenant data boundaries, roles, onboarding, and customer-specific configuration. Distinguish productization requirements from present access-control defects.
3. Plan
Propose a phased multi-organization design and migration plan, covering tenant identifiers, permissions, billing boundaries, existing data, and minimal v1 scope.
4. Challenge
Review edge cases: users in multiple organizations, administrator changes, invites, account removals, integrations, and exports. Test design assumptions with synthetic organizations.
5. Implement
After approval, build only the agreed stage in a test environment, with tests for organization isolation and migration safety. Never restructure live customer records without separate authorization.
The useful next deliverable is a productization plan: organization model, access rules, customer lifecycle, operating responsibilities, and the smallest credible pilot. DitchNow can help define that through an MVP scope and build plan and deliver the agreed product through an end-to-end build. Bring the existing tool to a first conversation.
About DitchNow
DitchNow is based in Haarlem, Netherlands, and helps founders and teams fix and extend software and put AI to work. Meet DitchNow.