🧠 SaaS, Multitenant e PWA na prática: o que aprendi criando o IntegraPsi

🌌 CodeVerse2026 | Artigo #21

🧑💻 Fala, Galera Dev! 👋

Quem acompanha o CodeVerse viu que no último artigo apresentei o MeuPet, um sistema de gestão para clínicas veterinárias. Naquele projeto comecei a explorar mais alguns conceitos relacionados à criação de um SaaS e principalmente a ideia de permitir que várias empresas utilizem uma mesma aplicação. Mas dessa vez resolvi ir um pouco além.

O projeto que quero mostrar é o IntegraPsi, uma plataforma que desenvolvi pensando na rotina de psicólogos e clínicas de Psicologia. Além de apresentar algumas funcionalidades do sistema, quero aproveitar o projeto para explicar três conceitos que aparecem cada vez mais quando falamos de aplicações modernas: SaaS, Multitenant e PWA.

E quero fazer isso de duas maneiras: primeiro olhando um pouco para o lado técnico e depois tentando explicar cada conceito como explicaria para alguém que nunca escreveu uma linha de código, afinal ficar ouvindo essa sopa de letrinhas já foi um grande desafio para mim, e por isso quero compartilhar um pouco do que aprendi na minha trajetória. Porque entender o nome é a parte fácil mas o interessante é entender o que realmente acontece por trás dele.

🧠 De onde surgiu o IntegraPsi?

O IntegraPsi nasceu inicialmente de um projeto acadêmico que estou desenvolvendo relacionado à Psicologia. Durante a elaboração comecei a pensar: se eu fosse transformar algumas dessas ideias em uma aplicação real, como seria um sistema que ajudasse o psicólogo não apenas a registrar informações de seus pacientes, mas a administrar boa parte da rotina da clínica?

A partir daí comecei a estruturar o projeto. Antes de partir para o desenvolvimento, novamente trabalhei bastante no PRD — Product Requirements Document, definindo funcionalidades, usuários, permissões, fluxos, regras de negócio e principalmente quais informações cada perfil poderia ou não acessar.

O resultado foi crescendo. Hoje o sistema possui gerenciamento de pacientes, agenda, prontuários, instrumentos de acompanhamento, registros, acesso do paciente e uma camada administrativa da própria plataforma. O psicólogo consegue trabalhar dentro da clínica enquanto existe outra camada responsável por administrar as clínicas e contas que utilizam o IntegraPsi.

E foi justamente aí que o conceito de SaaS e Multitenant deixou de ser apenas algo que eu lia e passou a ser um problema que eu precisava resolver no código.

Dashboard do software - IntegraPSI

☁️ Afinal, o que é SaaS?

Começando pela definição mais técnica: SaaS significa Software as a Service — Software como Serviço.

Em vez de entregar uma cópia do software para cada cliente instalar em seu próprio computador ou servidor, mantemos uma aplicação centralizada e disponibilizamos seu uso pela internet. O cliente acessa o serviço e utiliza as funcionalidades que aquela plataforma oferece.

Isso permite trabalhar, por exemplo, com planos, assinaturas, diferentes níveis de acesso, atualizações centralizadas e vários clientes utilizando o mesmo produto. Um bom exemplo é a Netflix que não precisa instalar um servidor de streaming na sua casa. Outro exemplo é o Gmail que não precisa entregar um servidor de e-mail para cada usuário. Você acessa um serviço que está disponível na internet.

No meu caso, a lógica seria parecida.

Eu não precisaria criar: integrapsi-clinica-a.com
Depois copiar todo o código e criar: integrapsi-clinica-b.com
E depois novamente: integrapsi-clinica-c.com

A ideia é existir um IntegraPsi capaz de atender diferentes clientes. E aí começa outro problema.

Se várias clínicas utilizam a mesma aplicação, como impedir que uma veja as informações da outra?

É aqui que entra o Multitenant.

🏢 O que é Multitenant?

Tecnicamente, uma arquitetura multitenant permite que múltiplos clientes, chamados de tenants, utilizem uma mesma aplicação enquanto seus contextos e dados permanecem logicamente isolados. No IntegraPsi, um tenant pode representar uma clínica.

