PredatorAlgo Landing

🇪🇸 Entregables del equipo — PredatorAlgo Landing (8–23 jun 2026)

Resumen: En esta quincena el equipo (Alvaro, Leonardo y Oscar, en conjunto) dejó el recorrido compra → acceso automático funcionando de punta a punta y blindó la base legal y de copy. Esto es lo que se entregó, por propósito — no por cantidad de tickets.

🎯 Entregables (qué quedó funcionando)

Actores por entregable — 🥇 principal · 🤝 apoyo (según quién resolvió los tickets).

🏗️ Arquitectura & base del repo

Scaffold inicial + arquitectura del repo (Next.js App Router, layout, config) · infraestructura de agentes Claude Code + slash-commands de GitHub/Jira · tooling de dev (MCPs, OpenSpec) · CI (lint/type-check/test en Node 22) · test infra (Vitest) · dominio y deploy (Cloudflare + Vercel → predatoralgo.com). _Base fundacional, may 2026._

Actores: 🥇 Oscar · 🤝 Alvaro _(dev tooling/agents, SD-1218)_ · 🤝 Leonardo _(config de deploy, vercel.json)_

_Tickets: SD-1172, SD-1173, SD-1183, SD-1224, SD-1268, SD-1185, SD-1200, SD-1218._

💳 Pagos con Stripe — en producción, cobro real

Cobro en vivo (claves y prices live, fix de configuración que tiraba el checkout) · botones de pricing y CTA conectados al Checkout · captura en el pago de usuario de TradingView, Telegram y consentimiento de email · modelo de suscripción directa sin trial con reembolso de 7 días · cancelación self-serve vía el portal de Stripe · cumplimiento de auto-renovación (§7.4) · cupón de dev 99% off detrás de feature flag.

Actores: 🥇 Oscar · 🤝 Alvaro

_Tickets: SD-1283, SD-1281, SD-1282, SD-1288, SD-1280, SD-1294, SD-1300, SD-1278, SD-1293, SD-1332, SD-1246, SD-1302, SD-1338, SD-1325._

📧 Creación de correo — dominio propio

Casilla support@predatoralgo.com creada (Hostinger + Cloudflare) + dominio de remitente propio con DKIM/DMARC y reply-to, para que los correos de Stripe lleguen y no caigan en spam.

Actores: 🥇 Oscar · 🤝 Alvaro

_Tickets: SD-1383, SD-1350._

🔓 Acceso automático a TradingView

El cliente paga y recibe el indicador solo: cliente endurecido de TradingView + webhook de Stripe que otorga/extiende/revoca acceso · estado operativo en Redis · cola de fallback + ruta de grant manual para los casos que fallan · cron diario que revoca a los vencidos · soporte de múltiples indicadores · clasificación de fallos (permanente vs transitorio).

Actores: 🥇 Leonardo · 🤝 Oscar

_Tickets: SD-1254, SD-1255, SD-1256, SD-1257, SD-1258, SD-1352, SD-1337._

✈️ Comunidad VIP en Telegram

Invitación de un solo uso generada automáticamente tras el pago · seguimiento de miembros y expulsión automática al vencer el acceso · Telegram opcional en el checkout · evento de "join" medido en analítica · control de seguridad: barrido + reintento de kicks fallidos (backstop) con cobertura de tests.

Actores: 🥇 Alvaro · 🤝 Leonardo _(control de seguridad de kicks, SD-1313/1326/1327)_ · 🤝 Oscar

_Tickets: SD-1259, SD-1308, SD-1311, SD-1368, SD-1363, SD-1313, SD-1326, SD-1327._

🖥️ Panel de administración / operaciones

Dashboard para operar los casos que el automático no resuelve: colas de grant/revoke/refund · cola de grant manual con email y usuario de TradingView legibles · botón Diagnose con el error real · Refresh payment con total pagado · persistencia de pestaña · runbook de operador · capacitación del dashboard a Guadalupe · corrección de usuarios mal ingresados: "Guardar usuario TV" otorga acceso + captura/grant condicional + toasts por resultado.

Actores: 🥇 Oscar · 🤝 Alvaro · 🤝 Leonardo _(corrección de usuarios mal ingresados, SD-1339/1343/1344)_

_Tickets: SD-1253, SD-1245, SD-1365, SD-1370, SD-1369, SD-1371, SD-1357, SD-1339, SD-1343, SD-1344._

🎨 Landing pública (páginas y UI)

Páginas construidas: /pricing, /how-it-works, /education, /about, /faq, /checkout/success · navbar + menú mobile + breakpoints para tablet · identidad visual (motivo "reticle" + glow) · hero video optimizado (AV1/VP9/H.264) · fixes visuales de mobile · tabla de precios responsive.

Actores: 🥇 Alvaro · 🤝 Leonardo

_Tickets: SD-1233, SD-1234, SD-1235, SD-1236, SD-1249, SD-1247, SD-1250, SD-1360, SD-1231, SD-1345, SD-1349, SD-1355, SD-1271, SD-1364, SD-1361._

✍️ Landing copy & mensajería

Copy de toda la landing alineado a la "Bible": home reescrito a la voz de marca · cobertura/claims neutralizados frente a competidores · FAQ de 13 preguntas · copy de billing para el modelo no-trial / reembolso 7 días.

Actores: 🥇 Alvaro · 🤝 Leonardo

_Tickets: SD-1229, SD-1252, SD-1296, SD-1366, SD-1239, SD-1301, SD-1270._

⚖️ Legal & compliance

