Informe de entregas día por día — PredatorAlgo Landing

Cronología real de desarrollo (27 may → 24 jun 2026) · por equipo

Propósito. Mostrar, con datos verificables y trazables, qué se construyó en PredatorAlgo Landing y en qué tiempo. Cada afirmación está respaldada por tickets de Jira (épica SD-1170 — PredatorAlgo Landing), por commits y Pull Requests reales del repo swissbull-group/predatoralgo, y —para la conclusión de madurez— por la lectura del código real. Nada está inventado; donde un dato no existe, se dice. Se agrupa por equipo, no por persona.

---

1. Lectura rápida

En 19 días laborales (27 de mayo – 24 de junio de 2026), un equipo de 3 desarrolladores construyó y

puso en producción la landing de PredatorAlgo con cobro real por Stripe y automatización de acceso a

TradingView y Telegram.

⏱️ Duración real: 19 días laborales. El período del 27 de mayo al 24 de junio de 2026 abarca 28 días corridos, de los cuales se descuentan sábados, domingos y 2 feriados nacionales de Bolivia (Corpus Christi, 4 de junio y Año Nuevo Andino, 21 de junio) → quedan 19 días laborales. El equipo tuvo actividad en 20 días — es decir, trabajó todos los días hábiles y además el feriado de Corpus Christi (15 commits el 4 de junio). No hubo días muertos dentro de la jornada hábil.

Reparto de esfuerzo: los 422 commits y los 89 PRs fueron trabajo del **equipo completo en

paralelo (no en serie). Por eso este informe agrupa todo por equipo y por área funcional (scope)** —

nunca por persona.

Contexto clave (ver §5): durante estas mismas semanas el equipo no estuvo dedicado solo a PredatorAlgo. De los 350 tickets que los 3 devs cerraron en la ventana, solo 101 fueron de PredatorAlgo; los otros 249 fueron de otros frentes (sobre todo la campaña de marketing BK/PF). PredatorAlgo se entregó compartiendo el equipo con varias prioridades a la vez.

---

2. Cómo leer este informe (fuentes y método)

• Jira (SD-1170). Cada "entrega" del día = un ticket cuyo estado pasó a Done ese día. Los SD-###

son la evidencia trazable. Muchos llevan prefijo [T-xx]/[AUTO-x]: son los ítems del Bible/spec del

proyecto (.docs/creation-tasks/SD-1212-…).

• GitHub (predatoralgo). Commits y PRs por día corroboran el trabajo real integrado (rama por

defecto main; no hay rama develop).

• Código real. La §8 (conclusión de madurez de la IA) se basa además en la lectura del código del

repositorio, no solo en Jira/GitHub.

• Por equipo, no por persona. No se atribuye trabajo individual.
• Honestidad sobre lo no terminado (§6) y sobre la arquitectura (§8), incluidas sus limitaciones.

---

3. Línea de tiempo — día por día

Cada día es un desplegable: el título resume qué se hizo; al abrirlo se ven los tickets y la actividad (cerrados · commits · PRs). Por defecto están colapsados. Fines de semana y feriados omitidos. En los días sin tickets cerrados se muestran las tareas en progreso y los commits.

Semana 1 — Scaffold, dominio y tooling (27–29 may)

Mié 27 may — Arranque del repositorio (commit inicial). Sin tickets cerrados aún.

En progreso: scaffold inicial del proyecto.

Commits del día (1): Initial commit.

Actividad: 0 done · 1 commit · 0 PRs

Jue 28 may — Scaffold de la landing V1 (reframe + listo para lanzar), conexión del dominio predatoralgo.com (Hostinger + Cloudflare) e infraestructura de agentes de Claude + comandos de PR.

Tickets: SD-1172, SD-1185, SD-1173 · 3 done · 19 commits · 3 PRs

Vie 29 may — Configuración de Cloudflare y Vercel apuntando al dominio real predatoralgo.com; importación y adaptación de los comandos de IA al proyecto.

Tickets: SD-1200, SD-1183 · 2 done · 9 commits · 2 PRs

Semana 2 — Branding, specs y arquitectura de pagos (1–5 jun)

Lun 1 jun — Sin tickets cerrados: limpieza visual de la landing (unificar fondos, quitar secciones) en curso.

En progreso (referido en commits): SD-1202.