Para conseguir entender melhor, imagine:

IntegraPsi
│
├── Clínica A
│   ├── Psicólogos
│   ├── Pacientes
│   ├── Agenda
│   └── Prontuários
│
├── Clínica B
│   ├── Psicólogos
│   ├── Pacientes
│   ├── Agenda
│   └── Prontuários
│
└── Clínica C
  ├── Psicólogos
  ├── Pacientes
  ├── Agenda
  └── Prontuários

Todos estão utilizando o mesmo produto, mas cada clínica precisa enxergar somente aquilo que pertence ao seu contexto.

E isso não pode depender apenas da interface esconder um botão ou determinada página. A aplicação precisa controlar autorização e isolamento de dados no backend, e isso não é tão simples assim. Agora vamos tirar a programação da conversa.

🏨 Multitenant explicado como um hotel

Imagine um hotel. O prédio é o IntegraPsi. Cada quarto é uma clínica.

Todos utilizam a mesma recepção, os mesmos corredores, os mesmos elevadores e a mesma estrutura do prédio. Mas receber a chave do quarto 201 não significa que você pode abrir o 202, 301 ou 402. Sua chave determina onde você pode entrar.

No software, podemos imaginar que acontece algo parecido:

Aplicação = hotel
Tenant = quarto
Usuário = hóspede
Autenticação = identificação na recepção
Permissões = chave de acesso

Só existe uma diferença importante: em um sistema que trabalha com informações sensíveis, uma porta aberta no lugar errado pode ser um problema muito maior.

Por isso arquitetura multitenant não significa simplesmente colocar um campo clinica_id no banco de dados. É necessário garantir que aquele usuário realmente pertence àquela clínica e que as consultas realizadas pela aplicação respeitem esse isolamento.

🛡️ E foi aqui que comecei a enxergar segurança de outra maneira

Quando construí a primeira versão, uma das minhas preocupações foi justamente não tratar o multitenant apenas como uma funcionalidade visual. Não adianta o usuário entrar na Clínica A e a interface mostrar somente os pacientes da Clínica A se ele conseguir alterar um ID em uma URL e acessar alguma informação da Clínica B.

Isso seria uma falha de autorização.

Também existem diferentes papéis dentro de uma clínica. Um psicólogo precisa acessar informações clínicas que não necessariamente deveriam estar disponíveis para alguém responsável apenas pela parte administrativa ou financeira.

Quando começamos a trabalhar com múltiplos tenants, autenticação responde principalmente:

Quem é você?

Mas autorização precisa responder:

O que você pode fazer?

E o contexto do tenant ainda acrescenta:

Dentro de qual organização você pode fazer isso?

Essa separação foi uma das coisas mais interessantes que aprendi colocando o conceito em prática.

👨💼 Mas quem administra todas essas clínicas?

Aqui criei outra camada no IntegraPsi: a Administração Global. Esse usuário não é simplesmente "mais um psicólogo". Ele administra a própria plataforma.

No painel consigo visualizar as clínicas cadastradas, psicólogos, contas ativas e convites pendentes, além de executar algumas operações administrativas. Isso cria duas visões completamente diferentes:

ADMINISTRAÇÃO DA PLATAFORMA
      ↓
 IntegraPsi SaaS
      ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
Clínica A Clínica B Clínica C
 ↓      ↓      ↓
Usuários e pacientes de cada clínica

Essa separação me ajudou bastante a entender que desenvolver um SaaS não significa apenas criar as telas que o cliente utiliza. Existe também o software que administra o próprio software.

tela do admin geral

📱 E então apareceu outro conceito: PWA

Outra funcionalidade que quis experimentar no IntegraPsi foi criar uma experiência específica para o paciente. O psicólogo pode liberar o acesso e o paciente passa a ter uma área própria para interagir com determinados recursos disponibilizados para ele, como atividades e registros de acompanhamento.

