Tavika
Una plataforma para centralizar oportunidades laborales en escuelas privadas y simplificar el envío de postulaciones docentes.
CLIENTE
Proyecto propio
ROL
Founder · Product Designer
UX/UI
ESTADO
TIPO
Product Design · SaaS
ENLACE
tavika / sitio web
02 · EL PROBLEMA
El problema no era encontrar trabajo. Era encontrar dónde postularse.
Trabajé durante años como docente y todavía tengo muchos amigos y colegas que trabajan en educación. Conozco bastante bien cómo funciona la búsqueda laboral en este ámbito.
Cuando volví a pensar en ese mundo, apareció un problema bastante concreto: encontrar colegios privados no era especialmente difícil. Lo difícil era encontrar sus datos de contacto y convertir esa información dispersa en una lista útil para postularse.
Un docente puede pasar horas buscando colegios, entrando a sitios, revisando redes, buscando emails y preparando postulaciones una por una.
El problema que vi fue, sobre todo, tiempo perdido.
La fricción estaba en la dispersión de los datos.
03 · CONSTRUCCIÓN
Primero construí la función.
Al principio Tavika ni siquiera era una plataforma. Era un programa para mí.
Para que Tavika pudiera hacer su trabajo necesitaba algo más que una lista de colegios. Necesitaba una base de datos suficientemente confiable como para que los contactos realmente pudieran utilizarse.
El padrón oficial era el punto de partida, pero no podía usarlo directamente. Había miles de colegios sin email, y muchos de los que estaban, rebotaban.
Construí "El Cazador de Emails", un scraper que busca los colegios rebotados en directorios confiables para extraer sus verdaderos contactos y sanar la base de datos automáticamente.
El problema dejó de ser conseguir una lista de colegios. El problema era mantenerla utilizable.
04 · LA PRUEBA
Funcionó. Era bastante fea.
Con la idea bastante clara y usando vibe coding, pude construir una primera versión muy rápido. Tenía una base de datos mucho más chica y una interfaz muy rudimentaria. Parecía software de los años 90, pero podía hacer lo que necesitaba. Podía escribir el asunto y el cuerpo del mail, seleccionar colegios y hacer el envío. Eso era suficiente para comprobar que la idea podía funcionar.
01 · Primer prototipo funcional
02 · TAVIKA ACTUAL
"El salto importante no fue visual. Fue conceptual: una herramienta que originalmente había construido para mí empezó a convertirse en un producto."
05 · ESTRATEGIA
Esta vez decidí no diseñar primero.
Después de trabajar en Tattoo Empleo, sabía que podía pasar muchísimo tiempo en Figma antes de tener algo funcionando. Esta vez quise probar otra cosa.
Desde el primer día decidí no hacer el proceso habitual de diseñar todas las pantallas antes de construirlas. Quería aprender haciendo.
Mi hipótesis era bastante simple: un producto imperfecto pero funcionando podía enseñarme más que un mockup perfecto que todavía no había enfrentado ninguna restricción real.
No significa que haya dejado de diseñar. Diseñaba constantemente, pero el producto funcionando pasó a ser mi principal herramienta de validación.
También acepté perder cierto control sobre la dirección de arte. La UI inicial fue generada a partir de referencias y llevada directamente a código. Algunos resultados son más genéricos de lo que me gustaría. Por ahora lo acepto como parte del experimento.
06 · RESTRICCIONES REALES
El problema apareció cuando intenté hacerlo de verdad.
Mi primera solución tenía bastante sentido: si el docente iba a enviar una postulación, lo ideal era que el correo saliera directamente desde su propia cuenta de Gmail. Eso era lo que había hecho en la primera versión y parecía la opción más efectiva.
El problema apareció cuando intenté convertir esa solución personal en una plataforma para otras personas.
Para hacerlo, necesitaba permisos de Google mucho más sensibles. Cuando probé el flujo desde otras cuentas aparecieron las advertencias de seguridad de Google sobre una aplicación no verificada.
En ese momento entendí que podía construir la funcionalidad, pero que nadie razonablemente iba a querer utilizarla.
Había consultado varias veces a la IA sobre la viabilidad de esta solución y había tomado sus respuestas como una confirmación. Fue un error. La funcionalidad estaba desarrollada antes de descubrir el problema real.
La nueva arquitectura:
07 · DECISIONES DE ALCANCE
No todo lo que se puede construir tiene que entrar en el MVP.
A medida que el producto crecía aparecían nuevas posibilidades. Muchas eran buenas ideas. No todas resolvían el problema principal. Cada funcionalidad tiene que justificar su existencia.
Envíos ilimitados
Cada envío tiene un costo y también afecta la reputación del dominio. En lugar de ofrecer envíos ilimitados, decidí trabajar con créditos y devolverlos cuando un correo rebota de manera definitiva.
Generar el contenido con IA
La automatización tiene sentido para encontrar colegios y distribuir postulaciones. No estoy convencido de que tenga sentido automatizar aquello que debería hacer personal una postulación: el contenido.
Seguimiento de apertura y clics
Podría mostrarle al docente si un colegio abrió su correo, pero prioricé la entrega real antes que una métrica atractiva que pudiera perjudicarla.
08 · ITERACIÓN
El producto empezó a enseñarme cosas que yo todavía no sabía.
Una de las cosas que más me interesaba comprobar con este experimento era si podía usar el producto funcionando como herramienta de diseño. La experiencia me mostró que sí.
01 · REDACTOR BÁSICO
02 · PERSONALIZACIÓN
03 · DASHBOARD DE ESTADOS
No trabajé en una gran versión, después otra gran versión y después otra. Fui haciendo microcorrecciones. Probaba. Veía qué funcionaba. Corregía. Guardaba una versión. Y volvía a probar. Entre esas etapas hubo muchas correcciones pequeñas. Algunas aparecieron simplemente porque una interfaz que parecía correcta en mi cabeza no funcionaba igual cuando realmente tenía que usarla.
09 · HERRAMIENTAS
La IA construyó mucho.
Las decisiones siguieron siendo mías.
Trabajé principalmente con Gemini, Stitch y Antigravity. Gemini me ayudó a estructurar ideas, investigar alternativas y comparar servicios. Stitch fue una herramienta para generar una primera dirección visual. Antigravity fue el constructor principal.
Pero delegar la construcción no significa delegar las decisiones. La mayor parte de las decisiones sobre qué construir, qué descartar y qué camino tomar fueron mías.
La IA me permitió construir cosas que probablemente no habría podido construir solo, pero también me hizo perder tiempo. El episodio de Gmail fue un buen ejemplo. La IA me ayudó a avanzar muy rápido en una dirección que después tuve que abandonar. Eso también es parte del aprendizaje.
10 · ESTADO
Todavía no lo considero un MVP terminado.
Una herramienta que funciona enseña más que una pantalla perfecta.
Tavika me sirvió para comprobar que puedo trabajar de otra manera. No creo que este proceso sea mejor que diseñar previamente. Creo que depende del proyecto.
Para un producto personal, de bajo riesgo, con poco presupuesto y donde la velocidad sea importante, volvería a hacerlo. Para productos que manejan información sensible, ecommerce complejos o proyectos donde la seguridad y la consistencia visual sean críticas, no.
Lo que sí me llevo es otra forma de pensar el proceso. A veces necesito diseñar antes de construir. Y a veces necesito construir para saber qué tengo que diseñar.
Nada enseña mejor sobre un producto que la respuesta de sus usuarios.
Hecho es mejor que perfecto.
TAVIKA
Founder
Product Designer
UX/UI
Estado: En desarrollo
Tecnologías
- Next.js
- React
- FastAPI
- PostgreSQL
- Mercado Pago
- Resend
Herramientas
- Gemini
- Stitch
- Antigravity