Cuándo cerrar un proyecto: distinguir entre una web, un servicio y un producto

Voy a cerrar Qué Veo Ahora. La decisión tiene menos que ver con un problema técnico o con el coste de mantener la aplicación que con una distinción que me ha resultado útil al evaluar proyectos propios: una web, un servicio y un producto no son lo mismo, aunque a veces usemos esas palabras como si fueran intercambiables.

El proyecto nació para resolver una decisión cotidiana: ayudar a elegir una película o serie entre los catálogos de distintas plataformas. Al principio la pregunta era puramente de construcción: cómo organizar la aplicación, conectar las fuentes de datos y convertir una idea en algo que se pudiera publicar. Después apareció una pregunta más importante: si alguien que no me conoce llegaría a utilizarlo y encontraría valor en ello.

La respuesta fue sí, al menos en parte. Qué Veo Ahora ha tenido personas usuarias reales que han buscado contenido, han utilizado sus funcionalidades y, en algunos casos, han vuelto. Eso no convierte automáticamente el proyecto en un negocio, pero tampoco es un detalle menor. Supone haber cruzado la frontera entre construir una demostración para uno mismo y ofrecer algo que participa, aunque sea modestamente, en la rutina de otras personas.

Una web puede estar bien hecha y no necesitar más recorrido

Una web es algo que se ha construido y publicado. Puede tener una interfaz cuidada, una arquitectura razonable y resolver un problema reconocible. También puede ser un proyecto técnicamente satisfactorio. Nada de eso implica, por sí solo, que vaya a tener usuarios o que deba convertirse en una actividad sostenida.

Esta primera etapa ya tiene valor. Publicar obliga a tomar decisiones reales que una prueba local permite aplazar: rendimiento, errores, accesibilidad, analítica, despliegue, mantenimiento de dependencias y claridad del mensaje con el que se presenta el proyecto. En mi caso, el desarrollo de Qué Veo Ahora también sirvió para explorar la separación entre una aplicación de recomendación y una plataforma editorial, una arquitectura que detallé en el artículo sobre el ecosistema de recomendación cinematográfica.

Sin embargo, una web no adquiere una obligación de crecer por el hecho de estar publicada. Puede cumplir perfectamente su función como experimento técnico, portfolio o vehículo para aprender una tecnología. El error aparece cuando se le atribuyen expectativas de producto que todavía no ha demostrado poder sostener.

El salto a servicio ocurre cuando alguien obtiene valor

Un servicio empieza cuando otras personas llegan, lo usan y resuelven con él una necesidad concreta. No hace falta tener miles de visitas ni una comunidad activa. Basta con que el uso no dependa únicamente de quien lo construyó y con que la propuesta sirva para algo fuera del entorno de desarrollo.

Ese uso introduce un tipo de responsabilidad distinto. Una integración que deja de responder, un catálogo desactualizado o una pantalla confusa ya no son solo incidencias de un proyecto propio: afectan a alguien que esperaba obtener un resultado. También cambia la forma de medir el avance. Terminar una funcionalidad continúa siendo importante, pero empiezan a importar más las señales de uso: qué busca la gente, dónde abandona, qué parte vuelve a utilizar y qué problema sigue sin estar resuelto.

Qué Veo Ahora llegó a ese punto. Su uso real confirmó que el problema de decidir qué ver existe y que una aplicación puede facilitar esa decisión. Pero esa validación no responde todas las preguntas necesarias para seguir invirtiendo. Que una persona use un servicio no significa todavía que el servicio tenga una propuesta suficientemente diferenciada, una recurrencia sostenible o un camino razonable hacia un modelo de negocio.

Un producto exige una propuesta que compita por recursos

Para mí, un proyecto empieza a ser producto cuando genera suficiente valor como para que alguien pudiera estar dispuesto a pagar por él. No es necesario estar cobrando ya; tampoco conviene tratar el pago como la única medida de valor. La cuestión es si existe una propuesta clara que pueda justificar una relación duradera entre quien la usa y quien la mantiene.