Commits del día (4): unificar fondos de secciones con grilla de decoración · quitar la sección Trading Journal de la landing · ignorar caché de tooling.

Actividad: 0 done · 4 commits · 1 PR

Mar 2 jun — Branding y assets de la landing (fondos oficiales, mejoras de logo y copy, imagen del hero con el gráfico de TradingView) y setup de tooling de desarrollo (Supabase agents/skills, MCPs, GGA, OpenSpec).

Tickets: SD-1184, SD-1198, SD-1214, SD-1216, SD-1202, SD-1218, SD-1224 · 7 done · 26 commits · 4 PRs

Mié 3 jun — Lectura de documentación y creación/refinamiento de las tareas del proyecto; rediseño de precios (Pro/Lifetime) y el spike de arquitectura de Stripe (contrato + smoke-test).

Tickets: SD-1212, SD-1227, SD-1260, SD-1232, SD-1243 · 5 done · 23 commits · 3 PRs

Jue 4 jun *(feriado de Corpus Christi — trabajado)* — Stack tipográfico y tokens de color de marca; productos, precios y checkout de Stripe (con 2 campos personalizados) + infraestructura de tests (Vitest).

Tickets: SD-1230, SD-1244, SD-1268 · *(SD-1199 marcado "no se hará", reemplazado por SD-1244)* · 5 done · 15 commits · 3 PRs

Vie 5 jun — Sin tickets cerrados: páginas y cliente de TradingView en curso.

En progreso (referido en commits): SD-1236 (página /about), SD-1264 (esquemas y cliente HTTP endurecido de TradingView).

Commits del día (2): construir la página /about (brand-story) · lib/tradingview schemas + expiración + cliente HTTP endurecido.

Actividad: 0 done · 2 commits · 0 PRs

Semana 3 — Páginas, checkout y automatización de acceso (8–12 jun)

Lun 8 jun — Páginas del sitio (/pricing, /about, /faq), motivo visual "reticle" (glow + scanline), página /checkout/success y cumplimiento de auto-renovación §7.4 (nativo de Stripe).

Tickets: SD-1233, SD-1236, SD-1249, SD-1231, SD-1269, SD-1246, SD-1247, SD-1271 · 8 done · 33 commits · 6 PRs

Mar 9 jun — Día intenso: páginas /how-it-works y /education, contenido de FAQ, navbar; wiring del checkout de Stripe (server action), correcciones de variables de entorno de Stripe en producción; primeros bloques de automatización (cliente TradingView, estado en Redis).

Tickets: SD-1234, SD-1235, SD-1239, SD-1250, SD-1281, SD-1270, SD-1278, SD-1279, SD-1282, SD-1288, SD-1254, SD-1256, SD-1280 · 13 done · 38 commits · 9 PRs

Mié 10 jun — [AUTO-2] Webhook de Stripe (otorgar/extender/revocar acceso), auditoría de Claims Policy, completar SEO y harness de tests de pago/acceso.

Tickets: SD-1255, SD-1240, SD-1242, SD-1251 · 4 done · 27 commits · 7 PRs

Jue 11 jun — [AUTO-4] Cola de fallback híbrida + ruta de grant manual, reconciliación del home con el Bible §5.1, consentimiento de marketing en el checkout (3er campo) y ajustes de política de reembolso.

Tickets: SD-1257, SD-1229, SD-1252, SD-1296, SD-1293, SD-1294, SD-1299, SD-1241 · 8 done · 38 commits · 9 PRs

Vie 12 jun — Automatización de Telegram: [AUTO-6] invite de un solo uso, [AUTO-7] tracking y expulsión de miembros (captura de user_id al unirse) y el [T-26] dashboard de operaciones (colas + grant/revoke/refund).

Tickets: SD-1259, SD-1308, SD-1253 · 3 done · 29 commits · 4 PRs

Semana 4 — Pivot sin-trial, go-live y panel de admin (15–19 jun)

Lun 15 jun — Pivot del modelo de cobro: se elimina el trial de $1/10 días → suscripción directa con reembolso de 7 días; [AUTO-5] cron de revocación + reconciliación, ops de Telegram en el dashboard y reconciliación de la ventana de reembolso (10d→7d).

Tickets: SD-1300, SD-1301, SD-1302, SD-1258, SD-1311, SD-1313, SD-1328 · 7 done · 29 commits · 8 PRs

