Apply the boundary test

Treat the project as multi-tenant when any answer is yes:

  • Do clients sign in?
  • Does each client see different private data?
  • Can a client upload or retrieve files?
  • Are there roles inside one client organization?
  • Can a user change a business record or trigger a notification?
  • Must a forgotten or compromised account be recovered safely?

The OWASP Authorization Cheat Sheet emphasizes server-side authorization on every request. A login page proves identity at one moment; it does not prove that every query, object, export, and file is scoped to the right client.

Identify hard stops

Pause a custom build when the team cannot answer:

  1. Which system is authoritative for identity and client membership?
  2. How is client scope applied to every server request?
  3. How will simultaneous-client isolation be tested?
  4. Who handles invitation, recovery, suspension, and offboarding?
  5. Where do private files live and how are they retrieved safely?
  6. Who responds to a wrong-client disclosure or account compromise?

A failed hard stop cannot be offset by a small user count or attractive prototype.

Do not estimate risk by storage volume

Four PDFs per client can still require private registration, password recovery, correct authorization, retention, and incident response. The OWASP File Upload Cheat Sheet shows that uploads introduce decisions about names, types, sizes, storage, authorization, scanning, and retrieval.

The question is not whether the database is large. It is whether a plausible mistake exposes one client's information to another.

Consider narrower alternatives

Before building:

  • configure an established client or document portal;
  • keep private files in a purpose-built service and make the website a navigation layer;
  • send clients authenticated links generated by an existing system;
  • build only an internal staff queue while clients continue through a trusted channel; or
  • remove private data and keep the page informational.

Verify current product capabilities and plan limits directly. A thinner custom layer can preserve the distinctive workflow without accepting identity, storage, and isolation as new product responsibilities.

Write the decision record

Use five sections:

Section Decision
Users Identities, organizations, roles, recovery
Data Private fields, files, retention, authoritative system
Boundaries Server-side scope and isolation evidence
Failure Consequence, detection, responder, containment
Narrowing Capability delegated or removed

Choose buy/configure when established software handles the important job. Choose build narrowly only when the remaining custom workflow is material, the hard stops have owners, and isolation can be independently tested. Otherwise choose investigate or do not build.

This decision record does not certify an architecture. It prevents a multi-tenant system from being approved as if it were a homepage.