Páginas legales (Términos, Privacidad, Billing, Cookies, Disclaimer de trading) revisadas a fondo · drafts de disclaimer + billing · auditoría de Claims Policy · links legales normalizados.

Actores: 🥇 Alvaro · 🤝 Leonardo

_Tickets: SD-1237, SD-1240, SD-1367, SD-1372._

🍪 Cookie consent & banner

Página de Cookie Policy + banner de consentimiento (frontend-only) en la landing: el usuario acepta/rechaza y la analítica se dispara solo con consentimiento.

Actores: 🥇 Oscar

_Ticket: SD-1358._

📈 Analítica & SEO

Google Analytics 4 en vivo con eventos de conversión y medición del join a Telegram · SEO completo de la landing.

Actores: 🥇 Oscar · 🤝 Alvaro

_Tickets: SD-1284, SD-1346, SD-1363, SD-1359, SD-1242._

✅ Calidad (QA / tests)

Suite Playwright E2E (landing + funnel de checkout + manage-subscription) · test harness de pago/acceso · testing manual de UX/UI de toda la landing y de los flujos de suscripción/cancelación.

Actores: 🥇 Leonardo · 🤝 Oscar

_Tickets: SD-1347, SD-1251, SD-1353, SD-1362._

⏳ Pendientes — qué falta para el lanzamiento V1

Para V1 quedan solo 2 pendientes, ambos con dueño:

Novedades:

• SD-1248 (gate de checklist pre-launch) ya está en Done ✅.
• El trabajo post-MVP (historial de "kicked" SD-1324 · reconcile bidireccional SD-1304 · refactor de reconcile.ts SD-1329) se movió a la nueva épica Predatoralgo V2 (SD-1228) — fuera del alcance de V1.

Lectura: el producto está funcionalmente completo. V1 depende de dos cosas, ambas con responsable: que Franco termine el indicador (SD-1171) y que Rafael cierre la revisión legal (SD-1238). Nada más bloquea el lanzamiento.

🤖 Opinión de la IA — ¿es un MVP funcional?

Lectura honesta basada en los datos de Jira + el código (commit 218d1f9). Es una opinión, no un dato de Jira.

Veredicto: sí, es un MVP funcional — y bastante más maduro que un MVP típico. El recorrido que importa (pagar → recibir acceso al indicador y al canal VIP → poder cancelar) está implementado de punta a punta, con Stripe en producción, automatización de grant/revoke y un panel de operaciones para los casos que fallan. La mayoría de los MVPs llegan a "se puede pagar"; este llega a "se puede pagar, se entrega solo, y si algo falla un operador lo resuelve". 🟢

Proceso 🟢 — Muy sólido para el tamaño del equipo.

• El pipeline de acceso (cliente endurecido → webhook → estado → fallback → cron) es un diseño pensado, no parches sueltos. La cola de fallback + runbook de operador es justo lo que evita que un fallo de grant se vuelva un cliente enojado.
• _Riesgo a vigilar:_ la cola de fallback no tiene reintento automático (depende del operador), y la integración con TradingView es por scraping de su API privada → frágil ante cambios de su lado. Sugerencia: alerta proactiva (Slack) cuando la cola supere N items o expire la sesión de TV.

Legal / compliance 🟡 — Bien encaminado, con un bloqueante real.

• Ya está hecho lo difícil: auditoría de Claims Policy, compliance de auto-renovación §7.4, reembolso consistente, cookie banner + consent y revisión a fondo de las páginas legales. El gate pre-launch (SD-1248) ya se cerró ✅.
• SD-1238 (revisión de abogado externo) ya tiene dueño (Rafael Valdivia) — falta completarla. Para un producto de trading, lanzar sin esa firma es el riesgo más caro del proyecto. Recomendación: ponerle fecha de cierre esta semana — es el camino crítico, junto con el indicador.

Copy 🟢 — Cuidado y alineado a compliance.

• Se nota trabajo serio: neutralizar claims vs competidor, alinear todo a la "Bible", FAQ de 13 preguntas, copy de billing acorde al modelo legal. En un producto de trading el copy es de los puntos más expuestos legalmente, y acá se trató como tal.
• _Sugerencia:_ los mensajes de error del borde (usuario TV inválido — SD-1309/1310) también son copy de cara al cliente; cerrarlos con un mensaje claro evita tickets de soporte justo después de pagar.

Qué sugeriría además (priorizado):

1. Desbloquear el camino crítico: poner fecha de cierre a SD-1171 (indicador) y SD-1238 (legal, ya con Rafael). Sin esos dos, lo demás no habilita el lanzamiento.
2. Observabilidad mínima: alertas a Slack ante fallos de webhook/grant y tamaño de la cola de fallback. Hoy el éxito operativo depende de que alguien mire el dashboard.
3. Manejo de errores de cara al cliente: cerrar el caso "usuario de TradingView inválido en el checkout" (SD-1309/SD-1310, hoy fuera de la épica) — es el peor momento para una mala experiencia: el cliente ya pagó.
4. Post-MVP: reintento automático de la cola de fallback y reconcile bidireccional (SD-1304) para no depender del operador a medida que escale el volumen.

En una línea: el equipo construyó un MVP que ya es vendible; lo que falta no es producto, es firmar lo legal, crear el indicador y pulir el manejo de errores antes de abrir la canilla de tráfico pago.

Fuentes: Jira épica SD-1170, entregables pasados a "Done" entre 2026-06-08 y 2026-06-23. Datos reales de Jira; la sección "Opinión de la IA" es análisis, claramente separado.