Esse ao meu ver é um dos maiores pulos do gato, pois assim, o psicólogo consegue ver em tempo real o desenvolvimento de seus paciente, observando como estão entre as consultas. Pois muitas das vezes é esquecido fatos que ocorrem no período entre uma consulta e outra, além de não ter um controle exato de o que acontece.

Mas eu não queria necessariamente criar, neste momento, outro projeto completo para Android e iOS apenas para oferecer essa experiência. Foi quando entrou a PWA.

⚙️ O que é PWA tecnicamente?

PWA significa Progressive Web App, ou Aplicação Web Progressiva.

De maneira simplificada, é uma aplicação construída com tecnologias web que recebe recursos para proporcionar uma experiência mais próxima de um aplicativo instalado.

Dependendo da implementação e do navegador, uma PWA pode ser instalada no dispositivo (que foi exatamente o que eu fiz neste caso), conseguindo gerar um ícone na tela inicial e abrir em uma janela própria, sem aquela aparência tradicional de uma aba do navegador. Por trás disso normalmente encontramos tecnologias como:

Web App
 +
Web App Manifest
 +
Service Worker
 +
HTTPS
 ↓
PWA

O manifest fornece informações sobre a aplicação, como nome, ícones e comportamento de exibição. Já o service worker pode atuar entre a aplicação e a rede, permitindo estratégias de cache e outras capacidades da experiência PWA.

Mas novamente... Vamos esquecer esses nomes por um instante e entdner d euma forma mais simples o que é esse PWA...

📦 PWA explicado como uma embalagem diferente

Imagine que você compra exatamente o mesmo produto em duas embalagens.

Na primeira, para utilizá-lo, você precisa sempre entrar em uma loja, procurar o produto e abri-lo por lá.
Na segunda, você leva aquele produto para casa e coloca um atalho direto na sua mesa.

O conteúdo continua vindo da mesma origem, mas a maneira de acessá-lo ficou muito mais próxima e conveniente. É parecido com o que acontece com uma PWA.

No acesso tradicional:

Celular
 ↓
Navegador
 ↓
Digite/endereço/favorito
 ↓
IntegraPsi

Com a PWA instalada:

Celular
 ↓
Ícone IntegraPsi
 ↓
Aplicação

Para o usuário, a experiência se aproxima muito mais daquela sensação de "tenho o aplicativo instalado no meu celular". E para mim, como desenvolvedor, foi interessante perceber que eu poderia oferecer essa experiência sem necessariamente começar criando e mantendo imediatamente aplicações nativas diferentes para Android e iOS.

📲 O paciente também faz parte do sistema

Essa parte acabou se tornando uma das que mais gostei no IntegraPsi. O psicólogo consegue configurar o acesso de determinado paciente. Depois disso, o paciente recebe suas credenciais e pode acessar sua própria área.

A proposta é que esse ambiente permita uma interação entre sessões, dentro dos recursos definidos pelo profissional. No projeto, existem instrumentos de acompanhamento como check-ins, registros de pensamentos, avaliações semanais, metas terapêuticas e registros de situações ou gatilhos.

Esses registros não foram pensados para gerar diagnósticos automaticamente nem substituir o profissional. Eles servem como ferramentas de acompanhamento e precisam respeitar a separação entre aquilo que o paciente registra e aquilo que efetivamente compõe o prontuário clínico. Foi também uma maneira interessante de perceber que, às vezes, um único sistema possui experiências completamente diferentes dependendo de quem está utilizando.

Essa é provavelmente uma das imagens mais importantes do artigo porque mostra o PWA no celular e conecta perfeitamente com a explicação anterior.

🧩 Uma aplicação, vários pontos de vista

Foi aí que comecei a enxergar a arquitetura do IntegraPsi de uma maneira mais clara. Não construí simplesmente "uma tela para psicólogo". Comecei a construir um pequeno ecossistema:

 IntegraPsi
                      │
      ┌───────────────┼───────────────┐
      ↓               ↓               ↓
 Plataforma        Clínica         Paciente
      │               │               │
 Super Admin        Psicólogo          PWA
                      │
               ┌──────┼──────┐
               ↓      ↓      ↓
            Agenda Paciente Prontuário

