---
title: "MVP Digital para Laboratorio Farmacéutico - De Cero a Producción"
slug: "pharma-digital-transformation"
summary: "Liderazgo de squad en proyecto greenfield para laboratorio farmacéutico, construyendo MVP de plataforma digital con integraciones complejas (Salesforce, Twilio, APIs oficiales) partiendo de cero absoluto - sin Git, sin servidores, sin infraestructura."
client: "Laboratorio Farmacéutico"
industry: "Farmacéutica & Salud"
timeline: "4 meses (2 meses de retraso planificado)"
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 - Transformación Digital de Cero"
seo_description: "Caso de construcción de MVP digital para laboratorio farmacéutico partiendo de cero: sin Git, sin infraestructura, con integraciones complejas y entrega exitosa."
seo_keywords: "MVP, digital transformation, pharma, .NET, React, Next.js, Salesforce, greenfield project, tech lead"
---

## Descripción General

Laboratorio farmacéutico en el **inicio de transformación digital** contrata consultoría para construir plataforma de descuentos para médicos prescriptores, partiendo de prototipo en WordPress.

**Desafío único:** Comenzar proyecto greenfield en empresa **sin infraestructura básica** de desarrollo - sin Git, sin servidores aprovisionados, sin procesos definidos.

**Contexto:** Proyecto ejecutado en ambiente de múltiples squads. **Entrega exitosa en producción** a pesar de los desafíos iniciales de infraestructura, con retraso controlado de 2 meses.

---

## Desafío

### Transformación Digital... Partiendo de Cero Absoluto

**Estado inicial de la empresa (2023):**

❌ **Sin Git/versionamiento**
- Código solo en máquinas locales
- Histórico inexistente
- Colaboración imposible

❌ **Sin servidores aprovisionados**
- Ambiente de desarrollo inexistente
- Homologación no configurada
- Producción no preparada

❌ **Sin procesos de desarrollo**
- Sin CI/CD
- Sin code review
- Sin gestión de tareas estructurada

❌ **Sin equipo técnico interno experimentado**
- Equipo sin familiaridad con stacks modernos
- Primer contacto con React, APIs REST
- Inexperiencia con integraciones complejas

**Punto de partida técnico:**
- Prototipo funcional en **WordPress**
- Contenido y textos ya aprobados
- UX/UI definido
- Reglas de negocio documentadas (parcialmente)

---

### Integraciones Complejas Requeridas

El MVP necesitaba integrar con múltiples sistemas externos:

1. 🔐 **Salesforce** - Registro de pedidos de descuento
2. 📱 **Twilio** - SMS para validación de login (2FA)
3. 🏥 **API oficial de médicos** - Validación de CRM + datos profesionales
4. 🎯 **Interplayers** - Envío de registros de descuento por CPF
5. 📄 **WordPress** - Lectura de contenido (CMS headless)
6. 💾 **SQL Server** - Persistencia de datos

**Complejidad adicional:**
- Diferentes credenciales/ambientes por integración
- SLAs variados (Twilio crítico, WordPress tolerante)
- Tratamiento de errores específico por provider
- Compliance LGPD (datos sensibles de médicos)

---

## Arquitectura de Solución

### Estrategia: Start Small, Build Solid

**Decisión inicial:** Explicar al equipo el proceso que seguiríamos, estableciendo fundaciones antes de codificar.

### Fase 1: Setup de Infraestructura Básica (Semanas 1-2)

Incluso sin servidores aprovisionados, inicié setup esencial:

**Git & Versionamiento:**
```bash
# Repositorio estructurado desde día 1
git init
git flow init  # Branch strategy definida

# Estructura de monorepo
/
├── frontend/      # Next.js + React
├── backend/       # .NET APIs
├── cms-adapter/   # WordPress integration
└── docs/          # Arquitectura y ADRs
```

**Proceso explicado al equipo:**
1. ✅ Todo en Git (commits atómicos, mensajes descriptivos)
2. ✅ Feature branches (nunca commit directo en main)
3. ✅ Code review obligatorio (2 aprobaciones)
4. ✅ CI/CD preparado (para cuando servidores estén listos)

**Ambientes locales primero:**
- Docker Compose para desarrollo local
- Mock de APIs externas (hasta que lleguen credenciales)
- SQL Server local con seeds de datos

---

### Fase 2: Arquitectura Moderna & Desacoplada

