TV Time

TV Time era una aplicación de software del sector del software y SaaS, dedicada al seguimiento de series y películas. Según ADSLZone, su creador anunció el cierre de la aplicación y, al mismo tiempo, el lanzamiento de una nueva app.

La ubicación de la empresa y su razón social completa no constan en los datos disponibles.

No consta en los datos disponibles la fecha de fundación de TV Time ni el nombre de su fundador o fundadores. La fuente periodística consultada (ADSLZone) se refiere a "su creador" en singular, pero no especifica su identidad.

TV Time era una aplicación de seguimiento de series y películas. Según la información disponible, el uso principal era que los usuarios pudieran hacer el seguimiento de lo que veían. No constan en los datos disponibles detalles sobre el modelo de negocio, la base de usuarios o los mercados en los que operaba.

No consta en los datos disponibles información sobre la evolución de la empresa, sus ingresos, su base de usuarios o sus años de crecimiento.

La causa del cierre no consta en los datos disponibles. La única información verificada es que, según ADSLZone (14 de julio de 2026), TV Time cerraba al día siguiente, el 15 de julio de 2026, y que su creador lanzaba una nueva aplicación el mismo mes. La fuente no indica los motivos del cierre.

Según ADSLZone, el creador de TV Time lanzó una nueva aplicación el mismo mes del cierre. No consta en los datos disponibles ninguna otra información sobre la continuidad del producto, su venta o la migración de usuarios.

El creador de TV Time consta en la fuente periodística como la persona que lanzó una nueva aplicación en julio de 2026. Su identidad no consta en los datos disponibles. Para ampliar esta información se podrían consultar el registro mercantil correspondiente, las notas de prensa del lanzamiento de la nueva aplicación y las fuentes periodísticas especializadas en tecnología.

• En aplicaciones de seguimiento de contenido audiovisual, la propiedad de los datos del usuario (historial de visionado, listas) es un activo central: cuando la app cierra, hay que saber si estos datos se pueden exportar o migrar, y la fuente consultada no lo aclara.
• El lanzamiento de una nueva app por el mismo creador el mismo mes del cierre indica que el conocimiento del producto y de la base de usuarios puede sobrevivir al cierre de la sociedad; por ello, en este sector, conviene distinguir entre el cierre de la empresa y la continuidad del producto.
• La falta de datos públicos sobre la causa del cierre en una app de consumo masivo muestra la importancia de documentar las decisiones de cierre (comunicación a usuarios, plazos y gestión de datos) para que sean verificables posteriormente.

La funció central de TV Time era senzilla i encara té sentit: una app on l'usuari marca què veu, en quin episodi va, i rep recordatoris, amb una capa social per veure què fan els altres i comentar capítols. Això avui es pot construir més barat que mai: hi ha APIs de catàleg (TMDB i similars), infraestructura serverless i models de llenguatge per automatitzar fitxes, resums i recomanacions.

La proposta no és clonar TV Time, sinó reconstruir-ne l'essència amb tres decisions diferents: producte més lleuger (mòbil primer, sense funcions que ningú fa servir), monetització des del dia u (subscripció barata o afiliació, no només publicitat) i comunitat curada (grups petits i moderats en lloc d'un feed global difícil de moderar).

Això és una proposta, no una descripció del que TV Time feia: de l'empresa original només sabem que tancava i que el creador en llançava una altra (ADSLZone, 2026-07-14).

El mercat de "trackers" de sèries i pel·lícules és real i persistent: hi ha hagut diverses apps al llarg dels anys, i la necessitat —recordar on et vas quedar, decidir què veure després, compartir-ho— no ha desaparegut. El que ha canviat és el context: el catàleg està fragmentat entre moltes plataformes, la gent acumula subscripcions i rotació, i la descoberta de contingut és un problema més gran que fa deu anys.

Estimació (a validar): un nínxol viable seria la franja d'usuaris "heavy viewers" de 18-40 anys que ja fan servir dues o tres plataformes i volen una eina única. No hi ha dades públiques verificades sobre la mida d'aquest segment per a aquest producte concret; caldria validar-ho amb una enquesta pròpia i amb proves de pagament abans de dimensionar res.

Un senyal d'alerta: el tancament de TV Time suggereix que el model anterior —probablement gratuït amb publicitat i costos d'infraestructura i moderació— no era sostenible. Aquesta és una lectura nostra, no una causa verificada.

Proposta de tres capes, de menor a major compromís:

1. Gratuït amb límit: seguiment il·limitat de sèries, però historial limitat i sense estadístiques avançades.
2. Subscripció individual: rang estimat de 2-4 €/mes o 20-35 €/any (a validar amb tests de preu). Inclou estadístiques, exportació de dades, sense publicitat i sincronització multi-dispositiu.
3. Afiliació i enllaços: quan l'usuari vol veure on està disponible un títol, enllaços d'afiliació a plataformes o botigues. Ingressos variables, estimació conservadora: 0,5-2 € per usuari actiu i any (a validar; depèn molt dels acords).