Mar 16 jun — Cancelación self-serve por el Customer Portal de Stripe, clasificación de fallos permanentes/transitorios en el webhook, cupón dev (99% off) tras feature flag, GA4 + eventos de conversión y "Save TV username" que también otorga acceso.

Tickets: SD-1332, SD-1337, SD-1338, SD-1284, SD-1339, SD-1303, SD-1325, SD-1289 · 8 done · 29 commits · 6 PRs

Mié 17 jun — Runbook de fallback (operador: grant/revoke/refund), suite E2E con Playwright (landing + funnel de checkout + manage-subscription) y refresh de la landing (hero video, Features & How-It-Works).

Tickets: SD-1245, SD-1292, SD-1347, SD-1345 · 4 done · 20 commits · 3 PRs

Jue 18 jun — *Día pico.* Stripe go-live (cobro real con claves y precios live) + dominio de email propio (@predatoralgo.com con DKIM/DMARC); soporte de múltiples indicadores invite-only (TV_PINE_IDS), legal (disclaimer + billing), cookie policy + banner de consentimiento, testing manual completo y fixes de UX móvil.

Tickets: SD-1283, SD-1350, SD-1237, SD-1352, SD-1351, SD-1363, SD-1358, SD-1353, SD-1355, SD-1360, SD-1361, SD-1349, SD-1357, SD-1346, SD-1359 · 15 done · 40 commits · 10 PRs

Vie 19 jun — Revisión meticulosa de cumplimiento de todas las páginas legales, mejoras del panel de admin (cola de grant manual con email+usuario TV, botón Diagnose, "Refresh payment" por fila, persistir tab por query param) y tests manuales de update/cancel por el portal.

Tickets: SD-1367, SD-1365, SD-1370, SD-1369, SD-1371, SD-1366, SD-1372, SD-1362, SD-1364 · 9 done · 26 commits · 6 PRs

Semana 5 — Cierre: lifetime, Telegram y legal (23–24 jun)

Mar 23 jun — Username de Telegram opcional en el checkout y purga del @username en todo el flujo; fix del checkout Lifetime (pago único no otorgaba acceso porque session.customer venía null); email de soporte y gate de checklist pre-lanzamiento.

Tickets: SD-1368, SD-1385, SD-1386, SD-1383, SD-1384, SD-1248 · 6 done · 9 commits · 3 PRs

Mié 24 jun — Clientes Lifetime ahora pueden unirse/ser gestionados en Telegram (re-key del flujo desde subscriptionId a customerId) y fix del email de contacto legal + redes del footer. Último día de actividad del período.

Tickets: SD-1390, SD-1394 · 2 done · 5 commits · 2 PRs

---

4. Entregas por área funcional (scope)

Todo lo entregado (106 Done), agrupado por área.

Nota: 6 tickets transversales (lectura de documentación y creación de tareas del Bible, confirmación de comportamiento v2.3, CSP, gate de checklist pre-lanzamiento) no se asignan a una sola área. La automatización de acceso (filas 2) es el corazón técnico del producto: conecta el pago con el acceso real a TradingView y Telegram.

---

5. Saltos de proyecto (project jumps) — el equipo estuvo compartido

Durante la ventana de PredatorAlgo (15 may – 29 jun), los 3 desarrolladores cerraron 350 tickets en

total; solo 101 fueron de PredatorAlgo (SD-1170). Los otros 249 fueron de otros frentes — es

decir, PredatorAlgo se construyó sin dedicación exclusiva.

Lectura: el mayor frente paralelo fue la campaña de marketing y email de BK/Profunded (SD-821, 54 tickets, corre toda la ventana) más el stack de Resend/DNS/React-Email. PredatorAlgo avanzó rápido a pesar de compartir al equipo con esas prioridades — no con dedicación completa.

---

Fuente de §5 (trazabilidad): los agregados (350 totales · 101 de SD-1170 · 249 en otros epics) provienen de Jira con la JQL assignee in (Leonardo, Alvaro, Oscar) AND resolved >= "2026-05-15" AND resolved <= "2026-06-29", excluyendo la épica SD-1170. Cifras aproximadas (extracción: 29 jun 2026).

6. Pendientes (estado real en Jira)

De los 111 tickets de la épica, 5 no están Done:

Los pendientes reales son pocos: el principal gate de negocio es la revisión legal externa (depende del cliente/Rafael) y dejar publicados los indicadores en TradingView.