```
┌─────────────────────────────────────────────────────┐
│  FRONTEND (Next.js + React)                         │
│  - SSR para SEO                                     │
│  - Client-side para interactividad                  │
│  - 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 elegido:**

**Frontend:**
- `Next.js 13` - SSR, routing, optimizaciones
- `React 18` - Componentes, hooks, context
- `TypeScript` - Type safety
- `Tailwind CSS` - Styling moderno

**Backend:**
- `.NET 7` - APIs REST
- `Entity Framework Core` - ORM
- `SQL Server 2019` - Base de datos
- `Polly` - Resilience patterns (retry, circuit breaker)

**¿Por qué Next.js en vez de mantener WordPress?**
- ✅ Performance (SSR vs PHP monolítico)
- ✅ SEO optimizado (crítico para farmacéutica)
- ✅ Experiencia moderna (SPA cuando necesario)
- ✅ Escalabilidad
- ✅ WordPress mantenido solo como CMS (headless)

---

### Fase 3: Integraciones (Core del Proyecto)

#### 1. Salesforce - Campañas y Registro de Pedidos

**Solución implementada:**

Salesforce fue configurado para gestionar dos funcionalidades principales:

**a) Campañas de descuento:**
- Marketing configura campañas en Salesforce (medicamento X, descuento Y%, período)
- Backend consulta campañas activas vía API
- Frontend (Next.js) muestra porcentaje de descuento disponible basado en: medicamento + campaña activa

**b) Registro de pedidos:**
- Usuario informa: CRM del médico, UF, CPF del paciente, medicamento
- Sistema valida datos (CRM real vía API oficial, CPF válido)
- Porcentaje es calculado automáticamente (campañas de Salesforce + reglas del CMS)
- Pedido es registrado en Salesforce con todos los datos (compliance LGPD)

**Desafíos técnicos superados:**
- Autenticación OAuth2 con refresh token automático
- Rate limiting (Salesforce tiene límites de API/día)
- Retry logic para fallas transitorias (Polly)
- Enmascaramiento de CPF para logs (LGPD)

---

#### 2. Twilio - Autenticación por SMS (2FA)

**Solución implementada:**

Sistema de autenticación de dos factores para garantizar seguridad:

**Flujo de login:**
1. Usuario informa teléfono
2. Backend genera código de 6 dígitos (válido por 5 minutos)
3. SMS enviado vía Twilio ("Su código: 123456")
4. Usuario digita código en frontend
5. Backend valida código + timestamp de expiración
6. Token JWT emitido tras validación exitosa

**Compliance y auditoría:**
- Teléfonos enmascarados en logs (LGPD)
- Auditoría completa (quién, cuándo, qué SMS)
- Tasa de entrega: 99.8%

---

#### 3. API Oficial de Médicos (Consejo Regional de Medicina)

**Solución implementada:**

Validación automática de médicos vía API oficial de los consejos de medicina:

**Validaciones realizadas:**
- CRM existe y está activo en el consejo
- Nombre del médico corresponde al CRM informado
- Especialidad es permitida (regla de negocio del laboratorio)
- UF corresponde al estado de registro

**Optimizaciones:**
- Cache de 24 horas para reducir llamadas a API oficial
- Fallback en caso de API fuera del aire (notifica admin)
- Retry automático para fallas transitorias

**Por qué esto importa:**
Garantiza que solo médicos reales y activos puedan prescribir descuentos, evitando fraudes.

---

#### 4. WordPress como CMS Headless

**Solución implementada:**

Marketing continúa gestionando contenido en WordPress (familiar), pero frontend es Next.js moderno.

**Arquitectura:**
- WordPress: Gestiona textos, imágenes, reglas de campañas
- WordPress REST API: Expone contenido vía JSON
- Next.js: Consume API y renderiza con SSR (SEO optimizado)

**Beneficios:**
- ✅ Marketing no necesita aprender nueva herramienta
- ✅ Frontend moderno (performance, UX)
- ✅ SEO optimizado (Server-Side Rendering)
- ✅ Separación clara de responsabilidades (contenido vs código)

---

### Fase 4: Resiliencia & Error Handling

Con múltiples integraciones externas, fallas son inevitables. La solución fue implementar **patrones de resiliencia** usando biblioteca Polly (.NET):

**Patrones implementados:**

**1. Retry (Reintentar)**
- Si Salesforce/Twilio/CRM API fallan, sistema intenta automáticamente 2-3x
- Espera crece exponencialmente (1s, 2s, 4s) para evitar sobrecarga
- Solo errores transitorios (timeout, 503) son reintentados

**2. Circuit Breaker (Disyuntor)**
- Si servicio falla 5x seguidas, "abre el circuito" por 30s
- Durante 30s, no intenta más (evita desperdiciar recursos)
- Tras 30s, intenta nuevamente (puede haber vuelto)

**3. Timeout**
- Cada integración tiene tiempo máximo de respuesta
- Evita requisiciones trabadas indefinidamente

**4. Fallback (Plan B)**
- Salesforce fuera: Pedido va a cola, procesa después
- Twilio fuera: Alerta administrador vía email
- CRM API fuera: Usa cache (datos de 24h atrás)
- WordPress fuera: Muestra contenido estático precargado

**Estrategias por integración:**

| Integración | Retry | Circuit Breaker | Timeout | Plan B |
|----------|-------|-----------------|---------|----------|
| Salesforce | 3x (exponencial) | 5 fallas/30s | 10s | Cola de retry |
| Twilio | 2x (lineal) | 3 fallas/60s | 5s | Alerta admin |
| CRM API | 3x (exponencial) | No | 15s | Cache |
| WordPress | No | No | 3s | Contenido estático |

**Resultado en producción:**
- Salesforce tuvo mantenimiento (1h) → Sistema continuó funcionando (cola procesó después)
- Twilio tuvo inestabilidad → Retry automático resolvió 95% de los casos
- Zero downtime percibido por los usuarios

---

## Superando Desafíos de Infraestructura

### Problema: Servidores No Aprovisionados

**Solución temporal:**
1. Desarrollo 100% local (Docker Compose)
2. Mocks de servicios externos (cuando credenciales se retrasaron)
3. CI/CD preparado pero no activo (esperando infra)

**Cuando llegaron servidores (semana 6):**
- Deploy en 2 horas (ya estaba preparado)
- Zero sorpresas (todo probado localmente)
- Rollout suave

---

### Problema: Credenciales de Integración Retrasadas

**Impacto:** Twilio y Salesforce demoraron 3 semanas en ser aprovisionadas.

**Solución:** Crear versiones "mock" (simuladas) de cada integración:
- Mock de Twilio: Registra en log en vez de enviar SMS real
- Mock de Salesforce: Guarda pedido en archivo JSON local
- Mock de CRM API: Retorna datos ficticios de médicos

**Cómo funciona:**
- Ambiente de desarrollo: Usa mocks (no necesita credenciales)
- Ambiente de producción: Usa integraciones reales (cuando lleguen credenciales)
- Cambio automático basado en configuración

**Resultado:** Equipo continuó 100% productivo durante 3 semanas, probando flujos completos sin depender de credenciales.

---

### Problema: Equipo Inexperto con Stack Moderno

**Contexto:** Equipo no tenía experiencia con React, TypeScript, .NET Core moderno, APIs REST.

**Abordaje de capacitación:**

**1. Pair Programming (1h/día por desarrollador)**
- Tech lead trabaja al lado del dev
- Compartir pantalla + explicación en tiempo real
- Dev escribe código, tech lead guía

**2. Code Review Educativo**
- No solo "aprobar" o "reprobar"
- Comentarios explican el **por qué** de cada sugerencia
- Ejemplo: "Siempre trate errores de requisiciones! Si API cae, usuario necesita saber qué pasó."

**3. Documentación Viva**
- ADRs (Architecture Decision Records): ¿Por qué elegimos X y no Y?
- READMEs: Cómo ejecutar, cómo probar, cómo deployar
- Onboarding guide: De cero a primera feature

**4. Live Coding Semanal (2h)**
- Tech lead resuelve problema real en vivo
- Equipo observa proceso de pensamiento
- Q&A al final

**Resultado:**
- Tras 4 semanas, equipo estaba autónomo
- Calidad de código aumentó consistentemente
- Devs pasaron a hacer code review entre sí (peer review)

---

## Resultados e Impacto

### Entrega Exitosa A Pesar de los Desafíos

**Contexto:** Programa con múltiples squads trabajando en paralelo.

**Resultado alcanzado:**
- ✅ **MVP entregado en producción con éxito**
- ✅ Retraso controlado de 2 meses (significativamente menor que otras iniciativas del programa)
- ✅ Todas las integraciones funcionando según planificado
- ✅ Zero critical bugs en producción (primera semana)

**¿Por qué la entrega fue exitosa?**

1. **Setup anticipado** - Git, procesos, Docker local desde día 1
2. **Mocks estratégicos** - Equipo no quedó bloqueado esperando infra
3. **Arquitectura sólida** - Resiliencia desde el inicio
4. **Upskilling continuo** - Equipo aprendió haciendo
5. **Comunicación proactiva** - Riesgos reportados temprano

---

### Métricas del MVP

**Performance:**
- ⚡ Tiempo de carga: <2s (95th percentile)
- 📱 Lighthouse score: 95+ (mobile)
- 🔒 SSL A+ rating

**Integraciones:**
- 📊 Salesforce: 100% de pedidos sincronizados
- 📱 Twilio: 99.8% delivery rate
- 🏥 CRM API: 10k validaciones/día (media)
- 💾 SQL Server: 50k registros/mes

**Adopción:**
- 👨‍⚕️ 2.000+ médicos registrados (3 primeros meses)
- 🎯 15.000+ pedidos de descuento procesados
- ⭐ 4.8/5 satisfacción (encuesta interna)

---

### Impacto en el Cliente

**Transformación digital iniciada:**
- ✅ Git implementado y adoptado
- ✅ Procesos de desarrollo establecidos
- ✅ Equipo interno capacitado en stacks modernos
- ✅ Infraestructura cloud configurada (Azure)
- ✅ Roadmap de evolución definido

**Base para futuros proyectos:**
- Arquitectura sirvió de referencia para otras iniciativas
- Patrones 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`