Evitaria la publicitat programàtica com a base: és la que més fàcilment porta a costos de moderació i a una experiència dolenta. La clau del model és que cada usuari nou tingui un camí clar a ingressos, cosa que el producte original probablement no tenia prou resolta.

Proposta en quatre fases, amb terminis estimats:

• Fase 0 (4-6 setmanes): validació. Enquesta a 200-300 persones del nínxol, entrevistes a 15-20, i una landing amb llista d'espera per mesurar interès real. Cost baix.
• Fase 1 (8-10 setmanes): MVP. Seguiment de sèries, progrés per episodi, recordatoris, catàleg via API externa, i un grup social petit (no feed global). Sense app nativa: web progressiva o app lleugera.
• Fase 2 (3-4 mesos): subscripció i afiliació activades, estadístiques bàsiques, exportació de dades. Primer objectiu: estimació de 500-1.000 usuaris de pagament per validar el preu (a validar).
• Fase 3 (a partir del mes 6): comunitat curada, recomanacions assistides per IA i, si les dades ho justifiquen, apps natives.

El criteri de continuïtat hauria de ser explícit: si al mes 6 no hi ha un percentatge mínim de conversió a pagament (proposta: 3-5% dels usuaris actius, a validar), es replanteja o s'atura.

Totes les xifres són estimacions a validar, no pressupostos tancats:

• Desenvolupament MVP: 15.000-40.000 € si es fa amb un equip petit extern, o 0-10.000 € si el fundador programa i només paga eines. Rang molt ampli perquè depèn totalment de qui ho faci.
• Infraestructura i APIs (any 1): rang de 100-400 €/mes per a un producte petit; puja amb usuaris i amb ús d'IA.
• Disseny i marca: 2.000-6.000 €.
• Màrqueting de llançament: 3.000-10.000 € per a les primeres campanyes i contingut.
• Legal i compliment (RGPD, termes, moderació): 1.500-4.000 €.
• Cost de moderació de comunitat: estimació de 500-1.500 €/mes un cop hi hagi volum.

Total orientatiu per arribar al primer any amb producte viu: rang de 25.000-70.000 €, amb un escenari mínim de 10.000-15.000 € si el fundador assumeix el desenvolupament. Caldrà afegir un coixí de 6 mesos de despeses fixes.

• El risc principal és el mateix que va matar el producte original: un producte gratuït amb costos recurrents i sense conversió a pagament. No sabem la causa verificada del tancament de TV Time, però aquest és el patró habitual del sector i cal dissenyar contra ell des del dia u.
• Competència i substituts: hi ha apps consolidades de seguiment i, sobretot, les mateixes plataformes de streaming milloren les seves eines de descoberta. Cal una raó per triar una app externa.
• Dependència d'APIs de catàleg: si l'API canvia de condicions o de preu, el producte pateix. Cal pla B i cau de dades.
• Moderació i comunitat: un feed social global és car de moderar i pot generar problemes legals i reputacionals. Per això la proposta aposta per grups petits.
• Risc de validació: potser el nínxol no paga. Per això la Fase 0 i el criteri d'aturada són imprescindibles.
• Risc de "creador únic": si depèn d'una sola persona, el tancament sobtat és una possibilitat real — precisament el que va passar aquí.

Les lliçons de l'informe original, aplicades a aquest cas:

1. Un producte gratuït necessita un camí a ingressos des del primer dia. El tancament de TV Time, amb un creador que llança una app nova el mateix mes (ADSLZone, 2026-07-14), suggereix que el problema no era la idea sinó la sostenibilitat. Qui ho refaci ha de començar pel model de negoci, no per les funcions.
2. No inventar el que no se sap. D'aquest cas només tenim una data i un titular; qualsevol reconstrucció ha de tractar les mètriques com a hipòtesis i validar-les amb usuaris reals abans d'invertir.
3. Dissenyar per a la longevitat, no per al creixement. Un equip petit, costos baixos i un nínxol que paga val més que milions d'usuaris gratuïts que no financen res.
4. La comunitat és el valor i el cost alhora. Cal moderar-la des del disseny, amb grups petits i normes clares, no afegir-la després.
5. Qui ho faci ha de tenir un pla de successió o un equip. Un projecte d'una sola persona és fràgil; el tancament sobtat n'és el símptoma.

En resum: la idea té sentit avui, però només si es construeix amb un model de negoci clar, costos continguts i validació honesta abans de gastar.

TV Time va tancar el juliol de 2026, segons ADSLZone [ADSLZone, 2026-07-14], i el seu creador va llançar una app nova el mateix mes. Això deixa milions d'usuaris amb historials de visualització, llistes i estadístiques atrapats en un servei que desapareix. El problema concret és la pèrdua de dades personals de seguiment i la dependència d'un únic proveïdor de catàleg i notificacions.

La solució proposada és un servei de seguiment que tracta l'historial de l'usuari com a dada seva: exportable, importable i no lligada a un proveïdor de catàleg únic. No competeix per tenir el catàleg més gran, sinó per garantir continuïtat i portabilitat.

Backend modular en tres serveis desplegables independentment, sobre una base de dades relacional única:

``` [App mòbil / Web] --HTTPS--> [API Gateway] | +-------------------------+-------------------------+ | | | [Servei d'usuaris] [Servei de seguiment] [Servei de catàleg] | | | +------------[PostgreSQL]--+ | | | [Cua de treballs] [Sincronitzador] | | [Servei de notificacions] [Proveïdors externs] ```

Motius de les decisions:

• PostgreSQL únic en lloc de microserveis amb bases separades: el volum és moderat i les consultes de seguiment creuen usuaris, títols i episodis; un sol esquema amb transaccions simplifica la consistència.
• Servei de catàleg separat perquè la font de dades externa canvia sovint i ha de poder substituir-se sense tocar el nucli de seguiment.
• Cua de treballs per a sincronització i notificacions: desacobla pics de càrrega i permet reintents.
• API Gateway per centralitzar autenticació i límits de taxa.

Taules principals (PostgreSQL):

```sql users(id, email, display_name, locale, created_at, deleted_at) titles(id, external_ref, kind, name, year, metadata_json, updated_at) -- kind: 'series' | 'movie' episodes(id, title_id, season, number, air_date, duration_min) follows(user_id, title_id, status, rating, started_at, finished_at) -- status: 'watching' | 'planned' | 'dropped' | 'completed' watches(user_id, episode_id, watched_at, source) lists(id, user_id, name, is_public) list_items(list_id, title_id, position) exports(id, user_id, status, format, created_at, url) ```

Decisions:

• `titles.external_ref` guarda la referència al proveïdor de catàleg per poder re-sincronitzar; `metadata_json` absorbeix camps variables sense migracions constants.
• `watches` és la font de veritat de l'historial; les estadístiques es calculen a partir d'aquí, no es desen agregades.
• `exports` desa l'estat de les exportacions asíncrones perquè l'usuari pugui descarregar-les quan estiguin llestes.

API REST versionada (`/v1`), autenticació amb JWT i refresc.

• `POST /v1/auth/login`, `POST /v1/auth/refresh`
• `GET /v1/titles?query=`, `GET /v1/titles/{id}`
• `PUT /v1/follows/{title_id}`, `DELETE /v1/follows/{title_id}`
• `POST /v1/watches`, `DELETE /v1/watches/{id}`
• `GET /v1/me/stats`
• `POST /v1/exports` (asíncrona), `GET /v1/exports/{id}`
• `POST /v1/imports` per pujar un fitxer d'historial

Integracions externes:

• Proveïdor de catàleg (per exemple, una API de metadades de sèries): el sincronitzador fa una passada diària i actualitza `titles` i `episodes`. Si el proveïdor desapareix, es pot canviar per un altre mantenint `external_ref` com a àncora.
• Servei de notificacions (push i correu): consumidor de la cua, envia recordatoris d'episodis emesos segons `episodes.air_date` i les sèries seguides.

Motiu: exposar importació i exportació com a API de primera classe és el que fa el producte resistent al tancament d'un proveïdor.

1. Esquema de dades i autenticació: usuaris, títols, episodis, seguiments i visualitzacions. Sense això no hi ha producte.
2. Importació d'historial: acceptar un fitxer CSV/JSON amb títols i episodis vistos. És el ganxo d'adquisició en el moment del tancament d'un competidor.
3. Seguiment bàsic i estadístiques: marcar episodis com a vistos i calcular minuts i capítols.
4. Sincronitzador de catàleg amb un sol proveïdor.
5. Notificacions de nous episodis.
6. Exportació completa de les dades de l'usuari.

Ordre motivat: la importació abans que la sincronització perquè el valor immediat per a l'usuari és recuperar el seu historial, no explorar catàleg nou.

• Volum: un usuari actiu genera poques escriptures al dia; el coll d'ampolla és la lectura d'estadístiques i la sincronització de catàleg. Amb PostgreSQL i índexs adequats n'hi ha prou fins a ordres de magnitud raonables.
• Risc de dependència de catàleg: si el proveïdor canvia el format o desapareix, la sincronització falla. Mitigació: capa d'adaptació per proveïdor i validació d'esquema a l'entrada.
• Risc legal de metadades: les imatges i sinopsis poden tenir restriccions d'ús. Mitigació: desar només referències i metadades mínimes, i mostrar imatges des de la font quan sigui possible.
• Risc de notificacions duplicades: la cua ha de ser idempotent per clau (usuari, episodi, data).
• Risc de privadesa: l'historial és sensible; cal xifrat en repòs i esborrat real en sol·licitud de baixa.

• Proves d'integració sobre l'esquema: importar un fitxer d'historial i verificar que les estadístiques coincideixen amb el nombre d'episodis.
• Prova de resiliència de catàleg: simular la caiguda del proveïdor i comprovar que el servei de seguiment continua operatiu amb les dades existents.
• Prova d'idempotència de notificacions: executar el consumidor dues vegades i verificar que no es dupliquen enviaments.
• Prova d'exportació/importació creuada: exportar, esborrar el compte, importar el fitxer i comparar l'historial resultant.
• Mètrica d'èxit inicial: percentatge d'usuaris que importen historial en la primera sessió i el mantenen actiu al cap de 30 dies.