Documento actualizado
El alcance se mantiene compatible con producto/decisiones-vigentes.md y matriz-funcionalidad-fase.md. Las funciones sacadas del MVP en la revisión 2026-07-11 (crédito, tarjetas, referidos, WhatsApp) ya no se incluyen.
Alcance del MVP¶
Documento de alcance — 2026-06-08 (v2)
Este documento define qué entra y qué no entra en el MVP operativo de IslaBox. Para los criterios de aceptación detallados (qué debe poder hacer el usuario/operador para que cada bloque se considere "hecho"), consultar criterios-aceptacion-mvp.md.
Relación entre los dos documentos:
- alcance-mvp.md (este) → qué se construye.
- criterios-aceptacion-mvp.md → cómo se sabe que está terminado (los 13 CA con sus checklists).
1. Definición de MVP¶
MVP de IslaBox = la versión mínima del sistema con la que un usuario de EE.UU. puede ejecutar el flujo completo de envío a Cuba — comprar, reportar, recibir, consolidar, pagar, despachar — sin asistencia manual externa (más allá del operador de almacén, que sí es parte del sistema).
Hipótesis a validar: que el flujo guiado por app + casillero propio + agencia aliada manual es viable como negocio y aporta suficiente valor para validar con beta cerrada antes de invertir en automatizaciones.
2. Lo que SÍ entra en el MVP¶
2.1 Módulos funcionales¶
| # | Módulo | Componentes incluidos |
|---|---|---|
| 1 | Autenticación y registro | Registro con verificación OTP, login, recuperación, edición de perfil, KYC completo |
| 2 | Casillero virtual | Asignación de CP-XXXXXX-D, dirección Miami copiable, tutoriales Amazon/SHEIN/Temu |
| 3 | Prealerta / reporte de compra | Formulario, lista, detalle con timeline, edición y cancelación |
| 4 | Paquetes físicos | Recepción (con fotos, peso, dimensiones), conciliación, listado, detalle con timeline |
| 5 | Almacenaje | Período gratis configurable (default 15 días), alertas, cargos automáticos |
| 6 | Consolidación y cotización | Selección, cálculo de costo, vigencia 7 días, recálculo si cambia peso |
| 7 | Pago y despacho | Registro manual de pago por operador, facturación, despacho con guía maestra |
| 8 | Tracking del envío | Timeline de 16 estados, notificaciones push en eventos clave |
| 9 | Servicios adicionales | Inspección, reempaque, devolución, con evidencia fotográfica |
| 10 | Incidencias y reclamos | 11 tipos, 8 estados, mensajes, evidencia, cierre con resolución |
| 11 | Notificaciones | Push (FCM) en eventos clave, historial en app, in-app badge |
| 12 | Gestión de contactos | Destinatarios en Cuba, remitentes en EE.UU. |
| 13 | Módulo informativo de aduana | Contenido Res. 175/2022 administrable |
| 14 | Tarifario visible | Costos de envío, servicios, cargos editables desde backoffice |
| 15 | Backoffice con colas operativas | Recepción, conciliación, KYC, servicios, consolidaciones, incidencias |
| 16 | Reporte de almacenamiento | RF-055: paquetes almacenados y próximos a vencer (MVP) |
2.2 Módulos NO incluidos en MVP (quedan para Fase 2+)¶
| # | Módulo | Fase |
|---|---|---|
| 17 | Programa de referidos (crédito, niveles, tarjetas) | 2 |
| 18 | Stripe como pasarela de pago online | 2 |
| 19 | OCR de capturas de órdenes | 2 |
| 20 | WhatsApp API | 3 |
| 21 | Tracking automático de transportistas (UPS, USPS, FedEx) | 2 |
| 22 | Lectura de QR/barcode en almacén | 2 |
| 23 | Webhook automático de agencia aliada | 2 (en MVP se hace manual) |
| 24 | Reportes administrativos avanzados (RF-052, RF-053, RF-054) | 2 |
| 25 | App iOS nativa | 2 |
| 26 | Web PWA | 2 |
2.3 Restricciones de diseño y de plataforma¶
- Plataforma MVP: solo Android nativo (Kotlin + Jetpack Compose).
- Idioma: solo español.
- País del usuario: solo EE.UU. (teléfono +1 obligatorio, ver reglas-negocio.md §Regla de origen).
- Pasarela de pago: registro manual por operador (no Stripe en MVP).
- Notificaciones: push (FCM) y email básico. No WhatsApp.
- Tracking: el operador actualiza manualmente el estado del envío (no hay integración automática con transportistas en MVP).
3. Lo que NO entra en el MVP (decisiones explícitas)¶
3.1 Funcionalidades excluidas¶
| Funcionalidad excluida | Razón de exclusión | Fase de reintroducción |
|---|---|---|
| Programa de referidos (RN-080 a RN-095) | Requiere base de usuarios activos; no es crítico para validar la hipótesis de envío | 2 |
| Stripe como pasarela online (RN-072, RN-073, RN-075) | Costo y tiempo de integración; MVP valida con pago manual | 2 |
| OCR de capturas (RF-046) | El usuario puede tipear; OCR agrega complejidad sin valor inmediato | 2 |
| WhatsApp API (RF-047) | Push + email cubren el MVP; WhatsApp es canal secundario | 3 |
| Tracking de transportistas (RF-051) | Sin contrato con APIs; operador actualiza manualmente | 2 |
| Lectura de QR/barcode en almacén (RF-050) | Operador digita identificador; escáner físico en Fase 2 | 2 |
| Webhook automático agencia (RF-048) | Sin agencia aliada con API en MVP; operador usa master_guide manual |
2 |
| Reportes avanzados (RF-052, RF-053, RF-054) | Backoffice mínimo; reporte de almacenamiento (RF-055) sí está en MVP | 2 |
| App iOS | MVP Android primero; iOS tras validar mercado | 2 |
| Web PWA | Móvil nativo es la prioridad | 2 |
3.2 Tipos de usuario no incluidos¶
- Destinatario en Cuba: nunca se registra, aparece como contacto del usuario registrado (siempre fue así).
- Remitente en EE.UU. distinto del usuario: modelado, pero la implementación completa del flujo de alta/edición se difiere al MVP-beta. El default es usar los datos del usuario.
3.3 Canales no incluidos¶
- WhatsApp: se difiere a Fase 3.
- SMS masivos (solo OTP): se mantiene para verificación; otros SMS no se envían en MVP.
- Llamadas de voz: no se ofrece canal de voz en MVP.
4. Cobertura esperada por capa¶
| Capa | Componentes en MVP | Componentes fuera de MVP |
|---|---|---|
| App Android | 16 módulos (ver §2.1) | 10 módulos (ver §2.2) |
| Backend | Servicios para los 16 módulos MVP + auth + archivos + notificaciones | Programa de referidos, Stripe, OCR, WhatsApp |
| Backoffice | Colas de los 9 flujos operativos + config básica de tarifas y categorías | Reportes avanzados, auditoría detallada |
| Base de datos | Todas las tablas de los 16 módulos | Tablas de referidos/crédito (se crean vacías) |
5. Criterios de salida del MVP (resumen)¶
El MVP se considera listo para beta cerrada cuando se cumplen los 13 criterios de aceptación documentados en criterios-aceptacion-mvp.md. Si alguno está rojo, el lanzamiento beta se retrasa.
Métricas de éxito en beta (primeros 60 días, 50–100 usuarios):
| Métrica | Objetivo |
|---|---|
| Tasa de registro completo (llega a ver dirección) | ≥ 80% |
| Tasa de primera prealerta creada | ≥ 60% |
| Tiempo medio desde registro hasta primera prealerta | ≤ 7 días |
| Tasa de KYC aprobado a la primera | ≥ 70% |
| Tasa de paquetes correctamente conciliados (sin intervención) | ≥ 85% |
| Tasa de consolidación creada por usuarios con 2+ paquetes | ≥ 50% |
| Tiempo medio desde consolidación hasta despacho | ≤ 5 días |
| NPS de usuarios activos | ≥ 30 |
| Tickets de soporte por usuario activo | ≤ 2 al mes |
6. Cómo se conecta con otros documentos¶
- Criterios de aceptación:
criterios-aceptacion-mvp.md— los 13 CA detallados. - Roadmap completo:
../_archivo/roadmap/mvp.md— lista de 19 funcionalidades del MVP con prioridad. - Fase 2 (lo que viene después):
fase-2.md— siguiente ola de desarrollo. - Decisiones de negocio:
preguntas.md— preguntas resueltas que afectan el alcance. - APK estado actual:
../apk/estado-actual.md— qué hay implementado en código vs qué está documentado. - Matriz de trazabilidad:
../_archivo/rup/02-elaboracion/matriz-trazabilidad.md— cobertura de requisitos (actualmente 18%).