Ondas repriorizadas
Las ondas se mantienen como guía, pero cada iniciativa debe evaluarse contra producto/decisiones-vigentes.md y el backlog P0/P1 antes de ser aceptada.
Fase 2 — Alcance y roadmap¶
Documento de planificación — 2026-06-07
Define qué se construye después del MVP, en qué orden, y qué criterios se usan para incorporar o rechazar funcionalidades.
Este documento se complementa con:
alcance-mvp.md— qué entra en MVPproximos-pasos.md— acciones inmediatasintegraciones.md— integraciones planificadaspreguntas.md— dudas abiertas
1. Definición de Fase 2¶
Fase 2 = funcionalidades que aportan valor claro al usuario o al negocio, pero que no son necesarias para validar la hipótesis de MVP (que es: "un usuario de EE.UU. puede enviar paquetes a Cuba a través de un casillero en Miami").
2. Hipótesis de Fase 2¶
| # | Hipótesis | Métrica de validación |
|---|---|---|
| H1 | El programa de referidos con créditos incrementa la adquisición de usuarios en ≥ 30% | Crecimiento mensual de referidos activos |
| H2 | La integración con Stripe (pagos online) reduce la fricción de pago en ≥ 50% (medido por tiempo de pago) | Tiempo promedio de pago |
| H3 | La app iOS abre mercado a usuarios iPhone (≥ 20% del mercado de envíos a Cuba) | Descargas iOS vs Android |
| H4 | El OCR de capturas de órdenes reduce errores de datos en prealertas en ≥ 70% | Tasa de error por reporte |
| H5 | El tracking automático de transportistas mejora la confianza del usuario (medido por NPS) | NPS del feature de tracking |
| H6 | WhatsApp como canal de notificación aumenta el engagement con notificaciones en ≥ 40% | Tasa de apertura de notificaciones |
| H7 | El programa de niveles (fidelidad) aumenta el LTV del usuario en ≥ 25% | LTV por cohorte |
3. Funcionalidades priorizadas¶
3.1 Onda 1 (meses 4–6 post-MVP)¶
| Funcionalidad | Hipótesis | Esfuerzo | Impacto |
|---|---|---|---|
| Pagos online con Stripe | H2 | M | Alto |
| App iOS | H3 | XL | Alto |
| Notificaciones WhatsApp | H6 | M | Medio |
| Programa de referidos nivel 1 | H1 | L | Alto |
| Tracking automático de transportistas (UPS, USPS) | H5 | M | Medio |
| Reportes administrativos (3 básicos) | Operacional | S | Medio |
3.2 Onda 2 (meses 7–9)¶
| Funcionalidad | Hipótesis | Esfuerzo | Impacto |
|---|---|---|---|
| OCR de capturas de órdenes | H4 | M | Alto |
| Programa de niveles + pool promocional | H7 | M | Alto |
| Referidos nivel 2 y 3 | H1 | M | Medio |
| Tarjetas promocionales canjeables | H1 | M | Medio |
| Panel de operador móvil (app) | Operacional | L | Medio |
| Integración API con segunda agencia aliada (contingencia) | Continuidad | M | Crítico |
3.3 Onda 3 (meses 10–12)¶
| Funcionalidad | Hipótesis | Esfuerzo | Impacto |
|---|---|---|---|
| Centro de soporte (tickets) | Operacional | L | Medio |
| Chat en vivo operador ↔ usuario | Operacional | M | Medio |
| Cotización de envíos masivos (B2B) | Negocio | L | Alto (nuevo mercado) |
| Integración con Shopify/WooCommerce | Negocio | M | Medio |
| Búsqueda global en la app | UX | S | Bajo |
| Modo oscuro | UX | S | Bajo |
4. Detalle de cada funcionalidad¶
4.1 Pagos online con Stripe (Onda 1)¶
Descripción: el usuario paga directamente desde la app con tarjeta, vía Stripe Checkout. Webhook confirma el pago y dispara la consolidación.
Tickets:
- Integración con Stripe API + Checkout
- Webhook POST /webhooks/stripe con firma HMAC
- Manejo de idempotencia
- Tabla webhook_events para auditoría
- UI: pantalla de checkout en la app
- Reemplazo del flujo "operador registra pago manual"
Criterios de aceptación: - Usuario puede pagar con tarjeta Visa/Mastercard/Amex. - Webhook confirma en < 5 segundos. - Si falla el pago, se notifica y se libera la consolidación. - Auditoría completa del flujo.
Referencia: api-contract §pagos, CU-014.
4.2 App iOS (Onda 1)¶
Descripción: port de la app Android a iOS usando Kotlin Multiplatform (compartiendo lógica de negocio) o reescritura con Swift/SwiftUI.
Decisión técnica pendiente: KMP vs Swift nativo. - KMP: más rápido, menos bugs, comparte código con Android. - Swift nativo: mejor UX, animaciones nativas, mejor soporte de Apple Pay.
Tickets: - Decisión de arquitectura - Configurar proyecto Xcode - Implementar pantallas (mismas que Android) - Integrar con FCM (APNS) - TestFlight interno → externo - App Store review
Criterios de aceptación: - Paridad funcional con Android. - Animaciones fluidas (60 fps). - Compatible con iOS 15+. - App Store rating ≥ 4.5.
4.3 Notificaciones WhatsApp (Onda 1)¶
Descripción: además de push, email y SMS, enviar notificaciones críticas (pago confirmado, incidencia, entrega) por WhatsApp Business API.
Tickets: - Aprovisionar número de WhatsApp Business - Integración con proveedor (Twilio WhatsApp o Meta Cloud API) - Plantillas de mensajes pre-aprobadas - Opt-in/opt-out del usuario - Manejo de respuestas (palabras clave: "ALTO", "INFO")
Criterios de aceptación: - Mensaje llega en < 30 segundos. - Usuario puede darse de baja vía "STOP". - Métricas de entrega reportadas.
4.4 Programa de referidos nivel 1 (Onda 1)¶
Descripción: el usuario comparte su código. Cuando alguien se registra con ese código y completa su primer envío, ambos reciben crédito promocional.
Tickets:
- Tablas referrals, credit_balances, credit_movements
- Pantalla "Invita a un amigo"
- Lógica de acreditación al primer envío completado del referido
- Email/push al referir con link personalizado
Reglas: - 180 días de ventana desde el registro del referido - Crédito al referir: $10 - Crédito al referido: $10 - Vencimiento del crédito: 12 meses - Aplica solo a envíos ≥ $50
4.5 Tracking automático de transportistas (Onda 1)¶
Descripción: el sistema consulta automáticamente las APIs de UPS/USPS para mantener actualizado el estado de los paquetes en tránsito hacia Miami.
Tickets:
- Integración con UPS API (requiere registro de negocio)
- Integración con USPS API
- Polling cada 6h
- Webhook donde esté disponible
- Mapeo de estados externos a package.status
4.6 OCR de capturas de órdenes (Onda 2)¶
Descripción: el usuario toma foto de su orden de Amazon/SHEIN. El sistema extrae automáticamente: tienda, número de orden, fecha, valor, descripción.
Tickets: - Integración con AWS Textract o Google Document AI - Modelo de entrenamiento con órdenes de las 3 tiendas - Validación humana si confianza < 80% - UI: pre-llenar formulario desde OCR
Riesgo: la calidad de OCR varía mucho entre las 3 tiendas. Hacer MVP con Amazon (más estructurado) y extender después.
4.7 Programa de niveles (Onda 2)¶
Descripción: 3 niveles de usuario (Bronce, Plata, Oro) basados en envíos completados. Cada nivel otorga beneficios (descuentos, prioridad, sorteos).
Tickets:
- Tabla user_levels + reglas de ascenso/descenso
- Pantalla "Mi nivel y beneficios"
- Cálculo automático al final de cada mes
- Notificación al cambiar de nivel
Reglas (propuesta): - Bronce: 0–2 envíos - Plata: 3–9 envíos - Oro: 10+ envíos o $1000+ acumulados
5. Funcionalidades en consideración (no confirmadas)¶
| Funcionalidad | Estado | Próximo paso |
|---|---|---|
| Multi-idioma (inglés) | Pendiente | Encuesta a usuarios para validar demanda |
| Marketplace propio (comprar dentro de la app) | Descartado | No es el core del negocio |
| Web pública (sin app) | Pendiente | Evaluar en Q3 |
| Programa de agencias franquiciadas | Pendiente | Depende de regulación cubana |
| Envío de dinero (remesas) | Descartado para Fase 2 | Evaluar Fase 3 si cambia regulación |
6. Métricas de éxito de Fase 2¶
| Métrica | Baseline MVP | Objetivo Fase 2 |
|---|---|---|
| MAU (usuarios activos mensuales) | 100 | 5,000 |
| Envíos/mes | 50 | 1,000 |
| NPS | (a medir) | ≥ 50 |
| Tasa de pago online vs manual | 0% | 70% |
| Tasa de retención a 90 días | (a medir) | 50% |
| CAC (costo de adquisición) | (a medir) | < $15 |
| LTV (valor de vida) | (a medir) | > $200 |
7. Recursos necesarios¶
| Recurso | Onda 1 | Onda 2 | Onda 3 |
|---|---|---|---|
| Desarrolladores backend | 2 | 2 | 2 |
| Desarrolladores Android | 1 | 1 | 1 |
| Desarrollador iOS | 1 (nuevo) | 1 | 1 |
| Diseñador UX/UI | 0.5 | 0.5 | 0.5 |
| QA | 0.5 | 1 | 1 |
| DevOps | 0.5 | 0.5 | 0.5 |
| PM | 1 | 1 | 1 |
| Total FTE | 6.5 | 7 | 7.5 |
8. Riesgos de Fase 2¶
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|---|---|---|
| Stripe rechaza la cuenta por OFAC | Media | Alto | Tener plan B con otro procesador o esperar a legal |
| El OCR no funciona bien con SHEIN/Temu | Alta | Medio | MVP con Amazon, luego iterar |
| App Store rechaza la app | Baja | Crítico | Seguir guidelines, evitar menciones a "Cuba" en metadata |
| Cambios regulatorios en Cuba | Alta | Crítico | Asesoría legal continua, plan de contingencia |
| Sobrecosto de iOS | Media | Medio | Empezar con KMP, evaluar Swift después |
9. Criterios para incorporar una nueva funcionalidad a Fase 2¶
Antes de agregar algo, validar:
- ¿Atiende al menos 1 hipótesis de las 7? Si no, no se hace.
- ¿Mejora una métrica de éxito? (MAU, NPS, LTV, etc.)
- ¿Cuál es el esfuerzo? Si es XL (> 1 quarter) requiere aprobación de dirección.
- ¿Hay dependencia regulatoria? Si sí, requiere visto bueno legal.
- ¿Compite con otra funcionalidad de mayor impacto? Priorizar la de mayor impacto.
10. Cómo se actualiza este documento¶
- Trimestralmente: revisión del equipo de producto.
- Cuando cambia una hipótesis validada: actualizar la sección de hipótesis.
- Cuando se completa una funcionalidad: marcarla y mover a "lanzadas".