El problema y su origen
La idea de Spooki no nació frente a una pizarra blanca, sino en el instituto, durante las noches entre amigos. Cada vez volvía el mismo tiempo muerto: buscábamos qué ver, abríamos tres catálogos, leíamos sinopsis y las ganas se desvanecían incluso antes de los títulos de crédito. Sobre todo, la pregunta que realmente nos hacíamos nunca era aquella a la que respondían las plataformas. No queríamos saber solamente qué película de terror ver, sino cuál da verdaderamente miedo y qué tipo de miedo provoca. Ese matiz lo cambia todo. Una nota sobre diez no dice si una película da miedo, ni cómo. Eso es lo que Spooki tenía que saber decir.
La intuición se precisó en el metro y luego se transformó en un pliego de condiciones mental mucho antes de la primera línea de código. En aquella época, mi bagaje técnico era escaso: algo de JavaScript adquirido con bots de Discord y scripts de automatización, y algo de HTML. Una aplicación móvil completa, con un backend, una base de datos y una distribución en las tiendas, parecía claramente fuera de mi alcance. Me enfrenté a ello precisamente porque era difícil. No era ni un proyecto escolar ni un encargo, sino un terreno que elegía por su capacidad de hacerme progresar.
No hubo método. Fui aprendiendo la parte técnica sobre la marcha, cuando la necesitaba. La interfaz siempre me importó tanto como la fluidez del desplazamiento o la calidad del renderizado.
La apuesta y la comunidad
La visión inicial iba más allá de la sola aplicación. Imaginaba una unión entre una herramienta de descubrimiento y un Cine-Club, una comunidad de fans del terror que se recomiendan películas entre ellos. El ángulo comunitario no era un añadido tardío, estructuraba el proyecto desde el origen: el valor no venía solamente de un algoritmo, sino también de personas que comparten el mismo gusto y se confían mutuamente para señalar lo que da realmente miedo.
Para financiar a la vez el desarrollo y el Cine-Club, lancé una campaña Ulule, cerrada el 11 de diciembre de 2023. El resultado: 474 euros recaudados sobre un objetivo de 3 000 euros, con 23 contribuciones. La campaña, por tanto, no se financió y no se percibió ningún fondo. Las pantallas presentadas a los contribuidores correspondían al MVP React Native de la época, lo que hacía concreta la promesa, sin bastar para convencer a la escala deseada.
Mi respuesta a este fracaso definió la continuación del proyecto: construir y entregar Spooki de todos modos, en solitario y en autofinanciación, hasta la publicación en las dos tiendas. Esta restricción de medios impuso decisiones sobrias y pocas dependencias de pago, una disciplina que orientó duraderamente la arquitectura. El ángulo comunitario, por su parte, no desapareció: sobrevivió en el producto en forma de la recomendación mediante una puntuación de miedo alimentada por la comunidad.
El giro de React Native hacia Flutter
Empecé en React Native, lógico para un perfil JavaScript, y pronto tuve un primer MVP que funcionaba. Sirvió para validar el concepto: el recorrido de descubrimiento se sostenía, y el problema merecía una aplicación de verdad.
Soy perfeccionista, y quiero una aplicación tan fluida como una nativa. Detecto los microtirones, las transiciones que se enganchan, las listas que no se desplazan perfectamente, y esos detalles son los que hacen que uno conserve una aplicación o la borre. En Android, en uso real, el desplazamiento y las animaciones no estaban a ese nivel. Entre iOS y Android, era como el día y la noche. Seguramente me faltaba experiencia para optimizar bien, pero conseguir un resultado fluido en Android con React Native seguía siendo muy difícil.
Tomé, pues, una decisión costosa a corto plazo y rentable a largo plazo: reescribir la totalidad del frontend en Flutter, cuyo motor dibuja él mismo la interfaz, lo que ofrece un control al píxel y una homogeneidad entre iOS y Android. La decisión era explícita: aceptar una curva de aprendizaje real y la pérdida del MVP existente, a cambio de un techo de calidad mucho más alto y una base de código única, mantenible por una sola persona. En el mismo periodo, adopté TypeScript en el lado del backend, para llevar la misma exigencia de rigor del cliente hasta el servidor.
La arquitectura full-stack
Toda la cadena la sostiene una sola persona, desde el cliente móvil hasta la infraestructura. El frontend está escrito en Flutter y Dart. El backend se apoya en Node.js, TypeScript y Express, con Prisma como ORM por encima de una base MySQL.
En el lado de la infraestructura, el servicio corre bajo Docker para garantizar la reproducibilidad entre los entornos, Nginx asume el papel de proxy inverso y Cloudflare se sitúa en el frontal. La aplicación integra además numerosas APIs externas, lo que exigió un cuidado particular en la resiliencia de las llamadas y la coherencia de los datos agregados. El conjunto permanece voluntariamente clásico y dominable por una sola persona, lo que aquí es un objetivo de ingeniería y no una confesión de simplicidad.
Industrialización y entrega continua
La entrega está automatizada, lo que rara vez es el caso en un proyecto personal y constituye sin embargo un multiplicador de velocidad. GitHub Actions publica automáticamente las betas internas en TestFlight para iOS y en el Play Store para Android. En concreto, un cambio validado desencadena una distribución hacia los testadores sin intervención manual, lo que suprime una fuente clásica de errores y de lentitud, y permite probar una corrección en el dispositivo real acto seguido.
Más allá de la mecánica de despliegue, mantuve una organización Git profesional, incluso trabajando en solitario. Utilizo issues de GitHub para trazar el trabajo y pull requests para integrar los cambios, cuando un simple push a la rama principal habría bastado. Esta elección es deliberada: impone una trazabilidad, obliga a formular la intención de cada cambio y crea un historial legible que puedo releer, lo cual es valioso cuando se retoma un proyecto tras una pausa.
Esta disciplina reproduce voluntariamente las condiciones de un equipo, para que el paso a un contexto colaborativo no exija ningún cambio de hábito. Es una prueba concreta de la manera en que trabajo, más que del producto en sí mismo.
Instrumentación y medición del producto
Instrumenté Spooki de extremo a extremo y me construí un panel de analítica propio, bautizado SPOOKI Analytics V4, en Grafana. Se alimenta de mis propias métricas de backend, expuestas desde Node.js y MySQL, con una observabilidad garantizada por Prometheus y Loki. El objetivo no era coleccionar curvas, sino poder responder a preguntas precisas sobre el producto: quién lo usa, cómo, y si la funcionalidad central responde bien a la necesidad de origen. Mido así la adquisición (registros por día y acumulados), el compromiso, la retención, la distribución por plataforma, por idioma y por versión de aplicación, y sobre todo las preferencias de intensidad de miedo.
En septiembre de 2026, el panel cuenta 1.397 usuarios, 107.075 swipes, 4.639 películas vistas, 3.026 notas y 19.898 películas activas en el catálogo. Las inscripciones se aceleran: una treintena al mes a finales de 2025, 123 en julio de 2026 y 130 en agosto. La audiencia es francófona e internacional, mayoritariamente en Francia, pero también en Costa de Marfil, Camerún, Canadá, Gabón, Congo, Estados Unidos y Reino Unido.
El punto más interesante cierra el bucle abierto en el instituto: la distribución de las preferencias muestra que alrededor del 57% de los usuarios buscan la intensidad de miedo más elevada. El dato valida, pues, la necesidad que fundó el proyecto. Quiero ser honesto sobre el alcance de todo esto: el valor que reivindico no es el tamaño de la audiencia, todavía modesto, sino la capacidad de medir y la cultura data-driven que de ello se deriva. El producto es joven y llevado en solitario, no sobrevendo la tracción y no destaco métricas frágiles.
Los retos de ingeniería
El primer desafío fue aprender Flutter. Me llevó varios meses sentirme cómodo: la forma de construir una interfaz no tiene nada que ver con lo que conocía de JavaScript.
La autenticación constituyó otra pieza importante. Nunca había implementado ninguna, y fue un verdadero aprendizaje de backend, con sus cuestiones de seguridad, de gestión de las sesiones y de los casos límite. En el mismo registro, diseñar un esquema de base de datos sólido y evolutivo exigió pensar más allá de la necesidad inmediata, para no encontrarme bloqueado por mis propias decisiones unos meses más tarde. La robustez y la estabilidad fueron un hilo conductor permanente: gestionar los casos de error en todas partes, y pensar al mismo tiempo en los usuarios, en los administradores, en la evolutividad futura y en los diferentes estados del frontend.
Lo que hace el ejercicio sostenible es que disfruto tanto del backend como del frontend. Lo que me motiva no es una capa en particular, sino el resultado: buscar, comprender, y luego lograr. Esta motivación es lo que permite aguantar la distancia cuando hay que, en solitario, pensar en todo a la vez.
Resultado y pruebas
Spooki fue diseñado y entregado en solitario, desde el prototipo hasta la publicación en las dos tiendas. Es el punto que retengo en primer lugar, porque resume la naturaleza del proyecto: llegar hasta el final, en solitario, de una cadena completa que va desde la idea hasta el cliente móvil instalado. La aplicación muestra una nota de 5,0 sobre 10 en el App Store, sobre 10 reseñas, y precisé voluntariamente el volumen para no dar a creer en una representatividad que no tiene.
En septiembre de 2026, el backend cuenta 1.397 usuarios, una cifra leída en mi propio panel. La marca está registrada en el INPI y la actividad la lleva una microempresa. Spooki también apareció en Télématin, en France 2, en 2024.
Lo que este proyecto muestra, más que sus cifras, es que puedo diseñar, entregar y mantener solo una aplicación en producción, incluso sin financiación.