MANIJAPP
Descubrir eventos no es el problema. El problema es saber cuáles valen la pena.
MVP independiente para discovery de eventos alternativos en CABA y La Plata, con validación comunitaria visible y geolocalización.
TL;DR
01. Problema
Los eventos independientes en CABA y La Plata no tienen una fuente centralizada confiable. El discovery ocurre de forma fragmentada: Instagram, WhatsApp, boca a boca.
02. Insight
El problema no es encontrar más eventos, sino identificar cuáles valen la pena. La fricción está en la curaduría y la confianza, no en la disponibilidad.
03. Solución
Plataforma de discovery con validación comunitaria visible, geolocalización y foco en eventos fuera del circuito tradicional.
04. Resultados
Señales tempranas de retención sostenidas en múltiples días, comportamiento real en todo el core loop (exploración, validación, compartir, publicación) y primeros casos de supply sin pedido explícito.
El problema
Los fines de semana en La Plata y CABA, la pregunta "¿qué hay para hacer?" se resuelve mal. Eventbrite tiene los eventos masivos. CulturaBA tiene la agenda oficial. Instagram tiene todo mezclado.
El show underground en un espacio alternativo, la fiesta que solo circula por WhatsApp, el evento en un bar nuevo sin visibilidad — no aparecen en ninguna plataforma.
La hipótesis inicial era simple: centralizar eventos cerca tuyo. Eso cambió en el primer ciclo de discovery.
El insight que lo redefine
Con el prototipo en producción, la validación arrancó el mismo día. Cinco sesiones de guerrilla research. Tres de ellos llegaron a la misma conclusión sin que nadie se las sugiriera: el diferencial no son todos los eventos, son los que no están en ningún otro lado.
No querían otro Eventbrite. Querían acceso a lo que existe cerca pero está invisible, verificado, que hoy solo circula por WhatsApp.
Eso redefine el producto. No es un problema de volumen. Es un problema de curaduría y confianza.
Cómo se construyó: metodología antes que stack
Construir antes que research
El primer trade-off fue explícito: esperar a tener mayor claridad conceptual o salir a producción con un sistema incompleto.
La decisión fue lanzar. No por velocidad en sí misma, sino porque una interfaz genera un tipo de señal que ningún research previo puede reemplazar. Cinco conversaciones reales en 48 horas aportan más que cualquier encuesta por email.
El costo de saltear la especificación
Sin un brief previo, la IA tomó miles de micro-decisiones que nunca pedí: copy que no comunicaba, jerarquía visual sin lógica, estados indefinidos. El costo no era solo eficiencia — era metodología. Si la UX tiene ruido de defaults del generador, los testers reaccionan a decisiones que nunca tomaste. Los datos quedan contaminados antes de empezar.
Spec-Driven Development
La corrección no fue técnica, sino de proceso. Sin una especificación clara, la IA completa los vacíos y define el producto en lugar del diseñador.
El paso a un enfoque spec-driven introduce una diferencia clave: permite dirigir al agente en lugar de dejar que el agente dirija. Sin esa capa de control, la velocidad de ejecución amplifica el error y aumenta la superficie de corrección. Ese costo temprano no desaparece; se transforma en deuda técnica.
Del Concierge al backend
Contexto
Un solo criterio rigió cada decisión técnica del proyecto: no construir infraestructura antes de tener evidencia que la justifique.
El formulario de publicación existía desde el día uno. Los eventos que subían los organizadores llegaban a un Google Sheet y la publicación la hacía yo manualmente — era el flujo del lado oferta.
Los eventos que yo cargaba manualmente (flyers de Instagram, contactos directos) pasaban por asistencia de IA para extraer datos, pero con reglas documentadas, tabla de venues fijos y criterios de geocodificación para validar cada campo de manera sistematizada. La IA aceleraba la extracción pero cada dato requería revisión antes de publicar.
El organizador percibía que el flujo funcionaba.
Trigger y decisión
La misma lógica definió cuándo sumar Supabase. Durante las primeras semanas, los contadores de pulgares eran valores simulados — suficientes para validar si alguien tocaba los botones, no para medir comportamiento real. El trigger fue concreto: aparecieron eventos de organizadores reales. En ese momento los datos simulados dejaron de ser neutrales. Los números afectaban la credibilidad. Necesitaba persistencia real.
Aprendizaje
Empecé sin backend para no escalar infraestructura sin validación. El problema: el costo de mantener todo manual fue mayor que el costo de construir persistencia temprana. La regla metodológica era correcta, pero el trade-off cambió — el costo tiende a cero.
La dependencia era triple: el interés dependía de la curaduría, la tracción dependía de la distribución, y ambas dependían de mi energía. Eso es sostenible para validar. No es sostenible en el tiempo.
Benchmarking y definición del diferencial
Jodify
El benchmark competitivo más útil tampoco vino de research — vino de cargar eventos. Jodify apareció en redes mientras operaba el catálogo. El análisis fue desde adentro: contacto directo posando como productora. Jodify opera como canal B2B con gatekeeping humano — llamada de onboarding, 10% de comisión, posicionamiento pago.
El contraste con Manijapp es estructural: Jodify valida antes de publicar, Manijapp valida después vía comunidad. Son apuestas distintas sobre cómo se construye confianza.
El naming: cuando la evidencia no es conclusiva
Después del primer ciclo aparecieron dos señales contradictorias sobre el nombre. Una persona con contexto de marketing lo validó. Otra con contexto de producto señaló que "manija" puede evocar segunda marca — nombres que priorizan lo fonético sobre lo aspiracional — y que eso podía bajarle el precio al producto.
La decisión fue no cambiar. No porque una señal pesara más que la otra, sino porque no hay dato de que el nombre frene el uso o genere rechazo en el segmento target. Una opinión bien fundamentada no es evidencia de comportamiento. El trigger para revisarlo está definido: si el reposicionamiento hacia un segmento con mayor capacidad de pago avanza, el naming entra a revisión como parte del sistema de identidad. No antes.
Validación: cuatro ciclos, decisiones encadenadas
| Métrica | Ciclo 2 | Ciclo 3 | Ciclo 4 |
|---|---|---|---|
| Usuarios activos (GA4) | 89 | 32 | 35 |
| Pages / sesión | 2.45 | 4.02 | 2.91 |
| Scroll depth | 63.7% | 78.4% | 65.35% |
| Active time | 57s | 1m 30s | 1m 0s |
| Retención 7 días (cohorte) | 7.9% (7/89) | ~7.1% (2/28) | 4% (1/25) |
| Usuarios returning (GA4) | 2 | 3 | 10 |
| validation_tap | 13% | 6.25% | 14.3% |
| event_shared | 5.2% | 6.25% | 8.6% |
| event_submitted | 1 | 2 | 0 |
Ciclo 1 · Primera señal, metodología contaminada
17 contactos activados, 5 sesiones reales. Un usuario regresó tres veces sin intervención, lo que indicaba interés. Sin embargo, las variables del sistema cambiaban mientras se medía, lo que invalidaba la señal.
La decisión fue aislar condiciones antes de continuar.
Este ciclo expuso una inconsistencia: la validación comunitaria (diferencial clave) no era evidente en la interfaz. Remover los indicadores mejoró lo visual, pero rompió la estrategia. El brief funcionó como herramienta de corrección.
Ciclo 2 · Señales tempranas confirmadas
Con variables controladas y un outreach rediseñado —más contextual y segmentado— comenzaron a aparecer patrones estables.
Se registraron entre 4 y 6 returning users diarios durante varios días sin contacto directo, superando el umbral definido. Además, apareció un evento publicado por un organizador que llegó a través de una historia de Instagram, sin contacto directo. Eso indicaba que la distribución pasiva —historias, referencias de terceros— generaba supply sin intervención explícita.
Ambas señales indicaban que el sistema empezaba a sostenerse por sí mismo.
Ciclo 3 · Experimento de seeding y límite de red
El tercer ciclo introdujo un experimento de seeding. La interacción con validación fue mayor en ese contexto, pero la calidad de sesión mejoró cuando se redujo la intervención.
La retención se mantuvo estable, incluso con menor volumen y una red de distribución más distante. Esto sugiere que el producto no pierde valor; lo que se degrada es la eficiencia del canal.
El aprendizaje es claro: el outreach directo tiene retorno decreciente. Escalar no implica insistir en el mismo canal, sino cambiarlo. El siguiente paso es presencia en el ecosistema, no mayor volumen de mensajes.
Ciclo 4 · Retención sin intervención
El cuarto ciclo no tuvo distribución, stories ni eventos nuevos. Sin ningún estímulo, 10 usuarios de ciclos anteriores volvieron solos. El engagement por usuario fue el más alto de toda la serie: validation_tap al 14.3%, event_shared al 8.6%.
La ausencia de intervención es lo que hace este ciclo el más limpio. Cualquier métrica de ciclos anteriores podía explicarse por el efecto novedad del outreach. Acá no hay outreach. Lo que se mide es el producto solo.
La conclusión es concreta: el cuello de botella no es el producto ni la retención. Es la adquisición de usuarios con intención real. El outreach directo trae curiosidad, no hábito.
Supply: no solo fricción, también incentivo
La hipótesis inicial era que tener red directa en la escena independiente resolvía el lado oferta. Años como DJ daban acceso a promotores y organizadores — suficiente para arrancar el supply sin depender de que desconocidos publicaran solos.
La señal existe pero no es suficiente. Tres submissions en dos ciclos confirman que la hipótesis de red directa genera alguna tracción, pero está lejos de sostener un catálogo de 40 eventos por fin de semana. El acceso a la escena reduce la fricción del arranque; no reemplaza el incentivo estructural que hace que un organizador publique solo.
La segunda hipótesis fue fricción. Eso también se rompe con dos señales convergentes. En research, una entrevistada lo dijo directo: "subir eventos no es hábito, es una tarea más." El rediseño del formulario reduce fricción para quien ya tiene intención, pero no genera esa intención.
La conclusión es estructural: sin audiencia, no hay incentivo para publicar.
Esto define la secuencia del producto. Primero se construye demanda. Luego se escala el supply. Sin una audiencia visible, no existe una propuesta de valor real para organizadores o venues.
Cuando esa masa crítica exista, la conversación cambia: deja de ser pedirle un favor a un organizador y pasa a ser ofrecerle acceso a una audiencia real. El modelo de negocio no se posterga; se secuencia.
Qué sigue
El ciclo 4 confirmó que el cuello de botella es el canal, no el producto. La retención existe sin estímulo. El siguiente paso es adquisición de usuarios con intención real — gente que no me conoce y llega igual.
Los avances pendientes tienen triggers, no fechas.
La decisión más importante no es qué construir.
Es qué medir, con qué criterio, y cuándo la señal es suficiente para actuar.
Manijapp es un proyecto en curso — manijapp.vercel.app
