The MVP Features That Are Actually Just Multi-Tenancy in Disguise

When discussing MVP scope, the conversation typically revolves around which features to prioritize and which to defer to later versions. However, some decisions within this scope are not truly about features at all, but rather architecture decisions that masquerade as minor scope considerations. These decisions prove far more costly to alter once the product has launched.

One such decision is whether users can belong to more than one workspace. At first glance, it may appear to be a simple toggle. However, this actually pertains to how the relationship between users and tenants is modeled in the database. Implementing this after launch often requires a schema migration that affects every table referencing a user, not just adding a join table.

If there is any possibility of this requirement emerging in the first year, it is prudent to establish the appropriate data model from the outset, even if the associated UI is delayed.

Another consideration is the need for custom roles per customer. Initially, "admin" and "member" roles may suffice for most users. But when an enterprise prospect requests a "billing viewer" who cannot modify settings, the two-role system proves insufficient. Permissions systems are often far more cost-effective to implement with built-in flexibility, even if only two roles are initially offered, rather than retrofitting the system later when customers rely on the existing permissions structure.

The question of whether each customer should receive a subdomain also seems superficial — "acme.yourapp.com" may feel like an aesthetic preference. However, adopting subdomain-based tenancy entails significant architectural implications, including routing, SSL certificate provisioning, session management, and potentially impacting the authentication flow. Deciding on this approach after already having customers live under a shared URL structure necessitates a migration, not simply a configuration change.

Designing for data export and customer departure is another critical factor. While nobody anticipates building this functionality for an MVP, having a clean tenant boundary from the beginning streamlines the eventual export or deletion process. Without this boundary, removing a single customer's data can transform into a multi-year project entailing complex joins and shared tables.

Lastly, determining whether the product will support a single pricing plan or multiple plans can also have far-reaching consequences. Launching with a flat price is an effective strategy for validating the MVP. However, embedding this assumption into billing logic with the implication of a single price forever — without provisions for tiered pricing or separation between what a customer is billed and what they are entitled to — can prove costly to rectify later.

Allocating fields for plan tiers and maintaining a clear distinction between billing and entitlements incurs minimal additional effort, yet saves substantial resources in the long run. The key takeaway is not to over-engineer the MVP, but rather to identify which seemingly small decisions are, in fact, architectural decisions, and address them proactively before writing the first migration script.