Fecha del diagnóstico: 27 de agosto de 2026
Responsables: Boris (producto y tecnología) y Gonzalo (marketing y ventas)
Acasito tiene el núcleo necesario para iniciar un piloto controlado y asistido: el sitio de producción responde, existe un flujo de creación de tiendas, onboarding, catálogo, tienda pública, carrito, checkout con comprobante, administración de pedidos y despliegue automatizado.
No está listo todavía para un lanzamiento público abierto. Los principales bloqueos son seguridad de credenciales, coherencia de precios y planes, cobertura de pruebas de archivos y checkout, respaldo y recuperación, validación completa del flujo en producción, definición de entregas, textos legales y preparación comercial.
La recomendación es lanzar primero un piloto con 5 a 10 tiendas, acompañadas directamente por Gonzalo y Boris. El cobro de la suscripción y la coordinación de entregas pueden ser manuales durante el piloto, siempre que esa política se comunique claramente. El lanzamiento público debe ocurrir después de validar ese piloto.
| Hito | Estado | Condición para avanzar |
|---|---|---|
| Piloto con 5–10 tiendas | Amarillo | Completar todas las tareas P0 |
| Lanzamiento público | Rojo | Completar P0, aprender del piloto y completar P1 |
| Etapa | Boris | Gonzalo | Duración probable trabajando en paralelo |
|---|---|---|---|
| P0: preparar y ejecutar el piloto | 56–97 h | 57–90 h | 3–5 semanas |
| P1: preparar lanzamiento público | 64–114 h | 60–99 h | 4–8 semanas adicionales |
Las horas son horas-persona aproximadas e incluyen implementación y verificación, pero no tiempos de espera de proveedores ni correcciones imprevisibles encontradas durante el piloto.
- Creación de una o varias tiendas por administrador.
- Onboarding de datos de la tienda, categorías, productos y diseño.
- Administración de productos, variantes, categorías, marcas, imágenes y páginas.
- Tienda pública con catálogo, categorías, marcas, búsqueda, ofertas y páginas.
- Carrito, checkout, carga de comprobante y consulta de pedidos.
- Administración de pedidos, ventas, inventario y POS.
- Vista previa de la tienda en un dominio separado antes de publicarla.
- Autenticación por correo y Google en un entorno multi-tienda.
- Catálogo interno de planes y registro de suscripción por organización.
- Aplicación desplegada en contenedores con PostgreSQL y pgvector.
- Proxy y certificados TLS administrados por Caddy.
- Almacenamiento de imágenes compatible con S3.
- Correo transaccional mediante Amazon SES.
- Trabajos en segundo plano con Oban.
- Registro de errores con Sentry.
- Despliegue automático desde
mainmediante GitHub Actions. - El sitio
https://acasito.apprespondió HTTP 200 durante este diagnóstico. - El último despliegue de
mainterminó correctamente el 25 de agosto de 2026.
- Existe una suite amplia de pruebas de contextos, LiveViews y flujos críticos.
mix precommitterminó con 510 pruebas aprobadas y 19 omitidas durante este diagnóstico.- El onboarding del issue #4 está implementado; falta validar sus criterios de aceptación y cerrar o actualizar el issue.
- El repositorio está privado y el archivo
.envlocal está ignorado por Git.
- Credenciales versionadas. El README y
.env.examplecontienen valores con forma de credenciales. Aunque el repositorio es privado, deben considerarse expuestos: revocar, rotar, reemplazar por ejemplos inequívocamente falsos y revisar el historial. - Cambios locales no desplegados. El entorno local tiene múltiples archivos modificados; la producción sigue en el commit
abd5b87. Debe estabilizarse una versión candidata y desplegarla de manera controlada. - El despliegue no ejecuta pruebas. El workflow construye y despliega directamente al hacer push a
main; no existe una compuerta que impida desplegar cuando falla la suite. - Pruebas críticas omitidas. Hay 19 pruebas marcadas como
skip, principalmente sobre archivos, comprobantes y checkout. Esas áreas tocan dinero y datos del cliente. - Planes y precios inconsistentes. La landing muestra Bs 0/99/199 con nombres y beneficios de ejemplo, mientras el catálogo interno usa Bs 50/100/200. Tampoco se encontró una interfaz pública de selección/cobro ni aplicación de límites por plan.
- Entregas sin definición suficiente. El issue #3 (“Mejorar las entregas”) no tiene alcance. Hoy el checkout indica que la entrega se coordina por WhatsApp. Puede servir para el piloto, pero debe declararse como política y probarse con clientes reales.
- Respaldo y recuperación no operados. Hay instrucciones puntuales, pero no se encontró automatización de backups, política de retención ni evidencia de una restauración probada.
- Validación de producción incompleta. HTTP 200 y un deploy exitoso no prueban Google OAuth, SES, S3, dominios, checkout, comprobantes, correos y administración de pedidos de extremo a extremo.
- Operación comercial y soporte no definidos. No están establecidos canal de soporte, horario, responsable, SLA, proceso de escalamiento ni registro de prospectos/clientes.
- Definir si el cobro de suscripciones será automático o inicialmente asistido.
- Aplicar estado, vencimiento y límites del plan dentro del producto.
- Reemplazar todos los nombres y beneficios de ejemplo en la landing.
- Publicar privacidad, términos, política de cookies y datos de contacto.
- Añadir analítica del embudo: visita → registro → tienda creada → producto publicado → primer pedido.
- Preparar SEO básico: títulos, descripciones, sitemap, robots y tarjetas para compartir.
- Probar rendimiento, accesibilidad y seguridad en producción.
- Tener rollback de despliegue y restauración de base de datos ensayados.
- Convertir el aprendizaje del piloto en material de venta, onboarding y soporte.
Todas estas tareas deben estar terminadas antes de incorporar las primeras 5–10 tiendas del piloto.
| ID | Tarea | Responsable | Horas | Dependencia | Terminado cuando… |
|---|---|---|---|---|---|
| P0-01 | Rotar credenciales expuestas y limpiar ejemplos/versionado | Boris | 3–5 h | Ninguna | Todos los secretos están revocados, los ejemplos son falsos y se documentó qué fue rotado |
| P0-02 | Consolidar los cambios locales en una versión candidata | Boris | 6–10 h | P0-01 | El diff está revisado, la suite pasa y existe un commit candidato identificable |
| P0-03 | Añadir pruebas como compuerta antes del despliegue | Boris | 4–6 h | P0-02 | GitHub Actions no despliega si fallan pruebas o build |
| P0-04 | Corregir el orden del deploy y documentar rollback | Boris | 3–5 h | P0-03 | Migraciones y arranque ocurren de forma segura y se puede volver al release anterior |
| P0-05 | Habilitar o reemplazar las pruebas skip críticas de checkout/S3 |
Boris | 10–18 h | P0-02 | No quedan pruebas omitidas en comprobantes, almacenamiento y checkout crítico |
| P0-06 | Ejecutar smoke test completo en producción | Boris | 6–10 h | P0-02, P0-05 | Se prueba crear tienda, publicar producto, comprar, subir comprobante, recibir correos y administrar pedido |
| P0-07 | Automatizar backup y probar una restauración | Boris | 5–8 h | Ninguna | Existe backup periódico, retención definida y restauración ensayada |
| P0-08 | Definir oferta, nombres, precios y límites del piloto | Gonzalo 4–6 h; Boris 4–8 h | 8–14 h total | Ninguna | Landing, discurso comercial y datos internos muestran la misma oferta |
| P0-09 | Definir política mínima de entrega y retiro | Gonzalo 3–5 h; Boris 4–8 h | 7–13 h total | P0-08 | El cliente entiende zonas, costo, plazo y coordinación; el checkout refleja esa decisión |
| P0-10 | Preparar privacidad, términos y contacto básico | Gonzalo 6–10 h; Boris 3–5 h | 9–15 h total | P0-08 | Los textos fueron revisados y están publicados y enlazados |
| P0-11 | Configurar alertas, runbook y canal de soporte | Boris 4–7 h; Gonzalo 3–5 h | 7–12 h total | P0-06 | Hay alertas accionables, pasos de diagnóstico, canal visible y responsable de respuesta |
| P0-12 | Definir cliente ideal y propuesta de valor del piloto | Gonzalo | 6–10 h | Ninguna | Existe un segmento principal, problema, promesa, objeciones y criterio de cliente apto |
| P0-13 | Crear tienda demo, guion de demo y material de venta | Gonzalo | 8–12 h | P0-08, P0-12 | Gonzalo puede mostrar el flujo completo en 15 minutos con datos realistas |
| P0-14 | Construir lista y contactar prospectos | Gonzalo | 12–18 h | P0-12, P0-13 | Hay al menos 30 prospectos calificados, contacto registrado y próximo paso definido |
| P0-15 | Reclutar 5–10 tiendas para el piloto | Gonzalo | 10–16 h | P0-14 | Al menos 5 aceptaron fecha, alcance, precio piloto y canal de soporte |
| P0-16 | Crear protocolo de onboarding y seguimiento del piloto | Gonzalo 4–6 h; Boris 3–5 h | 7–11 h total | P0-06, P0-15 | Hay checklist por tienda, métricas, registro de problemas y entrevistas semanales |
| P0-17 | Resolver issues #3 y #4 | Boris 1–2 h; Gonzalo 1–2 h | 2–4 h total | P0-09 | #4 se cierra si cumple; #3 queda con alcance, criterio de aceptación y prioridad |
Estas tareas comienzan después de obtener evidencia del piloto; no deben retrasar el aprendizaje inicial salvo que una tienda piloto las necesite.
| ID | Tarea | Responsable | Horas | Terminado cuando… |
|---|---|---|---|---|
| P1-01 | Implementar selección, cobro y renovación de planes o formalizar venta asistida | Boris 12–22 h; Gonzalo 4–6 h | 16–28 h total | El cliente sabe cómo contratar, pagar, renovar y cancelar |
| P1-02 | Aplicar vencimiento y límites de cada plan | Boris | 6–10 h | Los límites de productos/variantes y acceso vencido se aplican y prueban |
| P1-03 | Finalizar copy, beneficios, testimonios y preguntas frecuentes de la landing | Gonzalo 8–12 h; Boris 4–6 h | 12–18 h total | No hay placeholders y cada CTA lleva a una acción medible |
| P1-04 | Implementar analítica del embudo y tablero semanal | Boris 3–5 h; Gonzalo 3–5 h | 6–10 h total | Se miden adquisición, activación, primera publicación y primer pedido |
| P1-05 | SEO técnico y contenido inicial | Boris 4–6 h; Gonzalo 6–10 h | 10–16 h total | Metadatos, sitemap, robots y páginas objetivo están publicados |
| P1-06 | Revisión de accesibilidad, seguridad y rendimiento | Boris | 10–18 h | No quedan hallazgos críticos y se registran métricas base |
| P1-07 | Automatizar rollback y completar pruebas de recuperación | Boris | 6–10 h | Deploy anterior y backup pueden restaurarse dentro del tiempo acordado |
| P1-08 | Crear CRM y proceso de ventas repetible | Gonzalo | 5–8 h | Etapas, responsables, seguimiento, motivos de pérdida y forecast están definidos |
| P1-09 | Crear campaña y calendario de lanzamiento | Gonzalo | 12–20 h | Hay canales, piezas, fechas, presupuesto, responsables y métricas |
| P1-10 | Crear guía de onboarding, videos y base de ayuda | Gonzalo 6–10 h; Boris 3–5 h | 9–15 h total | Un cliente puede completar tareas frecuentes sin ayuda directa |
| P1-11 | Buscar alianzas y canales de distribución | Gonzalo | 8–16 h | Hay conversaciones y próximos pasos con al menos 5 aliados potenciales |
| P1-12 | Incorporar feedback y estabilizar después del piloto | Boris 16–32 h; Gonzalo 8–12 h | 24–44 h total | Problemas P0/P1 del piloto están resueltos o explícitamente aceptados |
- Decidir alcance técnico y proteger la calidad del producto.
- Mantener seguridad, infraestructura, backups, observabilidad y despliegues.
- Convertir problemas repetidos de clientes en mejoras pequeñas y verificables.
- Publicar releases y comunicar cambios o riesgos a Gonzalo.
- Mantener una fuente única para planes, límites y precios técnicos.
- Ser dueño de posicionamiento, marketing, ventas y relación comercial.
- Mantener la lista de prospectos, CRM, seguimiento y forecast.
- Realizar demos, entrevistas, onboarding comercial y seguimiento de clientes.
- Producir copy, casos de uso, testimonios, campañas y materiales de venta.
- Traer evidencia concreta de objeciones, pérdidas y necesidades, evitando convertir cada pedido individual en una función.
- Reunión semanal de lanzamiento de 60–90 minutos.
- Revisar métricas del embudo y problemas del piloto.
- Decidir juntos precio, segmento, promesa y prioridades.
- Ninguna nueva función entra al piloto sin indicar qué cliente la necesita y qué decisión comercial permitirá tomar.
- 5–10 tiendas activadas.
- Tiempo desde registro hasta primer producto publicado.
- Porcentaje que completa onboarding sin intervención de Boris.
- Tiendas que reciben al menos un pedido real.
- Errores o bloqueos por tienda y tiempo de resolución.
- Entrevista semanal y satisfacción cualitativa.
- Intención de continuar pagando después del piloto.
- Al menos 5 tiendas completaron el flujo crítico en producción.
- Al menos 3 recibieron un pedido real o simulado de extremo a extremo.
- Ningún incidente crítico de pérdida de datos, autenticación, comprobantes o pedidos.
- Backup y restauración probados.
- Oferta, precio, soporte y entregas comprendidos por los clientes sin explicación adicional.
- Existe un canal comercial capaz de generar prospectos de forma semanal.
No deben bloquear el piloto salvo evidencia de clientes:
- Dominios personalizados como función premium.
- Automatización avanzada de WhatsApp.
- Nuevas funciones de IA no necesarias para publicar y vender productos.
- Más tipos de páginas, componentes visuales o personalización profunda.
- Expansión a más idiomas o mercados.
- Refactorizaciones amplias sin impacto visible en seguridad, confiabilidad o ventas.
- Boris ejecuta P0-01 y crea una versión candidata limpia.
- Gonzalo ejecuta P0-08 y P0-12 para cerrar oferta, precio y cliente ideal.
- Ambos acuerdan por escrito la política mínima de cobro y entregas.
- Boris valida el flujo completo en producción mientras Gonzalo prepara demo y prospectos.
- Se incorporan primero 2 tiendas amigas; después de una semana estable, se amplía a 5–10.
Este documento debe actualizarse semanalmente con estado, horas reales, hallazgos del piloto y cambios de prioridad.