578 lines
19 KiB
Markdown
578 lines
19 KiB
Markdown
---
|
||
title: "MVP Digital para Laboratório Farmacêutico - Do Zero à Produção"
|
||
slug: "pharma-digital-transformation"
|
||
summary: "Liderança de squad em projeto greenfield para laboratório farmacêutico, construindo MVP de plataforma digital com integrações complexas (Salesforce, Twilio, APIs oficiais) partindo do zero absoluto - sem Git, sem servidores, sem infraestrutura."
|
||
client: "Laboratório Farmacêutico"
|
||
industry: "Farmacêutica & Saúde"
|
||
timeline: "4 meses (2 meses de atraso planejado)"
|
||
role: "Tech Lead & Solution Architect"
|
||
image: ""
|
||
tags:
|
||
- MVP
|
||
- Digital Transformation
|
||
- .NET
|
||
- React
|
||
- Next.js
|
||
- Salesforce
|
||
- Twilio
|
||
- SQL Server
|
||
- Tech Lead
|
||
- Greenfield
|
||
featured: true
|
||
order: 3
|
||
date: 2023-03-01
|
||
seo_title: "MVP Digital Farmacêutico - Transformação Digital do Zero"
|
||
seo_description: "Case de construção de MVP digital para laboratório farmacêutico partindo do zero: sem Git, sem infraestrutura, com integrações complexas e entrega bem-sucedida."
|
||
seo_keywords: "MVP, digital transformation, pharma, .NET, React, Next.js, Salesforce, greenfield project, tech lead"
|
||
---
|
||
|
||
## Overview
|
||
|
||
Laboratório farmacêutico no **início da transformação digital** contrata consultoria para construir plataforma de descontos para médicos prescritores, partindo de protótipo em WordPress.
|
||
|
||
**Desafio único:** Começar projeto greenfield em empresa **sem infraestrutura básica** de desenvolvimento - sem Git, sem servidores provisionados, sem processos definidos.
|
||
|
||
**Contexto:** Projeto executado em ambiente de múltiplas squads. **Entrega bem-sucedida em produção** apesar dos desafios iniciais de infraestrutura, com atraso controlado de 2 meses.
|
||
|
||
---
|
||
|
||
## Challenge
|
||
|
||
### Transformação Digital... Partindo do Zero Absoluto
|
||
|
||
**Estado inicial da empresa (2023):**
|
||
|
||
❌ **Sem Git/versionamento**
|
||
- Código apenas em máquinas locais
|
||
- Histórico inexistente
|
||
- Colaboração impossível
|
||
|
||
❌ **Sem servidores provisionados**
|
||
- Ambiente de desenvolvimento inexistente
|
||
- Homologação não configurada
|
||
- Produção não preparada
|
||
|
||
❌ **Sem processos de desenvolvimento**
|
||
- Sem CI/CD
|
||
- Sem code review
|
||
- Sem gestão de tarefas estruturada
|
||
|
||
❌ **Sem equipe técnica interna experiente**
|
||
- Time sem familiaridade com stacks modernas
|
||
- Primeiro contato com React, APIs REST
|
||
- Inexperiência com integrações complexas
|
||
|
||
**Ponto de partida técnico:**
|
||
- Protótipo funcional em **WordPress**
|
||
- Conteúdo e textos já aprovados
|
||
- UX/UI definido
|
||
- Regras de negócio documentadas (parcialmente)
|
||
|
||
---
|
||
|
||
### Integrações Complexas Requeridas
|
||
|
||
O MVP precisava integrar com múltiplos sistemas externos:
|
||
|
||
1. 🔐 **Salesforce** - Registro de pedidos de desconto
|
||
2. 📱 **Twilio** - SMS para validação de login (2FA)
|
||
3. 🏥 **API oficial de médicos** - Validação de CRM + dados profissionais
|
||
4. 🎯 **Interplayers** - Envio de registros de desconto por CPF
|
||
5. 📄 **WordPress** - Leitura de conteúdo (CMS headless)
|
||
6. 💾 **SQL Server** - Persistência de dados
|
||
|
||
**Complexidade adicional:**
|
||
- Diferentes credenciais/ambientes por integração
|
||
- SLAs variados (Twilio crítico, WordPress tolerante)
|
||
- Tratamento de erros específico por provider
|
||
- Compliance LGPD (dados sensíveis de médicos)
|
||
|
||
---
|
||
|
||
## Solution Architecture
|
||
|
||
### Estratégia: Start Small, Build Solid
|
||
|
||
**Decisão inicial:** Explicar ao time o processo que iríamos seguir, estabelecendo fundações antes de codificar.
|
||
|
||
### Fase 1: Setup de Infraestrutura Básica (Semanas 1-2)
|
||
|
||
Mesmo sem servidores provisionados, iniciei setup essencial:
|
||
|
||
**Git & Versionamento:**
|
||
```bash
|
||
# Repositório estruturado desde dia 1
|
||
git init
|
||
git flow init # Branch strategy definida
|
||
|
||
# Estrutura de monorepo
|
||
/
|
||
├── frontend/ # Next.js + React
|
||
├── backend/ # .NET APIs
|
||
├── cms-adapter/ # WordPress integration
|
||
└── docs/ # Arquitetura e ADRs
|
||
```
|
||
|
||
**Processo explicado ao time:**
|
||
1. ✅ Tudo no Git (commits atômicos, mensagens descritivas)
|
||
2. ✅ Feature branches (nunca commit direto em main)
|
||
3. ✅ Code review obrigatório (2 aprovações)
|
||
4. ✅ CI/CD preparado (para quando servidores estiverem prontos)
|
||
|
||
**Ambientes locais primeiro:**
|
||
- Docker Compose para desenvolvimento local
|
||
- Mock de APIs externas (até credenciais chegarem)
|
||
- SQL Server local com seeds de dados
|
||
|
||
---
|
||
|
||
### Fase 2: Arquitetura Moderna & Desacoplada
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ FRONTEND (Next.js + React) │
|
||
│ - SSR para SEO │
|
||
│ - Client-side para interatividade │
|
||
│ - Consumo de APIs │
|
||
└────────────┬────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ BACKEND APIs (.NET 7) │
|
||
│ - REST APIs │
|
||
│ - Authentication/Authorization │
|
||
│ - Business logic │
|
||
│ - Orchestration layer │
|
||
└────┬────┬────┬────┬────┬─────────────────────────┬──┘
|
||
│ │ │ │ │ │
|
||
▼ ▼ ▼ ▼ ▼ ▼
|
||
┌────────┐ ┌──────┐ ┌──────┐ ┌────────┐ ┌────────┐ ┌──────────┐
|
||
│Salesf. │ │Twilio│ │CRM │ │Interpl.│ │WordPr. │ │SQL Server│
|
||
│ │ │ │ │API │ │ │ │(CMS) │ │ │
|
||
└────────┘ └──────┘ └──────┘ └────────┘ └────────┘ └──────────┘
|
||
```
|
||
|
||
**Stack escolhido:**
|
||
|
||
**Frontend:**
|
||
- `Next.js 13` - SSR, routing, otimizações
|
||
- `React 18` - Componentes, hooks, context
|
||
- `TypeScript` - Type safety
|
||
- `Tailwind CSS` - Styling moderno
|
||
|
||
**Backend:**
|
||
- `.NET 7` - APIs REST
|
||
- `Entity Framework Core` - ORM
|
||
- `SQL Server 2019` - Banco de dados
|
||
- `Polly` - Resilience patterns (retry, circuit breaker)
|
||
|
||
**Por que Next.js em vez de manter WordPress?**
|
||
- ✅ Performance (SSR vs PHP monolítico)
|
||
- ✅ SEO otimizado (critical para farmacêutica)
|
||
- ✅ Experiência moderna (SPA quando necessário)
|
||
- ✅ Escalabilidade
|
||
- ✅ WordPress mantido apenas como CMS (headless)
|
||
|
||
---
|
||
|
||
### Fase 3: Integrações (Core do Projeto)
|
||
|
||
#### 1. Salesforce - Campanhas e Registro de Pedidos
|
||
|
||
**Solução implementada:**
|
||
|
||
O Salesforce foi configurado para gerenciar duas funcionalidades principais:
|
||
|
||
**a) Campanhas de desconto:**
|
||
- Marketing configura campanhas no Salesforce (medicamento X, desconto Y%, período)
|
||
- Backend consulta campanhas ativas via API
|
||
- Frontend (Next.js) exibe percentual de desconto disponível baseado em: medicamento + campanha ativa
|
||
|
||
**b) Registro de pedidos:**
|
||
- Usuário informa: CRM do médico, UF, CPF do paciente, medicamento
|
||
- Sistema valida dados (CRM real via API oficial, CPF válido)
|
||
- Percentual é calculado automaticamente (campanhas do Salesforce + regras do CMS)
|
||
- Pedido é registrado no Salesforce com todos os dados (compliance LGPD)
|
||
|
||
**Desafios técnicos superados:**
|
||
- Autenticação OAuth2 com refresh token automático
|
||
- Rate limiting (Salesforce tem limites de API/dia)
|
||
- Retry logic para falhas transitórias (Polly)
|
||
- Mascaramento de CPF para logs (LGPD)
|
||
|
||
---
|
||
|
||
#### 2. Twilio - Autenticação por SMS (2FA)
|
||
|
||
**Solução implementada:**
|
||
|
||
Sistema de autenticação de dois fatores para garantir segurança:
|
||
|
||
**Fluxo de login:**
|
||
1. Usuário informa telefone
|
||
2. Backend gera código de 6 dígitos (válido por 5 minutos)
|
||
3. SMS enviado via Twilio ("Seu código: 123456")
|
||
4. Usuário digita código no frontend
|
||
5. Backend valida código + timestamp de expiração
|
||
6. Token JWT emitido após validação bem-sucedida
|
||
|
||
**Compliance e auditoria:**
|
||
- Telefones mascarados nos logs (LGPD)
|
||
- Auditoria completa (quem, quando, qual SMS)
|
||
- Taxa de entrega: 99.8%
|
||
|
||
---
|
||
|
||
#### 3. API Oficial de Médicos (Conselho Regional de Medicina)
|
||
|
||
**Solução implementada:**
|
||
|
||
Validação automática de médicos via API oficial dos conselhos de medicina:
|
||
|
||
**Validações realizadas:**
|
||
- CRM existe e está ativo no conselho
|
||
- Nome do médico corresponde ao CRM informado
|
||
- Especialidade é permitida (regra de negócio do laboratório)
|
||
- UF corresponde ao estado de registro
|
||
|
||
**Otimizações:**
|
||
- Cache de 24 horas para reduzir chamadas à API oficial
|
||
- Fallback em caso de API fora do ar (notifica admin)
|
||
- Retry automático para falhas transitórias
|
||
|
||
**Por que isso importa:**
|
||
Garante que apenas médicos reais e ativos possam prescrever descontos, evitando fraudes.
|
||
|
||
---
|
||
|
||
#### 4. WordPress como CMS Headless
|
||
|
||
**Solução implementada:**
|
||
|
||
Marketing continua gerenciando conteúdo no WordPress (familiar), mas frontend é Next.js moderno.
|
||
|
||
**Arquitetura:**
|
||
- WordPress: Gerencia textos, imagens, regras de campanhas
|
||
- WordPress REST API: Expõe conteúdo via JSON
|
||
- Next.js: Consome API e renderiza com SSR (SEO otimizado)
|
||
|
||
**Benefícios:**
|
||
- ✅ Marketing não precisa aprender nova ferramenta
|
||
- ✅ Frontend moderno (performance, UX)
|
||
- ✅ SEO otimizado (Server-Side Rendering)
|
||
- ✅ Separação clara de responsabilidades (conteúdo vs código)
|
||
|
||
---
|
||
|
||
### Fase 4: Resiliência & Error Handling
|
||
|
||
Com múltiplas integrações externas, falhas são inevitáveis. A solução foi implementar **padrões de resiliência** usando biblioteca Polly (.NET):
|
||
|
||
**Padrões implementados:**
|
||
|
||
**1. Retry (Tentar novamente)**
|
||
- Se Salesforce/Twilio/CRM API falham, sistema tenta automaticamente 2-3x
|
||
- Espera cresce exponencialmente (1s, 2s, 4s) para evitar sobrecarga
|
||
- Apenas erros transitórios (timeout, 503) são retentados
|
||
|
||
**2. Circuit Breaker (Disjuntor)**
|
||
- Se serviço falha 5x seguidas, "abre o circuito" por 30s
|
||
- Durante 30s, não tenta mais (evita desperdiçar recursos)
|
||
- Após 30s, tenta novamente (pode ter voltado)
|
||
|
||
**3. Timeout**
|
||
- Cada integração tem tempo máximo de resposta
|
||
- Evita requisições travadas indefinidamente
|
||
|
||
**4. Fallback (Plano B)**
|
||
- Salesforce fora: Pedido vai para fila, processa depois
|
||
- Twilio fora: Alerta administrador via email
|
||
- CRM API fora: Usa cache (dados de 24h atrás)
|
||
- WordPress fora: Exibe conteúdo estático pré-carregado
|
||
|
||
**Estratégias por integração:**
|
||
|
||
| Integração | Retry | Circuit Breaker | Timeout | Plano B |
|
||
|----------|-------|-----------------|---------|----------|
|
||
| Salesforce | 3x (exponencial) | 5 falhas/30s | 10s | Fila de retry |
|
||
| Twilio | 2x (linear) | 3 falhas/60s | 5s | Alerta admin |
|
||
| CRM API | 3x (exponencial) | Não | 15s | Cache |
|
||
| WordPress | Não | Não | 3s | Conteúdo estático |
|
||
|
||
**Resultado em produção:**
|
||
- Salesforce teve manutenção (1h) → Sistema continuou funcionando (fila processou depois)
|
||
- Twilio teve instabilidade → Retry automático resolveu 95% dos casos
|
||
- Zero downtime percebido pelos usuários
|
||
|
||
---
|
||
|
||
## Overcoming Infrastructure Challenges
|
||
|
||
### Problema: Servidores Não Provisionados
|
||
|
||
**Solução temporária:**
|
||
1. Desenvolvimento 100% local (Docker Compose)
|
||
2. Mocks de serviços externos (quando credenciais atrasaram)
|
||
3. CI/CD preparado mas não ativo (aguardando infra)
|
||
|
||
**Quando servidores chegaram (semana 6):**
|
||
- Deploy em 2 horas (já estava preparado)
|
||
- Zero surpresas (tudo testado localmente)
|
||
- Rollout suave
|
||
|
||
---
|
||
|
||
### Problema: Credenciais de Integração Atrasadas
|
||
|
||
**Impacto:** Twilio e Salesforce demoraram 3 semanas para serem provisionadas.
|
||
|
||
**Solução:** Criar versões "mock" (simuladas) de cada integração:
|
||
- Mock do Twilio: Registra no log em vez de enviar SMS real
|
||
- Mock do Salesforce: Salva pedido em arquivo JSON local
|
||
- Mock da CRM API: Retorna dados fictícios de médicos
|
||
|
||
**Como funciona:**
|
||
- Ambiente de desenvolvimento: Usa mocks (não precisa de credenciais)
|
||
- Ambiente de produção: Usa integrações reais (quando credenciais chegarem)
|
||
- Troca automática baseada em configuração
|
||
|
||
**Resultado:** Time continuou 100% produtivo durante 3 semanas, testando fluxos completos sem depender de credenciais.
|
||
|
||
---
|
||
|
||
### Problema: Time Inexperiente com Stack Moderno
|
||
|
||
**Contexto:** Equipe não tinha experiência com React, TypeScript, .NET Core moderno, APIs REST.
|
||
|
||
**Abordagem de capacitação:**
|
||
|
||
**1. Pair Programming (1h/dia por desenvolvedor)**
|
||
- Tech lead trabalha ao lado do dev
|
||
- Compartilhamento de tela + explicação em tempo real
|
||
- Dev escreve código, tech lead guia
|
||
|
||
**2. Code Review Educativo**
|
||
- Não apenas "aprovar" ou "reprovar"
|
||
- Comentários explicam o **porquê** de cada sugestão
|
||
- Exemplo: "Sempre trate erros de requisições! Se API cair, usuário precisa saber o que aconteceu."
|
||
|
||
**3. Documentação Viva**
|
||
- ADRs (Architecture Decision Records): Por que escolhemos X e não Y?
|
||
- READMEs: Como rodar, como testar, como deployar
|
||
- Onboarding guide: Do zero à primeira feature
|
||
|
||
**4. Live Coding Semanal (2h)**
|
||
- Tech lead resolve problema real ao vivo
|
||
- Time observa processo de pensamento
|
||
- Q&A ao final
|
||
|
||
**Resultado:**
|
||
- Após 4 semanas, time estava autônomo
|
||
- Qualidade de código aumentou consistentemente
|
||
- Devs passaram a fazer code review entre si (peer review)
|
||
|
||
---
|
||
|
||
## Results & Impact
|
||
|
||
### Entrega Bem-Sucedida Apesar dos Desafios
|
||
|
||
**Contexto:** Programa com múltiplas squads trabalhando em paralelo.
|
||
|
||
**Resultado alcançado:**
|
||
- ✅ **MVP entregue em produção com sucesso**
|
||
- ✅ Atraso controlado de 2 meses (significativamente menor que outras iniciativas do programa)
|
||
- ✅ Todas as integrações funcionando conforme planejado
|
||
- ✅ Zero critical bugs em produção (primeira semana)
|
||
|
||
**Por que a entrega foi bem-sucedida?**
|
||
|
||
1. **Setup antecipado** - Git, processos, Docker local desde dia 1
|
||
2. **Mocks estratégicos** - Time não ficou bloqueado esperando infra
|
||
3. **Arquitetura sólida** - Resiliência desde o início
|
||
4. **Upskilling contínuo** - Time aprendeu fazendo
|
||
5. **Comunicação proativa** - Riscos reportados cedo
|
||
|
||
---
|
||
|
||
### Métricas do MVP
|
||
|
||
**Performance:**
|
||
- ⚡ Tempo de carregamento: <2s (95th percentile)
|
||
- 📱 Lighthouse score: 95+ (mobile)
|
||
- 🔒 SSL A+ rating
|
||
|
||
**Integrações:**
|
||
- 📊 Salesforce: 100% de pedidos sincronizados
|
||
- 📱 Twilio: 99.8% delivery rate
|
||
- 🏥 CRM API: 10k validações/dia (média)
|
||
- 💾 SQL Server: 50k registros/mês
|
||
|
||
**Adoção:**
|
||
- 👨⚕️ 2.000+ médicos cadastrados (3 primeiros meses)
|
||
- 🎯 15.000+ pedidos de desconto processados
|
||
- ⭐ 4.8/5 satisfação (pesquisa interna)
|
||
|
||
---
|
||
|
||
### Impacto no Cliente
|
||
|
||
**Transformação digital iniciada:**
|
||
- ✅ Git implementado e adotado
|
||
- ✅ Processos de desenvolvimento estabelecidos
|
||
- ✅ Time interno capacitado em stacks modernas
|
||
- ✅ Infraestrutura cloud configurada (Azure)
|
||
- ✅ Roadmap de evolução definido
|
||
|
||
**Base para futuros projetos:**
|
||
- Arquitetura serviu de referência para outras iniciativas
|
||
- Padrões de código documentados (coding standards)
|
||
- Pipelines CI/CD reutilizados
|
||
|
||
---
|
||
|
||
## Tech Stack
|
||
|
||
`.NET 7` `C#` `Entity Framework Core` `SQL Server` `React 18` `Next.js 13` `TypeScript` `Tailwind CSS` `Salesforce API` `Twilio` `WordPress REST API` `Docker` `Polly` `OAuth2` `JWT` `LGPD Compliance`
|
||
|
||
---
|
||
|
||
## Key Decisions & Trade-offs
|
||
|
||
### Por que Next.js em vez de React puro?
|
||
|
||
**Requisitos:**
|
||
- SEO crítico (farmacêutica precisa rankar)
|
||
- Performance (médicos usam mobile)
|
||
- Conteúdo dinâmico (WordPress)
|
||
|
||
**Next.js oferece:**
|
||
- ✅ SSR out-of-the-box
|
||
- ✅ API routes (BFF pattern)
|
||
- ✅ Otimizações automáticas (image, fonts)
|
||
- ✅ Deploy simplificado (Vercel, Azure)
|
||
|
||
---
|
||
|
||
### Por que manter WordPress?
|
||
|
||
**Alternativas consideradas:**
|
||
1. ❌ Migrar conteúdo para banco + CMS custom (tempo)
|
||
2. ❌ Strapi/Contentful (custos + learning curve)
|
||
3. ✅ **WordPress headless** (melhor trade-off)
|
||
|
||
**Vantagens:**
|
||
- Time de marketing já sabe usar
|
||
- Conteúdo aprovado já estava lá
|
||
- WordPress REST API é sólida
|
||
- Custo zero (já estava rodando)
|
||
|
||
---
|
||
|
||
### Por que .NET 7 em vez de Node.js?
|
||
|
||
**Contexto:** Cliente tinha preferência por Microsoft stack.
|
||
|
||
**Benefícios adicionais:**
|
||
- Performance superior (vs Node em APIs)
|
||
- Type safety nativa (C#)
|
||
- Entity Framework (ORM maduro)
|
||
- Integração fácil com Azure (deploy futuro)
|
||
- Time do cliente tinha familiaridade
|
||
|
||
---
|
||
|
||
## Lessons Learned
|
||
|
||
### 1. Infraestrutura Atrasada? Prepare Alternativas
|
||
|
||
Não espere servidores/credenciais para começar:
|
||
- Docker local é seu amigo
|
||
- Mocks permitem progresso
|
||
- CI/CD pode ser preparado antes de haver onde deployar
|
||
|
||
**Lição:** Controle o que você pode controlar.
|
||
|
||
---
|
||
|
||
### 2. Processos > Ferramentas
|
||
|
||
Mesmo sem Git corporativo, estabeleci:
|
||
- Branching strategy
|
||
- Code review
|
||
- Commit conventions
|
||
- Documentation standards
|
||
|
||
**Resultado:** Quando ferramentas chegaram, time já sabia usá-las.
|
||
|
||
---
|
||
|
||
### 3. Upskilling é Investimento, Não Custo
|
||
|
||
Pair programming e code reviews levaram tempo, mas:
|
||
- ✅ Time ficou autônomo mais rápido
|
||
- ✅ Qualidade de código aumentou
|
||
- ✅ Knowledge sharing natural
|
||
- ✅ Onboarding de novos devs simplificado
|
||
|
||
---
|
||
|
||
### 4. Resiliência Desde o Início
|
||
|
||
Implementar Polly (retry, circuit breaker) no início salvou em produção:
|
||
- Twilio teve instabilidade (resolvida automaticamente)
|
||
- Salesforce teve manutenção (queue funcionou)
|
||
- CRM API teve lentidão (cache mitigou)
|
||
|
||
**Lição:** Não deixe resiliência para "depois". Falhas vão acontecer.
|
||
|
||
---
|
||
|
||
### 5. Comunicação Clara de Riscos
|
||
|
||
Reportei semanalmente:
|
||
- Bloqueios (infraestrutura, credenciais)
|
||
- Riscos (prazos, dependências)
|
||
- Soluções alternativas (mocks, workarounds)
|
||
|
||
**Resultado:** Stakeholders sabiam exatamente o status e não tiveram surpresas.
|
||
|
||
---
|
||
|
||
## Challenges & How They Were Overcome
|
||
|
||
| Desafio | Impacto | Solução | Resultado |
|
||
|---------|---------|---------|-----------|
|
||
| Sem Git | Bloqueio total | Setup local + GitLab Cloud | Time produtivo dia 1 |
|
||
| Sem servidores | Sem ambiente de dev | Docker Compose local | Dev/test local completo |
|
||
| Credenciais atrasadas | Integração bloqueada | Mock services | Progresso sem bloqueio |
|
||
| Time inexperiente | Código de baixa qualidade | Pair prog + Code review | Ramp-up em 4 semanas |
|
||
| Múltiplas integrações | Complexidade alta | Polly + patterns | Zero downtime prod |
|
||
|
||
---
|
||
|
||
## Next Steps (Pós-MVP)
|
||
|
||
**Roadmap sugerido ao cliente:**
|
||
|
||
1. **Fase 2: Expansão de funcionalidades**
|
||
- Dashboard para médicos (histórico de pedidos)
|
||
- Notificações push (Firebase)
|
||
- Integração com e-commerce (compra direta)
|
||
|
||
2. **Fase 3: Otimizações**
|
||
- Cache distribuído (Redis)
|
||
- CDN para assets estáticos
|
||
- Analytics avançado (Amplitude)
|
||
|
||
3. **Fase 4: Escala**
|
||
- Kubernetes (AKS)
|
||
- Microserviços (quebrar monolito)
|
||
- Event-driven architecture (Azure Service Bus)
|
||
|
||
---
|
||
|
||
**Resultado:** MVP entregue em produção apesar de começar literalmente do zero, estabelecendo fundações sólidas para transformação digital do cliente.
|
||
|
||
[Precisa construir um MVP em cenário desafiador? Entre em contato](#contact)
|