Requerimientos · MVP · Ejecución

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.

PASO 1

Resuelve los prerrequisitos externos y define el nivel de cobro de cada cliente. El Nivel 0 no necesita ninguna pasarela.

PASO 2

Sigue el orden de construcción. Cada etapa tiene un criterio de salida verificable; no avances sin cumplirlo.

PASO 3

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.

Gate list

Stripe · entidad USA de Nikgu

Cuenta Stripe Billing de la empresa en Wyoming: productos, planes, portal de cliente y webhooks. Bloquea SUB-01 (suscripciones SaaS).

Owner: Finance · Bloquea Sprint 3

Google OAuth

Proyecto en Google Cloud, pantalla de consentimiento y scopes mínimos de Calendar. Bloquea INT-01 y la telemedicina.

Owner: Platform · Bloquea Sprint 2

OpenRouter con ZDR

Cuenta, política Zero Data Retention y lista de modelos aprobados por privacidad. Bloquea AI-01.

Owner: AI · Bloquea Sprint 1

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.

Owner: Messaging · Bloquea Sprint 4

Sandbox ONVO

Cuenta de pruebas, Checkout y firma de webhooks. Bloquea PAY-02 — solo el Nivel 1 de cobro, no el MVP.

Owner: Fintech · Bloquea Nivel 1 (opcional)

Sandbox PayPal

Cuenta business sandbox, órdenes y webhooks de captura. Bloquea PAY-03 — solo el Nivel 1 de cobro, no el MVP.

Owner: Fintech · Bloquea Nivel 1 (opcional)

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).

Owner: Finance / Legal · Bloquea Fase 2

Ruta crítica del MVP: gracias al Nivel 0 de cobro, ninguna pasarela de pago bloquea el lanzamiento. Los únicos gates duros del MVP son Stripe Billing (para cobrar la membresía), Google OAuth, OpenRouter y Meta. ONVO y PayPal se activan por cliente, cuando cada clínica lo pida. Cada gate necesita responsable y fecha la primera semana.

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.

payment_mode

Sin pago integrado

MVP · día uno

La 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.

Quién cobraLa clínica, fuera del sistema

ConfirmaciónManual, auditada, con rol financiero

ComisiónContractual, en la factura SaaS

RequiereNada externo

Requerimientos: PAY-00 APT-03

Cuenta propia del cliente

Opcional · por clínica

La clínica conecta su propia cuenta de ONVO o PayPal. El sistema genera el checkout, el webhook confirma automáticamente y los fondos van directo al cliente. La plataforma nunca custodia dinero.

Quién cobraLa clínica, con sus credenciales

ConfirmaciónWebhook firmado, automática

ComisiónContractual, con conciliación

RequiereSandbox y onboarding por cliente

Requerimientos: PAY-02 PAY-03 PAY-04

Plataforma gestiona

Fase 2 · hipótesis

La 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.

Quién cobraLa plataforma (custodia fondos)

ConfirmaciónAutomática, con liquidación

ComisiónAutomática por transacción

RequiereAprobación legal, fiscal y de riesgo

Requerimientos: PAY-05

Suscripciones SaaS

Carril separado · MVP

Las 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.

Quién cobraNikgu (entidad USA) vía Stripe

ConfirmaciónWebhooks de suscripción

Aplica límitesPlan → workspaces, usuarios, AI Units

RequiereCuenta Stripe USA + Stripe Tax

Requerimientos: SUB-01

Por qué es la jugada ágil: el Nivel 0 elimina las pasarelas de la ruta crítica y permite firmar clínicas en cualquier país desde la primera semana. El Payment Orchestrator (PAY-01) garantiza que subir de N0 a N1 o N2 sea un cambio de configuración, no una reescritura.

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.

Build order

Congelamiento de alcance: nada entra a una etapa activa sin sacar algo equivalente. Las funcionalidades nuevas se registran como Fase 2 por defecto.

Catálogo de requerimientos

Los 29 requerimientos con su definición completa. Haz clic en una fila para abrir historia, criterios de aceptación, dependencias y nota de seguridad.

Backlog

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.

Dependency map

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.

ERD v0.6

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

Antes de escribir la primera migración: SEC-01 exige policies RLS con pruebas automáticas de acceso cruzado entre tenants. Escríbelas junto con las tablas, no después.

Definition of Done

Un requerimiento no está terminado cuando el código compila; está terminado cuando cumple estas cuatro dimensiones.

Calidad

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

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