TV Time

TV Time era una aplicació de programari del sector del software i SaaS, dedicada al seguiment de sèries i pel·lícules. Segons ADSLZone, el seu creador va anunciar el tancament de l'aplicació i, al mateix temps, el llançament d'una nova app.

La ubicació de l'empresa i la seva raó social completa no consten a les dades disponibles.

No consta a les dades disponibles la data de fundació de TV Time ni el nom del seu fundador o fundadors. La font periodística consultada (ADSLZone) es refereix a "su creador" en singular, però no n'especifica la identitat.

TV Time era una aplicació de seguiment de sèries i pel·lícules. Segons la informació disponible, l'ús principal era que els usuaris poguessin fer el seguiment del que veien. No consten a les dades disponibles detalls sobre el model de negoci, la base d'usuaris o els mercats on operava.

No consta a les dades disponibles informació sobre l'evolució de l'empresa, els seus ingressos, la seva base d'usuaris o els seus anys de creixement.

La causa del tancament no consta a les dades disponibles. L'única informació verificada és que, segons ADSLZone (14 de juliol de 2026), TV Time tancava l'endemà, el 15 de juliol de 2026, i que el seu creador llançava una nova aplicació el mateix mes. La font no indica els motius del tancament.

Segons ADSLZone, el creador de TV Time va llançar una nova aplicació el mateix mes del tancament. No consta a les dades disponibles cap altra informació sobre la continuïtat del producte, la seva venda o la migració d'usuaris.

El creador de TV Time consta a la font periodística com la persona que va llançar una nova aplicació el juliol de 2026. La seva identitat no consta a les dades disponibles. Per ampliar aquesta informació es podrien consultar el registre mercantil corresponent, les notes de premsa del llançament de la nova aplicació i les fonts periodístiques especialitzades en tecnologia.

• En aplicacions de seguiment de contingut audiovisual, la propietat de les dades de l'usuari (historial de visionat, llistes) és un actiu central: quan l'app tanca, cal saber si aquestes dades es poden exportar o migrar, i la font consultada no ho aclareix.
• El llançament d'una nova app pel mateix creador el mateix mes del tancament indica que el coneixement del producte i de la base d'usuaris pot sobreviure al tancament de la societat; per això, en aquest sector, convé distingir entre el tancament de l'empresa i la continuïtat del producte.
• La manca de dades públiques sobre la causa del tancament en una app de consum massiu mostra la importància de documentar les decisions de tancament (comunicació a usuaris, terminis i gestió de dades) perquè siguin verificables posteriorment.

La font disponible [ADSLZone, 2026-07-14] només confirma que TV Time tanca i que el seu creador llança una altra app el mateix mes. No consta la causa del tancament, ni el nombre d'usuaris, ni el model de negoci que tenia. Per tant, qualsevol reconstrucció ha de partir d'una premissa prudent: no sabem per què va fallar, i això és una dada important.

La proposta, doncs, no és "refer TV Time igual", sinó reconstruir la funció: una app on una persona marca què ha vist, en quin punt va, i ho comparteix amb qui vol. Avui això es pot fer amb una arquitectura molt més barata que fa cinc o vuit anys: backend gestionat, autenticació de tercers, catàlegs via API pública i una app mòbil o fins i tot una web progressiva.

La diferència clau respecte de l'original és l'abast: començar amb un producte petit, d'un sol propòsit, i créixer només si hi ha retenció real.

No tenim dades verificades del mercat de TV Time. El que sí que podem afirmar és que el nínxol existeix: hi ha hàbit de seguiment de sèries i pel·lícules, i hi ha hàbit de compartir-ho. Les xarxes generalistes cobreixen part d'aquesta funció, però no l'especialitzen.

El mercat realista per a un producte nou és:

• Usuaris que volen privacitat: gent que vol registrar què veu sense que això alimenti un perfil publicitari.
• Usuaris que volen una cosa simple: marcar capítols i prou, sense gamificació agressiva.
• Comunitats petites: grups de gent que ja comparteixen gustos i volen una eina pròpia.

Mida de mercat: no verificable amb les fonts disponibles. Qualsevol xifra d'usuaris potencials seria una estimació a validar amb una prova de demanda abans d'invertir.

Proposta (no verificada, a validar):

• Freemium: funcions bàsiques gratuïtes (seguiment, historial, llistes) i de pagament les que costen diners de mantenir o aporten valor extra (sincronització multi-dispositiu avançada, estadístiques, exportació, grups privats).
• Subscripció individual amb un preu baix, tipus 1–3 €/mes (estimació; a validar amb enquestes de disposició a pagar).
• Sense publicitat basada en perfilat com a posicionament, o publicitat contextual no invasiva si cal.
• Possibles ingressos addicionals: afiliació a plataformes de streaming (a validar legalment i comercialment) i una versió per a grups o comunitats.