---

## Decisiones Clave & Trade-offs

### ¿Por qué Next.js en vez de React puro?

**Requisitos:**
- SEO crítico (farmacéutica necesita ranquear)
- Performance (médicos usan mobile)
- Contenido dinámico (WordPress)

**Next.js ofrece:**
- ✅ SSR out-of-the-box
- ✅ API routes (BFF pattern)
- ✅ Optimizaciones automáticas (image, fonts)
- ✅ Deploy simplificado (Vercel, Azure)

---

### ¿Por qué mantener WordPress?

**Alternativas consideradas:**
1. ❌ Migrar contenido a BD + CMS custom (tiempo)
2. ❌ Strapi/Contentful (costos + learning curve)
3. ✅ **WordPress headless** (mejor trade-off)

**Ventajas:**
- Equipo de marketing ya sabe usar
- Contenido aprobado ya estaba ahí
- WordPress REST API es sólida
- Costo cero (ya estaba ejecutándose)

---

### ¿Por qué .NET 7 en vez de Node.js?

**Contexto:** Cliente tenía preferencia por stack Microsoft.

**Beneficios adicionales:**
- Performance superior (vs Node en APIs)
- Type safety nativa (C#)
- Entity Framework (ORM maduro)
- Integración fácil con Azure (deploy futuro)
- Equipo del cliente tenía familiaridad

---

## Lecciones Aprendidas

### 1. Infraestructura Retrasada? Prepare Alternativas

No espere servidores/credenciales para comenzar:
- Docker local es su amigo
- Mocks permiten progreso
- CI/CD puede ser preparado antes de tener dónde deployar

**Lección:** Controle lo que puede controlar.

---

### 2. Procesos > Herramientas

Incluso sin Git corporativo, establecí:
- Branching strategy
- Code review
- Commit conventions
- Documentation standards

**Resultado:** Cuando llegaron herramientas, equipo ya sabía usarlas.

---

### 3. Upskilling es Inversión, No Costo

Pair programming y code reviews tomaron tiempo, pero:
- ✅ Equipo quedó autónomo más rápido
- ✅ Calidad de código aumentó
- ✅ Knowledge sharing natural
- ✅ Onboarding de nuevos devs simplificado

---

### 4. Resiliencia Desde el Inicio

Implementar Polly (retry, circuit breaker) al inicio salvó en producción:
- Twilio tuvo inestabilidad (resuelta automáticamente)
- Salesforce tuvo mantenimiento (queue funcionó)
- CRM API tuvo lentitud (cache mitigó)

**Lección:** No deje resiliencia para "después". Fallas van a ocurrir.

---

### 5. Comunicación Clara de Riesgos

Reporté semanalmente:
- Bloqueos (infraestructura, credenciales)
- Riesgos (plazos, dependencias)
- Soluciones alternativas (mocks, workarounds)

**Resultado:** Stakeholders sabían exactamente el estado y no tuvieron sorpresas.

---

## Desafíos & Cómo Fueron Superados

| Desafío | Impacto | Solución | Resultado |
|---------|---------|---------|-----------|
| Sin Git | Bloqueo total | Setup local + GitLab Cloud | Equipo productivo día 1 |
| Sin servidores | Sin ambiente de dev | Docker Compose local | Dev/test local completo |
| Credenciales retrasadas | Integración bloqueada | Mock services | Progreso sin bloqueo |
| Equipo inexperto | Código de baja calidad | Pair prog + Code review | Ramp-up en 4 semanas |
| Múltiples integraciones | Complejidad alta | Polly + patterns | Zero downtime prod |

---

## Próximos Pasos (Post-MVP)

**Roadmap sugerido al cliente:**

1. **Fase 2: Expansión de funcionalidades**
   - Dashboard para médicos (histórico de pedidos)
   - Notificaciones push (Firebase)
   - Integración con e-commerce (compra directa)

2. **Fase 3: Optimizaciones**
   - Cache distribuido (Redis)
   - CDN para assets estáticos
   - Analytics avanzado (Amplitude)

3. **Fase 4: Escala**
   - Kubernetes (AKS)
   - Microservicios (quebrar monolito)
   - Event-driven architecture (Azure Service Bus)

---

**Resultado:** MVP entregado en producción a pesar de comenzar literalmente de cero, estableciendo fundaciones sólidas para transformación digital del cliente.

[¿Necesita construir un MVP en escenario desafiante? Póngase en contacto](#contact)