E cada uma dessas pontas possui necessidades e permissões diferentes. Foi justamente quando comecei a desenhar essas relações que palavras como SaaS, tenant, autorização e PWA deixaram de parecer apenas termos técnicos bonitos utilizados em artigos de arquitetura.

Passei a entender por que eles existem.

🔐 E não, ainda não considero o sistema pronto para produção

Assim como com o MeuPet, quero deixar isso muito claro. O IntegraPsi está funcional e disponível para demonstração, mas trabalhar com dados relacionados à Psicologia aumenta muito a responsabilidade do projeto.

Ainda existem revisões, testes de segurança, validações de isolamento entre tenants, auditoria, testes de carga e diversas outras questões que eu precisaria aprofundar antes de considerar uma plataforma como essa pronta para utilização comercial com informações reais.

Inclusive, o próprio PRD foi pensado com preocupações maiores de segurança, auditoria e separação de acesso. Uma coisa que venho aprendendo nesses projetos é:

"Funciona no meu navegador" e "está pronto para produção" são duas frases completamente diferentes.

E quanto mais estudo desenvolvimento, mais importante essa diferença parece.

🧪 Quer testar o projeto?

Deixei uma conta de demonstração para quem quiser entrar no IntegraPsi e conhecer a aplicação funcionando.

Acessar o IntegraPsi: https://integrapsi-web.onrender.com/login.html#records

Usuário: psi.teste@gmail.com

Senha: Password123@

Tela de Login

🚀 No final, não era apenas mais um sistema

Quando comecei o IntegraPsi, minha preocupação principal era transformar uma ideia em uma aplicação funcional. Mas durante o desenvolvimento percebi que estava aprendendo coisas que iam muito além das telas.

Precisei pensar: Como vários clientes podem utilizar minha aplicação? Como separar seus dados? Quem administra esses clientes? Como diferentes perfis recebem permissões diferentes? Como oferecer uma experiência de aplicativo sem criar imediatamente um app nativo?

E essas perguntas me levaram diretamente para SaaS, Multitenant e PWA.

Talvez eu pudesse ter estudado tudo isso assistindo algumas aulas e lendo documentação. E continuo fazendo isso. Mas existe algo diferente quando o problema aparece na sua frente e você precisa fazê-lo funcionar.

💭 Algumas coisas só começaram a fazer sentido quando precisei construir

Durante muito tempo encontrei termos como SaaS, arquitetura multitenant, service worker, manifest, autenticação e autorização enquanto estudava programação.

Eu entendia mais ou menos suas definições. Mas existe uma distância enorme entre:

"Eu sei o que significa."

"Eu precisei implementar isso."

Foi desenvolvendo projetos como o IntegraPsi que essa distância começou a diminuir. E talvez esse seja um dos maiores motivos pelos quais continuo criando projetos mesmo sabendo que nenhum deles vai nascer perfeito.

Cada aplicação me obriga a atravessar uma barreira que antes parecia complicada. Depois que atravessamos, ela deixa de ser um mistério e passa a fazer parte da nossa caixa de ferramentas.

🌌 Mais um aprendizado no CodeVerse2026

O IntegraPsi ainda tem bastante espaço para evoluir. Segurança, arquitetura, experiência do usuário, testes e diversos outros pontos ainda podem e devem ser melhorados.

Mas dessa vez o maior resultado para mim não foi apenas colocar mais uma aplicação online. Foi finalmente conseguir olhar para alguns conceitos que antes pareciam abstratos e dizer:

Agora eu entendo por que isso existe. Porque precisei construir.

Mais um projeto. Mais alguns erros. Mais alguns conceitos que deixaram de ser teoria. E seguimos evoluindo, um aprendizado e um commit de cada vez. 🚀

Se esse artigo te ajudou de alguma maneira, curte, compartilhe para que alcance mais pessoas. Gratidão por lido até o fim, e nos vemos nos próximos artigos!

Segue lá no LinkedIn
Segue lá no GitHub