La lliçó del tancament, sense causa verificada, és que el model ha de ser sostenible des del primer dia: costos baixos, ingressos aviat, i cap dependència d'una sola font d'ingressos.

Fases, amb terminis estimats (a validar):

1. Fase 0 — Validació (4–6 setmanes): entrevistes a 20–30 persones que hagin fet servir apps de seguiment; landing page per mesurar interès; definir l'abast mínim.
2. Fase 1 — MVP (8–12 setmanes): seguiment de sèries i pel·lícules, historial, llistes, compartir per enllaç. Sense xarxa social completa.
3. Fase 2 — Primers usuaris (2–3 mesos): beta tancada amb 100–300 persones; mesurar retenció a 30 dies.
4. Fase 3 — Monetització (a partir del mes 6): introduir subscripció quan hi hagi hàbit d'ús demostrat.
5. Fase 4 — Creixement (mes 9+): només si les mètriques ho justifiquen.

Criteri d'aturada explícit: si la retenció a 30 dies és baixa, no escalar.

Totes les xifres són estimacions a validar, no dades de TV Time:

• Desenvolupament: 15.000–40.000 € per a un MVP sòlid (freelance o equip petit), o 0 € si el fundador programa i compta el temps com a inversió.
• Infraestructura i serveis: 50–300 €/mes en fase inicial (hosting gestionat, autenticació, base de dades, APIs de catàleg).
• Disseny i marca: 2.000–6.000 €.
• Legal i compliment (RGPD, termes, política de privacitat): 1.000–3.000 €.
• Màrqueting inicial: 1.000–5.000 € per a proves de canals.
• Total realista per començar: rang de 20.000–55.000 €, o menys si es fa amb temps propi.

• Causa del tancament desconeguda: no consta per què va tancar TV Time [ADSLZone, 2026-07-14]. Això vol dir que no podem descartar que el problema fos estructural (manca de disposició a pagar, costos, competència). Cal validar-ho abans d'invertir.
• Competència de plataformes gratuïtes: les xarxes generalistes i les mateixes plataformes de streaming cobreixen part de la funció.
• Dependència d'APIs de tercers per als catàlegs: poden canviar condicions o preus.
• Adquisició d'usuaris cara: el cost per usuari pot superar el valor que genera si el model és freemium.
• Privacitat i RGPD: gestionar dades de consum audiovisual és dades personals; cal fer-ho bé des del principi.
• Risc de "producte bonic sense negoci": moltes apps de seguiment moren per això.

Aquest informe no és un currículum, sinó un resum de les lliçons que es poden extreure del cas:

1. No copiar l'escala, copiar la funció: TV Time va arribar a una mida que probablement exigia un model de negoci que no es va sostenir (causa no verificada). Un producte nou ha de començar petit.
2. Validar la disposició a pagar abans de construir: el tancament recorda que l'ús gratuït massiu no paga factures.
3. Reduir dependències: com menys APIs de tercers i menys cost fix, més marge per corregir.
4. Mesurar retenció, no descàrregues: és l'única mètrica que diu si el producte té sentit.
5. Documentar la causa del fracàs aliè: la font disponible no ho diu; qui vulgui reconstruir-ho hauria d'investigar-ho abans de comprometre diners.

En resum: la persona o equip adequat és petit, tècnic i prudent, capaç de llançar un MVP en mesos i aturar-se si les dades no acompanyen.

El 14 de juliol de 2026 es va anunciar que TV Time tancava l'endemà i que el seu creador llançava una app nova aquell mateix mes [ADSLZone, 2026-07-14]. La font no detalla la causa del tancament ni el destí de les dades dels usuaris, i per tant no podem afirmar res sobre si l'exportació oficial estarà disponible ni fins quan.

El problema tècnic concret és la migració d'historials de visionat: sèries amb episodis marcats, pel·lícules vistes, puntuacions, llistes personalitzades i estadístiques acumulades durant anys. Aquestes dades són difícils de reconstruir manualment i són el principal actiu de retenció d'un servei de tracking. Un servei que les importi de manera fiable i les mantingui exportables en formats oberts resol la pèrdua de continuïtat i redueix el cost de canvi cap a l'app del creador.

Arquitectura en tres serveis desplegats en un sol proveïdor cloud, amb una base de dades relacional i una cua de treball asíncrona:

``` [App web / mòbil] --HTTPS--> [API Gateway + Auth] | +-------------+-------------+ | | [Servei de catàleg] [Servei d'importació] | | | [Cua de jobs] | | +----------> [PostgreSQL] <--+ | [Magatzem d'objectes] (fitxers d'exportació) ```

