SISO: from an operational need to a multi-tenant SaaS platform

I designed and built a multi-tenant SaaS platform from scratch to digitize healthcare operations. The product evolved from a clinical solution into a reusable core for multiple verticals, including dental and veterinary.

My role: Product Manager / Product Owner, Own product

The problem

The starting point was a common need in practices and healthcare organizations: information and tasks spread across schedules, patient records and manual processes, with little automation and limited operational visibility. The challenge was to build a digital solution without creating a different product for every customer while retaining the ability to expand into new specialties and business models.

Discovery

Discovery focused on the operational flows that could concentrate the most value in an initial product: patient administration, professional schedules and availability, appointments, roles and permissions, follow-up and metrics. As the product evolved, learning led to modular licensing, recall automations and new verticals. Each new capability is evaluated by the problem it solves, its reuse across tenants and the complexity it adds.

Decisions and trade-offs

Build a multi-tenant core instead of one application per customer
I defined an architecture with a central master and independent tenants. The master manages tenants and their configuration while each organization keeps its own data. This allows a single product to evolve for multiple customers while maintaining data isolation.
Ruled out: Creating an independent installation for every customer would have simplified some initial scenarios, but increased maintenance, duplicated deployments and made centralized product evolution more difficult.
Separate capabilities through licenses and modules
I introduced a licensing model with plans, validity periods, usage limits and configurable modules. This allows the capabilities available to each tenant to be configured and prepares the product for different service levels.
Ruled out: Enabling every feature for every customer reduced initial complexity, but limited the ability to differentiate plans and evolve toward a scalable commercial model.
Decouple automations from the transactional core
For processes such as inactivity recall and appointment reminders, I separated transactional logic from orchestration. The backend identifies and exposes the required information and records the outcome, while automation workflows manage execution and communication channels.
Ruled out: Implementing every automation directly inside the core would have reduced external components, but created tighter coupling and made it more expensive to modify rules, frequencies or communication channels.
Evolve from a clinical vertical to a reusable core
When adding the veterinary vertical, I reused common capabilities such as users, customers, scheduling, permissions, licenses and automations while separating vertical-specific models and processes. This enabled SISO Pet without building a second platform from scratch.
Ruled out: Building a completely independent veterinary product offered greater initial freedom, but required duplicating authentication, scheduling, licensing, automations, infrastructure and future product evolution.

Results

SISO evolved from a clinical management solution into a multi-tenant SaaS platform with tenant provisioning, roles and permissions, patient and customer management, scheduling and availability, appointments, module-based licensing, metrics and follow-up automations. The same core supports CLINIC and VET verticals, with veterinary-specific entities and workflows such as pets and veterinary care. The product is still evolving and undergoing commercial validation, so current results are expressed in built capabilities, core reuse and functional scope rather than adoption or growth metrics.

Key learnings

Building my own product reinforced a core idea in how I work: an architecture decision can also be a product decision when it determines how a solution scales, is commercialized and evolves. The main lesson has been balancing user value, delivery speed, reuse and technical debt, avoiding both designing only for the immediate use case and over-engineering before validation.