If you are building software for programs, networks or franchises, you hit the same question early: one deployment per customer, or one app that serves them all?

I faced that with Mentor Intelligence, the operating system for venture mentor programs. It handles intake, the mentor roster, AI team matching and rallies for independent chapters on one platform. A network of more than 130 chapters needed the same product to work for each chapter without any data crossing between them.

Here is how I approached it, and what I would tell any founder or CTO facing the same decision.

The problem behind the architecture

Before the product, chapters ran their mentor programs on spreadsheets, email and a generic CRM. Applicants lived in one sheet, mentors in another, and the three-mentor team for each founder got assembled from memory.

Staff needed one place to track applicants, keep the roster current, see where the roster was thin, and build the right team for each pitch. And each chapter wanted its own brand.

That combination of shared product, separate data and individual branding is common. It shows up in franchise tools, school platforms, association software and anything sold to a network.

One app, one database, tenancy on every row

I had two realistic options: a separate deployment per chapter, or one app with tenancy built into every row of data.

Separate deployments feel safer at first. But they multiply every upgrade, every migration and every bug fix by the number of customers. For a solo build serving a large network, that was not workable.

So Mentor Intelligence is one app with one database:

  • Every operational row carries an organization id.
  • Row-level security in the database enforces it, so a query for one chapter cannot return another chapter's rows.
  • Feature flags and theme tokens brand each chapter.
  • A signed-in user with no membership sees nothing until they are invited.

The trade-off is that every query carries tenancy, and a single mistake could leak data. So I do not trust row-level security, I test it. The isolation rules run in continuous integration, not just in my head.

What to take from this: if you choose shared infrastructure, make isolation a database rule rather than an application habit, and test it automatically. A rule that lives only in application code will eventually be forgotten in one query.

Ship the migration in usable steps

A working static prototype already existed, and chapters wanted it live fast. I could have kept extending the prototype, rebuilt everything on a full stack in one go, or ported it in steps.

I ported it in seven steps, each one shippable on its own:

  1. Shell and navigation.
  2. Ported pages.
  3. Typed models and seed data.
  4. Real persistence with row-level security.
  5. Server-side AI.
  6. Role-based visibility.
  7. Tests and continuous integration.

That made the first week slower. In return, sign-in, persistence and data isolation were in place before the first real user arrived, rather than being bolted on after people were already depending on the product.

What to take from this: when you move from prototype to production, sequence the work so every step leaves you with something that runs. The order matters too. Get the boring foundations of identity, persistence and isolation in before real data shows up.

Keep AI advisory when people are accountable

Mentor Intelligence uses AI to help staff build teams, but with clear limits. The AI should help without inventing facts or changing data on its own.

So AI runs on the server and only for staff and admins. When a founder submits a pitch video or document, the system extracts their needs and shows them to staff for editing before anything is saved. The model never writes to the database. The in-app assistant acts as the signed-in staff member, and only after they confirm the listed steps.

That means more clicks per task. But every change traces to a person, and that is what a program director has to be able to say.

Every change should trace back to a person, especially when AI helped make it.

The same thinking applies to how the product was built. Coding agents worked under a written set of rules: no production data, preview before production, and public claims need evidence.

Design for the work people actually do

Multi-tenant architecture is only worth it if the product inside it is useful. A few features came straight out of how chapters actually work:

  • Team matching ranks mentors for a founding team or an open seat, with the reason each one fits.
  • Roster gaps turns the mentor network into a recruiting plan: coverage by experience area, balance warnings, and a recruitment brief staff can copy.
  • The mentor directory keeps availability, hours and recent events on every profile, so nobody is matched from memory.
  • The company directory flags any venture left without a team.

None of these is technically complex. Together, they replace the spreadsheet with something staff trust.

The short version

If you are building for a network of programs or organizations:

  1. Prefer one app with tenancy on every row over a deployment per customer.
  2. Enforce isolation in the database and test it in continuous integration.
  3. Ship the move to production in steps that each work.
  4. Keep AI advisory where people are accountable for the outcome.

Mentor Intelligence is live with its first chapter, with more onboarding. If you run a program, network or platform that needs this kind of shared but separate product, email me and we can talk it through.