• PostgreSQL com a font de veritat: les relacions entre sèries, episodis i marques de visionat són inherentment relacionals i es consulten amb agregacions (estadístiques per any, per gènere, temps total). Un document store complicaria aquestes consultes.
• Cua de jobs per a la importació: un fitxer d'exportació pot contenir desenes de milers de files i la conciliació amb el catàleg fa crides externes; fer-ho en la petició HTTP trencaria els temps d'espera.
• Magatzem d'objectes per als fitxers originals: cal conservar l'exportació tal com es va rebre per poder reprocessar-la si la conciliació falla, i per complir el dret de portabilitat.
• Catàleg desacoblat de la font externa: les metadades de sèries i episodis es guarden en taules pròpies amb identificadors propis i mapes cap a identificadors externs, de manera que un canvi de proveïdor de metadades no obligui a migrar les dades dels usuaris.

Taules principals (simplificat):

```sql users(id, email, created_at, locale) titles(id, kind / series|movie /, canonical_name, year, external_ids jsonb) seasons(id, title_id, number) episodes(id, season_id, number, air_date) watch_events(id, user_id, episode_id, watched_at, source / import|manual /) movie_views(id, user_id, title_id, watched_at, rating) ratings(id, user_id, title_id, score, rated_at) lists(id, user_id, name, is_public) list_items(list_id, title_id, position) import_jobs(id, user_id, status, file_key, rows_total, rows_ok, rows_failed, created_at) import_errors(id, import_job_id, raw_row jsonb, reason) ```

Decisions i motius:

• `watch_events` com a esdeveniments i no com a booleà "vist": permet estadístiques per data, rewatches i correccions sense perdre informació.
• `external_ids` en `jsonb`: els identificadors de proveïdors externs varien i canvien; un camp flexible evita migracions d'esquema.
• `import_errors` guarda la fila original: l'usuari ha de poder veure què no s'ha pogut importar i corregir-ho, en lloc de rebre un recompte opac.

• `POST /v1/imports` — puja un fitxer d'exportació, retorna `import_job_id`. Validació de mida i tipus abans d'encuar.
• `GET /v1/imports/{id}` — estat, recomptes i mostra d'errors.
• `GET /v1/me/library` — historial paginat amb filtres per any, gènere i estat.
• `GET /v1/me/export?format=csv|json` — exportació completa en format obert; és requisit de producte, no un extra.
• `POST /v1/watch-events` — registre manual o des d'un client.

Integracions:

• Metadades de catàleg: proveïdor extern per resoldre noms, anys i episodis. La conciliació és probabilística (títol + any + nombre d'episodis) i sempre deixa els candidats dubtosos en estat `pending_review` en lloc de decidir automàticament.
• Format d'entrada: el parser s'ha de construir contra el format real d'exportació de TV Time; com que la font disponible no en documenta l'esquema [ADSLZone, 2026-07-14], el parser ha de ser tolerant i versionat, amb un adaptador per format.

1. Parser i importador d'exportacions amb informe d'errors per fila. És l'única funció que justifica el producte en la finestra de migració.
2. Catàleg mínim (sèries, temporades, episodis) amb conciliació i cua de revisió manual.
3. Exportació en format obert des del primer dia: és la promesa que diferencia el producte i redueix el risc percebut per l'usuari.
4. Auth i biblioteca bàsica (llistat i estadístiques simples).

No es construeix primer: recomanacions, social, app mòbil nativa. Cap d'aquestes funcions resol el problema immediat i totes depenen d'un historial ja importat.

• Volum d'importació: un usuari pot portar desenes de milers d'esdeveniments; el job ha de processar per lots i ser idempotent per poder reintentar sense duplicar.
• Qualitat de la conciliació: és el risc principal. Un títol mal aparellat contamina l'historial i erosiona la confiança. Mitigació: no decidir mai automàticament per sota d'un llindar de confiança i exposar els dubtes a l'usuari.
• Dependència del format de TV Time: no tenim documentació verificada de l'exportació; si el format canvia o desapareix, l'importador queda cec. Mitigació: adaptadors versionats i conservació del fitxer original.
• Finestra temporal: el tancament és imminent [ADSLZone, 2026-07-14]; el temps de desenvolupament és el recurs més escàs i obliga a retallar abast.
• Proveïdor de metadades: límits de tarifa i canvis de llicència; cal cachejar i tenir un pla B de font.

• Test de conciliació amb un conjunt de fitxers d'exportació reals i anonimitzats: mètrica d'encerts exactes, aparellaments dubtosos i errors, amb objectiu definit abans de llançar.
• Test d'idempotència: importar dues vegades el mateix fitxer ha de produir el mateix estat final.
• Test de round-trip: importar, exportar i tornar a importar ha de conservar el nombre d'esdeveniments i les dates.
• Prova d'usuari amb usuaris reals de TV Time: mesurar si l'informe d'errors els permet acabar la migració sense suport.
• Càrrega: un job de 50.000 files ha de completar-se dins d'un objectiu de temps acordat i sense bloquejar la resta del servei.

Nota de verificació: l'única dada confirmada sobre el tancament és l'anunci de tancament i el llançament d'una app nova pel creador [ADSLZone, 2026-07-14]. La causa del tancament i l'estat de les dades dels usuaris no consten i no s'han d'assumir en la implementació.