---

7. Conclusión (datos)

1. Ritmo alto y sostenido: 106 tickets, 89 PRs y 422 commits en 19 días laborales (~22 commits/día

hábil), con actividad en los 20 días disponibles —incluido un feriado— y cero días muertos.

1. Alcance entregado: landing completa, cobro real por Stripe en producción (go-live 18 jun) y una

automatización de acceso que conecta el pago con TradingView y Telegram de punta a punta.

1. Con el equipo compartido: se logró mientras el mismo equipo llevaba la campaña de marketing

BK/PF y otros frentes (§5) — solo 101 de 350 tickets del período fueron de PredatorAlgo.

1. Pendientes menores, varios dependientes del cliente (revisión legal, indicadores TV).

---

8. 🤖 Conclusión de la IA — madurez del proyecto (análisis sincero)

Esta sección fue generada por la IA (Claude). Es una valoración honesta e independiente —no un argumento de venta—, basada en los datos de Jira/GitHub y en la lectura del código real del repositorio y de su spec/"Bible" (.docs/creation-tasks/SD-1212-…).

Veredicto: funcional, pero arquitectónicamente inmaduro (por diseño deliberado y documentado).

PredatorAlgo cumple su objetivo de MVP —vender acceso, otorgarlo automáticamente al pagar y revocarlo al

cancelar— y lo hace con piezas de buena calidad. Pero no es un producto con backend real, y eso marca un

techo claro de escalabilidad y mantenibilidad.

Lo que está sólido (funcional):

• 🟢 Flujo de pago y acceso de calidad de producción. Webhook de Stripe con verificación de firma,

idempotencia (Redis), cola de fallback y cron de reconciliación; cobro real en vivo desde el 18 jun.

• 🟢 Automatización de acceso real. El pago dispara acceso a TradingView y un invite único de Telegram,

con tracking y expulsión automática — no es una maqueta.

• 🟢 Buenas prácticas de ingeniería en lo que existe: módulos separados (lib/stripe, lib/redis,

lib/tradingview, lib/telegram), helpers tipados, tests Vitest y CI en cada PR.

Lo que lo hace inmaduro en arquitectura (con evidencia en el código):

• 🟡 No hay backend real — Stripe es la "base de datos". El dashboard se arma con una llamada en vivo a

Stripe (stripe.customers.list, tope de 100 clientes, sin paginación), y el estado de negocio (plan,

access_granted, usuario TV/Telegram) vive como metadata de texto en Stripe, sin esquema, migraciones

ni integridad referencial. La única persistencia propia es Redis (estado operacional).

• 🔴 No hay autenticación de aplicación. El panel de administración depende **enteramente de una política

de Cloudflare Access en el borde; no hay login, sesión, roles (RBAC) ni tabla de usuarios. Es un único

punto de fallo**: si esa política se desconfigura, todo el panel (datos de clientes, acciones de grant)

queda públicamente accesible.

• 🔴 NowPayments (cripto) no existe — ni stub ni parcial. El spec lo declara fuera de alcance de esta

iteración. Para soportarlo hay que construir la integración completa (webhook, idempotencia, mapeo de

acceso) desde cero.

Conclusión. Para algo rápido y de lanzamiento, usar Stripe como fuente de verdad está bien y fue

una decisión correcta y documentada en el Bible (que difiere Supabase/auth/NowPayments a V1.5/V2). Pero para

que el producto crezca —que funcione NowPayments, y que exista un **dashboard real con usuarios

autenticados y autorizados— hay que reestructurar este pseudo-backend (Stripe-como-DB) a un backend real**

(p. ej. Supabase/Postgres + capa de auth/autorización). En síntesis: **funcional para su MVP, pero inmaduro

en arquitectura (escalabilidad y mantenibilidad)**; el siguiente salto del producto exige esa reestructuración,

no más parches sobre Stripe.

_— Análisis generado por Claude (IA). Sincero e independiente; basado en datos reales de Jira/GitHub y en la lectura del código del proyecto._

---

_Fuentes: Jira épica SD-1170 (111 tickets) y GitHub swissbull-group/predatoralgo (89 PRs, 422 commits),

extraídos en vivo el 29 jun 2026, más la lectura del código local del repositorio. Informe por equipo (no por

persona). Nada inventado._