Your app works for one customer. What happens when you add the second?

Your first customer can make an app look more finished than it is. They sign in, upload their files, run a report and get the right answer. Everyone is pleased.

Then you add a second business. Now the question is whether that same report can include somebody else's information.

If you're turning an internal tool into a product, this deserves a place in the budget before you start selling access. Adding another company changes what the software has to guarantee. A company selector in the navigation doesn't settle it.

On September 24, Cloudflare disclosed a storage isolation flaw affecting Containers and Sandboxes. Researchers recovered residual data from other workloads. Cloudflare says it fixed the issue and found no evidence of malicious exploitation in the telemetry available to it.

That was an infrastructure problem, different from a missing check in a business app. I'm not suggesting your application has the same flaw. It is a timely reason to ask where customer separation actually gets enforced.

A customer account needs an owner for every record

Consider a fictional quoting tool built for a decorating company. It stores customer addresses, room measurements, estimates and photographs. The owner likes it enough to offer the same software to other decorators.

In the original tool, “show all estimates” may have been a perfectly reasonable instruction. There was one business. After the change, it must mean “show the estimates this person is allowed to see for this business.” An estimate also has attachments, line items and perhaps a PDF sitting in file storage. Those need the same answer about ownership.

Developers usually call each customer organization a tenant. One person might belong to several tenants; several people might belong to one. Deciding that relationship is part of designing the product.

AWS's guidance on tenant isolation makes a useful distinction: passing the login and access checks at an application's entrance doesn't, by itself, establish isolation throughout the system.

For our decorating example, a successful login tells us who is asking. The next decision is whether that person may read or change this particular estimate. “They're a paying customer” is too broad an answer.

Follow the estimate out of the dashboard

I would ask the team to walk one fictional estimate through its whole life. It starts as a draft, gets a photograph, becomes a PDF, goes to the homeowner and appears in a monthly report. This gives the discussion something concrete to follow.

Suppose the dashboard correctly shows only the first decorator's estimates. A separate report generator still uses the original instruction to collect every estimate. The dashboard looks right while the monthly download is wrong. That's an illustrative failure, not a finding about a real client system.

The engineering review needs to follow the paths the customer cannot see. OWASP's multi-tenant security guidance covers verifying organization membership on the server and carrying that verified scope into storage, caches and background work. Choosing a company in the browser is a request to act within that company; the server still has to check permission.

For the founder, the useful deliverable is an explanation of how those rules cover the product's actual features. A diagram with two boxes labelled “Customer A” and “Customer B” isn't enough to assess whether an overnight report uses the right records.

Ask for two ordinary test customers

Before approving this part of the build, I would want a review using two fictional companies, clearly different sample records and ordinary customer accounts. Both companies should be able to finish their own work. The team should also demonstrate that one cannot read or change the other's private records, including through downloads and exports.

Use test organizations you control, in an authorized test environment. Real customers' information has no place in this exercise.

Give the two decorators recognizably different sample jobs. One quotes a blue kitchen; the other a green hallway. When a PDF, search result or scheduled report appears, the reviewer has a simple way to spot a mix-up. Then ask what automated checks will keep covering those cases after the next release.

This is a review of a defined requirement, not a complete security assessment. Passing it doesn't establish that every feature or deployment is secure. It does give you better evidence than watching a developer switch between accounts with an unrestricted administrator login.

Write down any deliberate sharing too. Perhaps an accountant is invited into both businesses. Their access should follow those invitations, while a decorator's receptionist remains limited to the company that hired them. A useful review includes permitted access as well as denied access.

Decide the boundary before pricing the expansion

I wouldn't assume that every new business needs its own server. AWS describes both dedicated resources and separation enforced within shared resources. The appropriate choice depends on the product and its requirements. More infrastructure is not, by itself, evidence of a better design.

I would ask for a short scope that names the customer-owned records, the permitted sharing, the features being checked and the evidence you'll receive. That lets you price a meaningful piece of work. “Make it multi-tenant” leaves too much room for the buyer and developer to imagine different outcomes.

For the decorating tool, an initial release might support estimates and PDFs for several businesses while keeping a complicated cross-company reporting feature out of scope. That is a decision a founder can make. Quietly assuming every existing feature is ready for multiple businesses is harder to defend.

If you're at this point, Rosecraft's technical assessment and strategy work can help define what needs checking before you commission the expansion. Tell us what the app does today and who needs to use it next. A clear account of those two things is a useful place to start.

Cover: AI-generated illustration using fictional customer files.