Esa fase exige trabajo que no se resuelve añadiendo otra funcionalidad. Hay que entender la recurrencia, encontrar un posicionamiento que no sea fácilmente sustituible, hablar con usuarios, distribuir el producto y probar hipótesis de adquisición o de negocio. Son tareas legítimas de construcción de producto, pero requieren tiempo, atención y una disposición explícita a aprender de resultados que pueden contradecir la idea inicial.

En un mercado con muchas alternativas para descubrir películas y series, ese trabajo tendría que ser el centro de la siguiente etapa de Qué Veo Ahora. Mantener la aplicación no sería difícil desde el punto de vista económico, pero convertirla en producto pediría una inversión continuada en diferenciación y distribución. No quiero hacer esa inversión ahora, y asumirlo con claridad es más útil que mantener el proyecto en una inercia indefinida.

El coste de oportunidad también forma parte del mantenimiento

Cuando se habla de cerrar una aplicación, suele pensarse en servidores, dominios, APIs o suscripciones. Esas cifras importan, pero en proyectos pequeños a menudo no son el coste decisivo. El recurso escaso es el tiempo: investigar una incidencia, revisar una dependencia, responder a un cambio de una API externa, mejorar una funcionalidad o decidir qué experimento merece atención la semana siguiente.

También existe un coste menos visible en el contexto mental. Un proyecto abierto conserva tareas pendientes aunque no haya una incidencia urgente: ideas que parecen prometedoras, mejoras que sería agradable terminar y preguntas que nadie ha respondido. Tener demasiados frentes activos hace más difícil dedicar energía suficiente a los que sí pueden avanzar hacia el objetivo actual.

Cerrar Qué Veo Ahora libera ese espacio para otros proyectos con más posibilidades de recorrer el ciclo completo. No presupone que esos proyectos vayan a convertirse en empresas. Significa que, si decido intentar que lo hagan, podré dedicarles la atención que esa apuesta requiere en lugar de repartirla entre mantenimientos que ya no son prioritarios.

Cerrar no borra lo que el proyecto ha aportado

Durante mucho tiempo asocié el cierre de un proyecto con haber fallado. Esa interpretación reduce demasiado lo que puede aportar construir algo desde cero. Qué Veo Ahora ha servido para experimentar con Vue, APIs, Supabase, analítica, SEO, automatización, IA y decisiones de arquitectura. Más importante aún, permitió comprobar qué ocurre cuando hay usuarios reales delante de una aplicación, con sus necesidades y comportamientos reales.

El aprendizaje no queda invalidado porque no se persiga una etapa posterior. Al contrario: la decisión de no convertir un servicio en producto puede estar respaldada por la información que el propio proyecto ha proporcionado. Mantenerlo solo para evitar la sensación de abandono convertiría el tiempo ya invertido en una razón para seguir invirtiendo, cuando debería ser evidencia para decidir mejor.

Antes de cerrar un proyecto, ayuda revisar cuatro aspectos de forma honesta:

1. Qué problema resolvió y para quién llegó a resolverlo.
2. Qué señales de uso, recurrencia o diferenciación existen realmente.
3. Qué trabajo concreto sería necesario para el siguiente nivel, más allá de programar funcionalidades.
4. Qué oportunidad se deja de atender al conservarlo activo.

Estas preguntas no producen una fórmula universal. Hay proyectos que merece la pena mantener aunque no tengan intención comercial, y otros que necesitan más tiempo antes de poder evaluarse. Su utilidad está en sustituir una decisión por inercia por una decisión consciente sobre la etapa en la que se encuentra el proyecto.

Saber en qué etapa estás también es construir producto

No todos los proyectos tienen que convertirse en empresas. A veces construyes una web; otras veces consigues ofrecer un pequeño servicio que aporta valor a personas reales. En menos ocasiones aparece un producto con una propuesta lo bastante fuerte como para sostener el esfuerzo de hacerlo crecer.

Reconocer esa diferencia evita dos trampas. La primera es despreciar un proyecto que ha funcionado porque no alcanzó una escala que nunca fue realista. La segunda es seguir manteniéndolo como si ya fuera un producto cuando las señales y la prioridad personal indican otra cosa. Cerrar Qué Veo Ahora responde a esa segunda lección: ha cumplido una función valiosa, pero su siguiente etapa requiere una apuesta que hoy prefiero hacer en otro lugar.