Guía de construcción del MVP
Este documento convierte el backlog en un plan de obra: qué construir, en qué orden, con qué dependencias y cuándo está terminado. El cobro clínico se modela en tres niveles configurables por workspace — desde cero pasarelas hasta plataforma gestionada — para lanzar rápido sin cerrar puertas. Fuente de verdad del equipo desde el primer commit.
Resuelve los prerrequisitos externos y define el nivel de cobro de cada cliente. El Nivel 0 no necesita ninguna pasarela.
Sigue el orden de construcción. Cada etapa tiene un criterio de salida verificable; no avances sin cumplirlo.
Abre cada requerimiento en el catálogo antes de implementarlo: historia, criterios de aceptación, dependencias y nota de seguridad.
Prerrequisitos externos
Aprobaciones y sandboxes de terceros que no dependen de código. Inícialos en paralelo al Sprint 0: son los cuellos de botella reales del cronograma.
Stripe · entidad USA de Nikgu
Cuenta Stripe Billing de la empresa en Wyoming: productos, planes, portal de cliente y webhooks. Aplicar al programa Stripe Startups (créditos de procesamiento). Bloquea SUB-01. Único proveedor de pagos activo del MVP.
Google OAuth
Proyecto en Google Cloud, pantalla de consentimiento y scopes mínimos de Calendar. Bloquea INT-01 y la telemedicina.
Anthropic BAA + OpenRouter ZDR
BAA self-serve de Anthropic con org HIPAA-ready dedicada (permanente; separada de cargas no-PHI) para toda ruta con datos de paciente. OpenRouter con ZDR solo para rutas sin PHI (fallback y contenido genérico) — no firma BAA. Bloquea AI-01.
Meta / WhatsApp Cloud API
Verificación del negocio, número dedicado, plantillas aprobadas y webhook. El proceso de Meta puede tomar semanas. Bloquea WA-01 y WA-02.
Resend · dominio verificado
Cuenta de Resend, dominio de envío con SPF, DKIM y DMARC verificados, y región Sudamérica. Sin esto, los correos de confirmación caen en spam. Bloquea INT-02.
Legal básico del piloto
Términos de servicio, aviso de privacidad (Ley 8968) y opt-in de WhatsApp del paciente. Sin esto, el piloto no puede escribirle a nadie. Bloquea el hito de piloto (S4).
Sandbox ONVO
Cuenta de pruebas, Checkout y firma de webhooks. Solo se tramita al retomar el Nivel 1 (Fase 2). No bloquea el MVP.
Sandbox PayPal
Cuenta business sandbox, órdenes y webhooks de captura. Solo se tramita al retomar el Nivel 1 (Fase 2). No bloquea el MVP.
Revisión legal · Nivel 2
Merchant of record, impuestos, disputas y elegibilidad por país para recaudar en plataforma. Solo bloquea PAY-05 (Fase 2).
Stack de desarrollo
Un stack único, opinado y coherente con la arquitectura (monolito modular, Supabase, TypeScript de punta a punta). Regla: una sola herramienta por categoría; agregar una segunda requiere retirar la primera. Versiones fijadas en el repo, no aquí.
Núcleo de aplicación
TypeScript (strict)
Un solo lenguaje del frontend a los jobs. Tipos compartidos entre API, tools de agentes y UI.
Next.js (App Router)
Server Components para el dashboard, route handlers para webhooks, server actions para mutaciones. Un solo deploy.
Vercel
Previews por PR, edge network y cero DevOps. Región primaria us-east (la más cercana a CR con Supabase al lado).
pnpm workspaces + Turborepo
apps/web + packages: db, ai, emails, ui. Los tool schemas de agentes viven en packages/ai y se comparten con evals.
Datos
Supabase Postgres
RLS multi-tenant (SEC-01), Auth, Storage, Realtime para inbox y agenda, y pgvector cuando llegue RAG.
Drizzle ORM
SQL-first y typesafe; convive bien con policies RLS escritas a mano y migra por SQL versionado en CI.
Zod
Contrato único: inputs de API, tool schemas de agentes, variables de entorno y formularios validan con el mismo esquema.
Upstash Redis
Rate limiting por número del agente patient-facing (AGT-01), locks de idempotencia de webhooks y contadores calientes.
Trabajo en segundo plano
Inngest
Funciones durables con retries: procesamiento de webhooks (WhatsApp, pagos, Resend), secuencias de email, ejecuciones de agentes y crons. Reemplaza "events + queues" caseros.
SDK de Anthropic + AI Gateway propio
Claude Haiku para agentes de volumen, Sonnet para razonamiento y graders, con prompt caching y tool_choice (AI-01). OpenRouter queda como capa de fallback multi-proveedor del gateway.
Experiencia
Tailwind CSS + shadcn/ui
Tokens de la Paleta C (berenjena/verde, CTA en verde 700), Radix para accesibilidad, componentes en packages/ui (UI-01).
Brand book · Paleta C v1
Fuente de verdad visual: colores exactos, Inter/Fraunces, sentence case, reglas de contraste y pantallas de referencia (dashboard, agenda, bandeja de agentes). Ver el tab Sistema de diseño →
React Email + Resend
Plantillas como componentes versionados (INT-02); webhooks de entrega alimentan el CRM vía Inngest.
TanStack Query
Solo donde Server Components no alcanzan: inbox en vivo, agenda interactiva. Estado global mínimo.
Calidad y operación
Vitest + Playwright
Vitest para dominio y adapters (con los mocks de agenda como fixtures), Playwright para flujos críticos E2E, y la suite de evals de agentes (AI-03) en el mismo CI.
Sentry + Axiom
Sentry para excepciones con contexto de workspace; Axiom para logs estructurados y trazas de webhooks e Inngest.
PostHog
Analytics de producto, session replay, y feature flags — incluyendo los flags por país del Payment Orchestrator y el modelo marketplace.
GitHub Actions
Lint, tests, evals de agentes y migraciones Drizzle en cada PR; deploy por merge con previews de Vercel.
Registro de decisiones tecnológicas evaluadas
| Tecnología | Veredicto | Razón | Se revisa cuando |
|---|---|---|---|
| Stripe + Stripe Startups | Adoptado | Único proveedor de pagos activo del MVP: Billing para membresías desde la entidad USA. Aplicar al programa Startups por los créditos de procesamiento antes del primer cobro. | — |
| Resend | Adoptado | Email transaccional y secuencias (INT-02). React Email alineado al stack; webhooks alimentan el CRM. | — |
| OpenRouter | Adoptado | Capa de fallback y diversificación multi-proveedor dentro del AI Gateway (AI-01), con ZDR. El SDK de Anthropic es la vía primaria de los agentes por caching y tool_choice. | — |
| ONVO / PayPal | Abierto · Fase 2 | Cobro integrado de telemedicina (Nivel 1). El contrato del Payment Orchestrator ya los contempla como adapters; la telemedicina del MVP opera en Nivel 0. | El volumen de teleconsultas justifique automatizar el cobro. |
| Clerk | Descartado por ahora | Excelente DX y organizaciones B2B de primera, pero desplaza a Supabase Auth, que es nativo del RLS del que depende SEC-01. Agregaría un proveedor, costo por MAU y cableado de JWTs sin dolor que lo justifique. | Supabase Auth genere fricción real en flujos de organización/invitaciones. |
| Metronome | Descartado por ahora | Facturación por consumo de nivel enterprise. Las AI Units por plan con overage las cubre Stripe Billing con usage records a esta escala. | El billing por consumo se vuelva producto: múltiples métricas, contratos negociados, créditos. |
| BYO API key de IA (estilo BAPI) | Descartado por ahora | Idea del equipo (02-ago): clientes avanzados conectando su propia llave de modelo. Rompe el modelo de AI Units y complica la trazabilidad de PHI por el Gateway. | Clientes Enterprise lo exijan contractualmente; se diseñaría solo sobre rutas sin PHI o con BAA propio del cliente. |
| Jenkins (CI/CD) | En decisión | Propuesta del equipo (02-ago), atada a la decisión de stack: si gana Laravel/Vue en servidores propios, Jenkins es su CI natural; si gana el stack documentado, GitHub Actions + Vercel lo cubren sin instancia que mantener. | Se resuelve junto con el stack, antes de S0. |
| SSO entre Billing y Hampiora | Descartado por ahora | Identidad compartida entre una plataforma de salud y otros productos complica el aislamiento (checklist de seguridad) y la historia de cumplimiento. Cada producto con su auth en el MVP. | Exista un "Nikgu ID" formal con revisión legal — no antes de Fase 3. |
| PWA (instalable, escritorio) | Adoptado | Propuesta del equipo (02-ago): el web app se empaqueta como PWA — costo marginal, funciona en cualquier stack, y cubre el caso escritorio de recepción sin app nativa. | — |
| App nativa (Flutter) | Descartado por ahora | WhatsApp cubre el caso móvil del paciente y la PWA el de la clínica. Steven/Moisés como recurso identificado si llega el momento. | Tracción B2C real del Passport que exija experiencia nativa. |
| Video conectable (Zoom y otros) | Abierto · Fase 2 | El MVP usa Google Meet único (regla: una herramienta por categoría, ya integrada vía INT-01). La idea del equipo — que cada clínica conecte su plataforma — se diseña como adapters, igual que los pagos. | Clínicas del piloto lo pidan con volumen real de teleconsultas. |
| ActiveCampaign (API / white-label) | Descartado por ahora | Para marketing avanzado de clínicas. A $49–59/mes por cliente rompe el margen del plan, y Resend + secuencias propias cubren el MVP (INT-02). | Clientes Business/Enterprise exijan automatización de marketing que no convenga construir. |
| Modo offline con sincronización | Descartado por ahora | Miedo real de clientes a cortes de luz/internet. Complejidad técnica alta; el propio equipo propuso cobrarlo como integración adicional si se implementa. | Demanda pagada de clínicas en zonas de conectividad inestable. |
| Sanity | Descartado por ahora | Tecnología de primera, sin requerimiento que la exija: el producto vive en Supabase, las landings de clínicas son producto multi-tenant propio (FUN-01), y la web de marketing cabe en el repo. Nunca para PHI. | El contenido SEO editado por no-developers se active como canal (blog, guías, landings por país). |
Decisión abierta — dos stacks sobre la mesa (resolver antes de S0)
El equipo de desarrollo propuso su stack el 02-ago-2026. Ninguna opción gana por default: se decide en sesión dedicada con esta tabla en pantalla, y el resultado se escribe aquí. Lo único inaceptable es construir sin decidir.
| Capa / criterio | Stack documentado | Propuesta del equipo (Alberto · 02-ago) |
|---|---|---|
| Backend | TypeScript + Next.js (route handlers, server actions) | Laravel (PHP) — el stack de Billing, dominio total del equipo |
| Frontend | React (mismo Next.js, un solo deploy) | Vue — componentes construidos desde los HTML base de diseño |
| CI/CD y deploy | GitHub Actions + Vercel (previews por PR) | Jenkins en instancia propia, reutilizada de Billing |
| Base de datos y tenancy | Supabase Postgres con RLS nativo — SEC-01 se apoya en policies de base | Postgres/MySQL gestionado en servidor propio — el aislamiento multi-tenant se implementa en la capa de aplicación (o RLS manual, a diseñar) |
| Costo pre-ingresos | ~$50–150/mes (serverless, escala con uso) | ~$1.000/mes desde el día cero (servidores fijos, estimado del propio equipo) |
| Cumplimiento / ruta USA | Supabase, Vercel y Anthropic firman BAA | BAA depende del hosting elegido (AWS/GCP con BAA es viable); auditoría y cifrado se configuran a mano |
| Velocidad del equipo | Curva de aprendizaje para el equipo actual | Máxima — es el stack que el equipo opera a diario |
| Riesgo principal | Construir con herramientas que el equipo no domina aún | Runway (12k/año sin clientes) + rediseñar SEC-01 fuera de RLS nativo + aislamiento respecto a Billing (checklist de seguridad) |
Escenarios de cobro
La decisión de arquitectura más importante del producto: el cobro de telemedicina es un payment_mode configurable por workspace, en tres niveles. Cada clínica empieza en el nivel que pueda hoy y sube sin migrar datos. Las suscripciones SaaS viajan por un carril separado.
Sin pago integrado
MVP · día unoLa clínica cobra por su canal actual — SINPE, transferencia, datáfono o el link de su propia pasarela — y confirma el pago en el sistema. La cita queda pendiente hasta esa confirmación y el Meet se crea al confirmar.
Cuenta propia del cliente
Abierto · Fase 2Abierto para desarrollo eventual: la clínica conectaría su propia cuenta de ONVO o PayPal, con checkout generado por el sistema y confirmación por webhook. El contrato del Payment Orchestrator ya lo contempla; se retoma cuando el volumen de telemedicina lo justifique.
Plataforma gestiona
Fase 2 · hipótesisLa plataforma recauda, descuenta comisión automática y liquida a la clínica — Stripe Connect operado desde la entidad USA de Nikgu, u ONVO Marketplace / PayPal Multiparty según el país. Mejor experiencia, pero implica merchant of record, disputas y aprobación legal y fiscal.
Suscripciones SaaS
Carril separado · MVPLas membresías de la plataforma (Free, Starter, Professional, Enterprise) se cobran con Stripe Billing desde la empresa de Nikgu en USA. Nunca se mezclan con los fondos clínicos: la comisión contractual de telemedicina se incluye en esta factura.
Orden de construcción
Secuencia derivada de las dependencias reales entre requerimientos. Cada etapa deja el sistema en un estado usable y verificable. Haz clic en cualquier requerimiento para ver su detalle.
Catálogo de requerimientos
Los 40 requerimientos con su definición completa. Haz clic en una fila para abrir historia, criterios de aceptación, dependencias y nota de seguridad.
| ID | Título | Módulo | Prioridad | Estado | Fase | Complejidad |
|---|
Requerimientos por módulo
Vista de mapa: qué requerimientos componen cada módulo del backend. Útil para asignar ownership y estimar por bloque.
Modelo de datos inicial
Entidades núcleo con sensibilidad, política de acceso y retención. El modelo completo (ERD) se deriva de estas entidades más las tablas de soporte por módulo.
| Entidad | Propósito | Sensibilidad | Relaciones clave | Política RLS | Retención |
|---|---|---|---|---|---|
| organizations | Tenant principal | No sensible | workspaces, memberships | Por membership | Mientras exista cuenta |
| workspaces | Marca / target dentro de la organización | No sensible | organization, funnels, team | Por membership | Mientras exista cuenta |
| leads | Pipeline comercial | PII | contacts, activities, appointments | Por workspace | Configurable |
| contacts | Identidad de contacto comercial | PII | leads, conversations | Por workspace | Configurable |
| patients | Identidad del paciente | PHI | documents, consents, appointments | Consent + rol | Legal |
| appointments | Citas presenciales y telemedicina | PII | patient, professional, payment | Por workspace + rol | Legal |
| payments | Checkout, webhook, fee y refund | Financiero | appointment, provider_ref | Roles financieros | Legal / fiscal |
| documents | Archivos y extracción | PHI | patient, observations, consents | Consent + rol | Legal |
| consents | Alcance, expiración y revocación | Metadata | patient, grantee, resource | Paciente + auditor | Inmutable |
| ai_usage_events | Costos y unidades AI (sin PHI) | No sensible | workspace, user, feature | Admin / owner | 36 meses |
| audit_logs | Trazabilidad de accesos y cambios | Metadata | actor, resource | Solo auditor / admin | Inmutable |
Definition of Done
Un requerimiento no está terminado cuando el código compila; está terminado cuando cumple estas cuatro dimensiones.
Funcional
- Todos los criterios de aceptación verificados en staging
- Flujos de error y estados vacíos resueltos
- Responsive hasta móvil en pantallas de usuario final
Seguridad
- La nota de seguridad del requerimiento está implementada
- RLS probado con test de acceso cruzado cuando aplica
- Acciones sensibles registradas en audit_logs
Ingeniería
- Pruebas automatizadas de la lógica de dominio
- Webhooks idempotentes y con firma verificada
- Sin credenciales fuera del gestor de secretos
- Agentes: suite de evals en verde antes de desplegar (AI-03)
Producto
- Estado actualizado en este catálogo
- Costo AI medido en el ledger cuando la función usa IA
- Demo grabada o reproducible para el siguiente review
Sistema de diseño · Paleta C
El brand book integrado: identidad, color, tipografía y componentes. El brand book completo vive aquí, con el PDF original embebido al final. Regla madre: ningún hex fuera de esta paleta entra al código (UI-01 lo verifica con tests).
Capa estratégica — Brand Book v1.0
Idea central
"La salud que no espera. Medicina, ahora." El sistema de salud en LATAM falla por tiempo, no por conocimiento. La idea no se publica — se usa como filtro: toda decisión de producto, diseño y copy responde una pregunta: ¿esto hace que algo pase más rápido, en su momento, sin fricción? Si no, sobra.
El nombre — un linaje de mil años
Hampi es quechua: remedio, medicina. En el imperio inca, el hampicamayoc — "el poseedor de la medicina" — custodiaba y administraba el conocimiento médico del estado. Ora completa desde el español: vive dentro de ahora y de hora. Hampi + ora = medicina, ahora. El significado de la marca está dentro del nombre.
Sistema verbal — una raíz, cuatro capas
Marca: Hampiora. Tagline (mundial, EN): Care. Now. Yours. — vive pegado al logo. Descriptor: The intelligent clinic operating system ("Health OS" se activa cuando Passport salga de Beta). Conversión ES (capa comercial, no traducción): Medicina. Ahora. Tuya. — landings, ads, WhatsApp, demos.
Tres palabras, tres productos
Care → Hampiora Clinic (opera la medicina). Now → Hampiora Agents (la hace inmediata — capa embebida, nunca un SKU aparte). Yours → Hampiora Passport (la hace tuya, en Beta). Arquitectura monolítica: una marca madre; Clinic, Agents y Passport son descriptores, no marcas.
Principios de voz
Di qué sigue (toda comunicación termina en acción) · Corto gana (registro Einstein/Ogilvy) · Tú neutro LATAM · La AI se presenta (el agente siempre se identifica como Hampiora; jamás finge ser humano). Nunca dice "error" — dice qué hacer: ✓ "No se pudo enviar. Verifica y reintenta." ✗ "Error 4022".
Lo que Hampiora nunca es
Genérico-médico (cruz, estetoscopio, azul hospital) · Tech-frío (jerga AI, neones) · Informal-startup (memes, tono delivery) · Corporativo-burocrático ("estimado usuario"). Y prohibido el cliché textil andino: la herencia es linaje, no wallpaper.
Capa de especificación — Design System v1.0 · Paleta C
Logo — el nudo
Una H tejida inspirada en la estructura de hilo y nudo de un quipu. Representa conexión, continuidad, conocimiento y flujo de información — no un ornamento. Variantes: fondo claro, fondo berenjena, símbolo solo, un solo color. No: rotar, distorsionar, bajar contraste, agregar sombra.
Voz
Tecnología con calidez — humano, calmado, preciso. Tagline mundial: "Care. Now. Yours." · Capa de conversión ES: "Medicina. Ahora. Tuya." Español neutro LATAM, trato de tú, microcopy breve: "La cita quedó confirmada para el martes a las 10:00."
Color — no inventar tonos, usar exactamente estos hex
Berenjena · base de marca
Verde vivo · acento de acción — una sola CTA por vista, nunca decorativo
Neutrales · superficies, bordes, texto secundario
Semánticos · solo estados del sistema — el rojo jamás es color de marca
Tipografía — Inter para toda la interfaz · Fraunces solo momentos de marca
Capitalización y componentes
Sentence case por defecto
✓ Crear una cita · Historial de pagos · No se pudo enviar
✗ Crear Una Cita · HISTORIAL DE PAGOS · Error Al Enviar
Title Case solo para nombres de producto. UPPERCASE solo en overlines de máx. 2 palabras (HOY, URGENTE, BETA).
Contraste de botones (WCAG AA)
Primario: verde 700 + texto blanco = 5.3:1 ✓. Secundario: verde 500 + berenjena 900 = 5.8:1 ✓. Nunca texto blanco sobre verde 500 (2.96:1) — el test de UI-01 rompe el build. Alerta siempre con texto oscuro.
Etiquetas de estado
Confirmada Pago pendiente No asistió Sin confirmar Agente Borrador
Patrones de referencia
Dashboard con panel de Agents proponiendo acciones de un clic ("¿Le envío recordatorio?") — humano en el loop. Agenda semanal por profesional con estados semánticos. Bandeja de agentes con la nota visible: "gestiona agendas, recordatorios y seguimientos; no ofrece consejos médicos".
PDF original del sistema de diseño
Incluido en assets/hampiora-design.pdf. Si tu navegador no lo muestra embebido, ábrelo con el enlace.
Finanzas y modelo económico
Estructura de planes, lógica de costos, mezcla de ingresos y unit economics del caso base. Costos AI estimados con caching; el ledger (AI-02) los sustituye con datos reales desde la semana 1 del piloto.
Planes
| Free | Starter (Doctor) | Professional ★ | Business | Enterprise | |
|---|---|---|---|---|---|
| Precio | $0 | $99/mes | $299/mes | $599/mes | Custom |
| Profesionales | 1 | 1 | 5 | 15 | Ilimitado |
| Landings (FUN-01) | 1 con marca Hampiora | 1 | 3 | 10 | Custom + dominio |
| WhatsApp + agente disponibilidad | — | ✓ | ✓ | ✓ | ✓ |
| Agente de audio | — | — | ✓ | ✓ | ✓ |
| AI Units / mes | 30 | 500 | 2.000 | 6.000 | Custom |
| Excedente por 100 units | Bloqueo | $10 | $9 | $8 | Negociado |
| Comisión tele (contractual) | — | 10% | 10% | 7% | 3–5% |
Costos, margen y benchmark
| Concepto | Valor | Lectura |
|---|---|---|
| Costo blended por AI Unit | ~$0.012–0.014 | Haiku/Sonnet con caching; excedente a $0.09 → margen ~7× en overage |
| Margen bruto Professional | ~84% (COGS ~$49) | AI incluida ~$24, WhatsApp ~$9, infra ~$4, soporte ~$12 |
| Huli "cargado" (expediente + IA + Bot) | ~$92/mes +IVA | Starter $99 a paridad con Huli completo, pero commercial-first |
| Clinera (IA plana) | $279–479 | Valida Professional $299 y Business $599 en rango premium aceptado |
| Landing por agencia | $300–800 una vez | FUN-01 incluido cambia el ancla de "software" a "agencia" |
Mezcla de ingresos — escenario base 12 meses
| Mes | Clínicas | MRR SaaS | Comisión tele | Overage AI | MRR total |
|---|---|---|---|---|---|
| M3 | 2 | $568 | $60 | — | $628 |
| M6 | 14 | $3.864 | $408 | $20 | $4.293 |
| M9 | 33 | $9.412 | $994 | $50 | $10.455 |
| M12 | 59 | $16.762 | $1.771 | $89 | $18.621 · ARR ~$223k |
Flujo de caja y capital requerido (ago 2026 → dic 2028)
Modelo mensual sobre la estructura madre (ingresos → utilidad bruta → operativa → impuestos → flujo del periodo → caja), con lanzamiento comercial en enero 2027. El modelo vivo es el Excel incluido en la guía — descargar hampiora_flujo_caja.xlsx → — con selectores de stack y de escenario de precio, y todos los supuestos editables.
| Supuestos estructurales del modelo | Valor |
|---|---|
| Desarrollo y mantenimiento (rampa estimada) | $1k/mes (2026) → $2.5k → $5k (2027) → $8k → $10k/mes (2028) · acumulado ~$156k |
| Tools y membresías | $25→$286/mes (stack documentado) · $1.025→$1.100/mes (stack equipo) — selector en el modelo |
| Transferencias Mercury USA→CR | $35 fijo/mes + 1.5% FX sobre lo repatriado · ~$10.7k en el periodo — fila de gastos financieros |
| Impuesto sobre utilidad / tasa de descuento VAN | 10% (verificar con contador) · 15% anual |
| Altas de clínicas | 2 pilotos (dic-26, 50% precio) → 3–10/mes en 2027 → 12–16/mes en 2028 (especulativo, editable) |
Tablero comparativo — los tres escenarios de precio con la misma base de clientes y costos
| A · Ancla ($99/$299/$599) | B · Penetración ($59/$199/$449) | C · Premium ($149/$399/$799) | |
|---|---|---|---|
| MRR a dic-28 | $60.5k | $41.5k | $81.7k |
| Caja acumulada a dic-28 | $344.5k | $169.3k | $540.2k |
| Capital requerido (caja mínima) | −$11.8k | −$13.7k | −$11.0k |
| Meses con flujo negativo | 7 | 9 | 7 |
| VAN (15% anual) | $262k | $127k | $414k |
Unit economics (clínica típica, mix 30/55/15) y escenarios
| Métrica | Valor |
|---|---|
| ARPA blend / margen bruto | $284/mes · ~84% |
| CAC supuesto (el más débil del modelo) | $800 → payback 3.1 meses |
| LTV según churn 2% / 3% / 4% mensual | $12.700 / $8.467 / $6.350 · LTV/CAC 15.9× / 10.6× / 7.9× |
| Break-even operativo (burn $12k/mes) | ~50 clínicas · alcanzable M11–M12 del escenario base |
| Escenario A · Ancla de valor (recomendado) | $99/$299/$599 — se elige si ≥40% de entrevistas acepta $99 |
| Escenario B · Penetración | $59/$199/$449 — solo si <25% acepta; riesgo de churn alto y precio difícil de subir |
| Escenario C · Premium AI-first | $149/$399/$799 — solo si >60% acepta y pide más IA |
Seguridad de datos · estándar estilo HIPAA para LATAM
HIPAA no aplica legalmente fuera de EE.UU.; Hampiora la adopta voluntariamente como estándar de diseño, sobre el piso legal real: Ley 8968 (CR), LFPDPPP/NOM-024 (MX), Ley 1581 (CO), Ley 29733 (PE). La seguridad es producto, no anexo: se vende en cada demo.
Clasificación de datos
| Clase | Ejemplos | Dónde vive | Quién accede | Regla dura |
|---|---|---|---|---|
| PHI directo | Documentos clínicos, observaciones, notas, historial del Passport | patients, documents, consents (Storage cifrado) | Consent + rol clínico; jamás rol comercial | Nunca en WhatsApp, email ni prompts sin pseudonimizar (SEC-03) |
| PII | Nombre, teléfono, email, cédula de leads y contactos | leads, contacts, appointments | Por workspace y rol (RBAC de 02) | Minimización en canales externos; exportación solo propietario (EXP-01) |
| Operativo no sensible | Métricas, configuración, ai_usage_events (sin PHI), estados | Resto del esquema | Por rol | Único nivel permitido en logs y analítica |
Acceso y consentimiento del paciente
Consentimiento con alcance
Cada consent define qué (recurso), quién (profesional/clínica), para qué (propósito) y hasta cuándo (expiración). Sin consent vigente no hay lectura — el RLS lo hace físico, no política.
Revocación inmediata
Revocar invalida tokens y QR del Wallet en el acto; los accesos previos quedan en el registro inmutable, los futuros se bloquean. El paciente ve quién accedió y cuándo.
Separación comercial / clínico
Recepción y ventas operan leads y citas sin ver PHI; el médico ve pacientes autorizados sin exportación masiva. Doble control en acciones financieras (PAY-00).
Auditoría inmutable
audit_logs solo-inserción: actor, recurso, acción, momento. Toda lectura de PHI y toda confirmación manual de pago quedan registradas. Retención indefinida.
Controles de la capa de IA (Hampiora Agents)
| Control | Regla |
|---|---|
| Nunca en texto plano al modelo | Nombre completo, cédula/ID, teléfono, email, dirección, y cualquier diagnóstico vinculado a identidad. Lista versionada compartida entre Gateway y evals (SEC-03). |
| Pseudonimización antes de la llamada | El Gateway sustituye identificadores por tokens ({{PACIENTE_1}}, {{TEL_1}}) antes de todo call; rehidrata en la respuesta solo para el usuario autorizado. El modelo razona sin saber quién es. |
| Minimización por función | Cada ruta declara los campos que necesita; el Gateway rechaza contexto extra. El agente de disponibilidad solo ve slots, jamás motivos de consulta. |
| Proveedores | ZDR verificado por proveedor y por ruta; prohibido todo proveedor que entrene con datos; modelos de bajo costo solo en rutas sin datos de paciente (política de enrutamiento). |
| Qué se audita | Cada llamada: hash no reversible del input, feature, modelo, usuario, workspace, costo y latencia en ai_usage_events; cada tool call en tool_executions. Jamás el texto del prompt con datos. |
| Verificación continua | Test de fuga con PHI sintética en los evals (AI-03): un identificador en un prompt saliente = build roto. |
Matriz de proveedores — quién puede tocar datos de paciente
| Proveedor | BAA | Regla en Hampiora |
|---|---|---|
| Supabase | Sí (plan Team+ con add-on HIPAA) | Hogar de todo dato sensible. El add-on se activa con el primer cliente que lo exija; el diseño (RLS, cifrado, logs) ya cumple desde hoy. |
| Anthropic (SDK directo) | Sí (self-serve, org dedicada) | Única vía para llamadas de IA con datos de paciente. Org HIPAA permanente y separada de cargas generales. Features excluidas del BAA no se usan ahí. |
| Vercel | Sí (Enterprise) | Mientras tanto: cero PHI en URLs, headers, logs, cachés y analytics; todo dato sensible se media por APIs de Supabase. |
| OpenRouter | No | Excluido de toda ruta con datos de paciente. Solo fallback y contenido sin PHI (p. ej. borradores de landing). |
| WhatsApp / Meta | No (excluye uso sanitario) | Política dura de canal: solo contenido operativo y logístico, jamás contexto clínico. El detalle viaja por enlace autenticado al portal. Aplica también bajo Ley 8968/LGPD. |
| Stripe | No | Solo cobro de membresías: prohibido contexto de salud en metadata, descriptores y facturas. |
| Resend | No | Correo sin contexto de salud; el contenido sensible vive tras el enlace al portal. PHI por email exigiría proveedor con BAA. |
Flujo del canal WhatsApp — la política en acción
Decide el carril por regla, no por juicio del modelo. El agente solo tiene tools logísticas: no puede filtrar lo que nunca ve (SEC-03).
Disponibilidad, confirmaciones, recordatorios. Respuesta directa del agente, sin ningún dato clínico.
El mensaje solo avisa: "tienes una actualización" + enlace firmado, de un solo uso y con expiración → portal con verificación (OTP) → historial y recetas dentro del producto. El PHI jamás toca WhatsApp.
"¿Es grave este resultado?" — el agente ni responde ni enlaza: deriva a un humano de la clínica con contexto. Nunca consejo clínico.
Plan de respuesta a incidentes
Detectar
Alertas de acceso anómalo (volumen, horario, cruce de tenant), fallos de RLS en Sentry, monitoreo de exportaciones. Cualquier miembro del equipo puede declarar incidente sin aprobación.
Contener
Revocar tokens y sesiones afectadas, aislar credenciales comprometidas, congelar la ruta o feature involucrada vía flag. Objetivo: contención en <4 horas.
Evaluar
Con audit_logs y tool_executions: qué datos, de qué pacientes, en qué ventana, por qué vector. Clasificar severidad según clase de dato (PHI > PII > operativo).
Notificar
A la clínica afectada de inmediato; a titulares y autoridad según la ley aplicable — en Costa Rica, PRODHAB exige notificar en 5 días. Estándar interno adoptado: 72 horas máximo, más estricto que el plazo legal.
Remediar y aprender
Cerrar el vector, rotar secretos, post-mortem sin culpas con acciones fechadas, y actualización de este plan. El post-mortem se comparte con las clínicas Enterprise que lo pidan.
Checklist de cumplimiento
| MVP — mínimo viable (bloqueante para el piloto) | Pospuesto — con detonante definido |
|---|---|
| RLS multi-tenant con test de acceso cruzado en CI (SEC-01) | SOC 2 Type I → cuando el primer cliente Enterprise lo exija |
| Cifrado en tránsito y reposo (Supabase) + backups PITR verificados | Pentest externo anual → antes de Business/Enterprise a escala |
| Pseudonimización hacia IA operativa y testeada (SEC-03) | Cifrado a nivel de campo para PHI de alto riesgo → con el Passport (Beta) |
| audit_logs inmutable + auditoría de accesos a PHI (SEC-02) | Residencia de datos por país → con la expansión MX/CO |
| Consentimiento con expiración y revocación funcional | DPO formal / oficial de privacidad externo → >25 clínicas activas |
| Opt-in de WhatsApp + aviso de privacidad + ToS (gate legal) | Contratos tipo BAA con clínicas → segmento Enterprise |
| Aislamiento de infraestructura: el sistema de salud no comparte servidores, CI ni credenciales con otros productos (Billing, etc.) | |
| Secretos solo en gestor; acuerdos de confidencialidad del equipo | Certificación ISO 27001 → decisión comercial, no antes de año 2 |
| Política de contenido por canal (WhatsApp, email, Stripe): cero contexto clínico fuera del producto | Supabase HIPAA add-on + Vercel Enterprise → primer cliente de EE.UU. |
| BAA de Anthropic firmado y org HIPAA-ready dedicada para rutas con PHI | Cero píxeles/SDKs publicitarios en Passport → desde el diseño (riesgo FTC con usuarios US) |
| Política de retención por clase de dato documentada |
Roadmap a enero 2027
Seis meses, de agosto 2026 al MVP completo el 31 de enero de 2027, mapeados sobre las etapas de construcción. Dos hitos con fecha: piloto en producción el 30 de noviembre y MVP completo el 31 de enero. Los dos relojes que no controlamos — la aprobación de Meta y las entrevistas — arrancan en agosto o enero se mueve.
Validación + Fundaciones (S0)
En paralelo: las 15–20 entrevistas de validación (umbral 40% en $99 decide el escenario de precio) y el Sprint 0 — repo, entornos, Supabase, RLS con test de acceso cruzado, backups PITR. Los 9 gates se tramitan desde el día 1: Meta es el más lento y no puede esperar.
Salida agosto: escenario de precio elegido con datos, tenancy aislado probado, gates en trámite con fecha.
CRM núcleo (S1)
Tokens del sistema de diseño en código (UI-01), CRM con captura y pipeline, AI Gateway con ledger, pseudonimización (SEC-03) y la base de evals. Primer demo real a las clínicas entrevistadas.
Salida septiembre: un lead entra, avanza con auditoría, y cada llamada de IA queda medida y pseudonimizada.
Agenda y monetización (S2 + S3)
Agenda por profesional con Google Calendar/Meet, correo transaccional (Resend), onboarding e importación (ONB-01), Stripe Billing vivo con los planes, y telemedicina Nivel 0. Fecha límite dura: la aprobación de Meta debe cerrar este mes.
Salida octubre: una clínica importada agenda, confirma por correo y cobra su membresía por Stripe; una teleconsulta se confirma manualmente y crea el Meet.
Máquina de captación (S4) → 🏁 Piloto
Landing generada por Agents, quiz, inbox de WhatsApp, framework de evals y agente de disponibilidad — el ciclo commercial-first completo con guardrails verificados.
HITO · 30 de noviembre: 2–3 clínicas piloto en producción, pagando (50% × 3 meses), con el flujo landing → quiz → WhatsApp → agente → cita trazado de punta a punta.
Inteligencia con piloto vivo (S5a)
Scoring multidimensional entrenado con leads reales del piloto, next-best-action y el dashboard de funnel. Advertencia honesta: diciembre en Costa Rica rinde al 60% — el buffer del plan vive aquí, y nada del hito de enero depende de un diciembre completo.
Salida diciembre: el CRM prioriza y recomienda con datos reales; el dashboard muestra conversión por canal del piloto.
Cierre del MVP · 🏁 31 de enero 2027
El agente de audio para médicos (el cierre, no el requisito del piloto), hardening del checklist de seguridad MVP completo, y las correcciones que dos meses de piloto exijan.
HITO · 31 de enero 2027: MVP completo (etapas S0–S5 en verde) + decisión go/no-go de lanzamiento comercial con dos meses de datos reales de piloto: conversión, no-show, adopción y costo AI por clínica.