Nova Launcher

Nova Launcher consta al corpus com una startup del sector del software i SaaS. Segons el titular d'Infobae del 10 de setembre de 2025, es tractava de "la app que activaba los modos de WhatsApp". La ubicació no consta.

No consta cap dada sobre la fundació: ni la data, ni els fundadors, ni el lloc. El corpus no inclou aquesta informació.

D'acord amb el titular d'Infobae, l'aplicació activava modes de WhatsApp. El corpus no permet precisar quins modes, com funcionava tècnicament ni quin era el perfil d'usuari objectiu.

No consta informació sobre mètriques d'usuaris, ingressos, rondes de finançament o fites de creixement. El corpus no conté dades d'aquest període.

El tancament consta datat el 10 de setembre de 2025, segons Infobae. La causa verificada del tancament no consta al corpus. La font disponible és periodística i no detalla els motius en les dades subministrades.

No consta cap informació sobre continuïtat del producte, adquisició per tercers, alternatives oberts o comunitat d'usuaris que hagi perdurat. El corpus no ho recull.

No consta cap identificació dels fundadors ni de la seva trajectòria posterior. Per completar aquesta informació caldria consultar el registre mercantil corresponent (BORME, si és una societat espanyola) i fonts primàries de l'empresa; el corpus no permet determinar-ho.

• Una aplicació que depèn de funcionalitats o modes d'una plataforma de tercers (en aquest cas, WhatsApp) queda exposada a canvis de política o d'API del titular de la plataforma; el corpus no confirma que aquest fos el motiu, però és el risc estructural que es desprèn del model descrit.
• El corpus no permet extreure'n lliçons operatives addicionals: no hi ha dades sobre producte, equip, finançament ni causa del tancament. Qualsevol conclusió més enllà d'això seria una suposició no verificada.

Nova Launcher era un llançador d'Android: una aplicació que substitueix la pantalla d'inici del telèfon i permet personalitzar icones, graelles, gestos i automatitzacions. Segons la font disponible (Infobae, 2025-09-10), se'l descrivia com "la app que activaba los modos de WhatsApp", és a dir, que la seva proposta de valor percebuda anava lligada a automatitzar i personalitzar l'experiència d'ús del mòbil.

La idea reconstruïda avui seria la mateixa essència —control i personalització de l'escriptori del mòbil— però empaquetada com a capa d'automatització modular: perfils d'ús (feina, personal, conducció), automatitzacions per aplicació i gestos, i sincronització opcional al núvol. És una proposta, no una descripció del producte original.

El mercat dels llançadors d'Android existeix i és global, però és un nínxol: la majoria d'usuaris es queden amb el llançador de fàbrica. El segment disposat a pagar és petit i concentrat en usuaris avançats ("power users"), entusiastes de la personalització i mercats on la personalització té més pes.

No tinc dades verificades de mida de mercat ni de quota de Nova Launcher; qualsevol xifra que es faci servir per dimensionar-ho hauria de venir d'estudis de tercers i validar-se abans d'invertir. El que sí que és verificable és que el producte existia i tenia usuaris fins al 2025, i que el seu tancament deixa un buit de demanda que algú pot cobrir.

Proposta de model (a validar):

• Freemium: versió gratuïta amb personalització bàsica; subscripció o compra única per a automatitzacions avançades, perfils i sincronització.
• Compra única com a alternativa: és el model que històricament encaixa millor amb aquest tipus d'app, però genera menys ingressos recurrents.
• Ingressos complementaris: packs de temes/icones de creadors amb repartiment de revenue.

Risc de model: la disposició a pagar per un llançador és baixa; caldrà mesurar conversió real abans de fixar preus. Qualsevol previsió d'ingressos és, avui, una estimació a validar.

1. Fase 0 – Validació (1-2 mesos): enquesta a comunitats d'usuaris avançats d'Android, llista d'espera, prototip de les 3 automatitzacions més demanades.
2. Fase 1 – MVP (3-4 mesos): llançador funcional + 2-3 automatitzacions clau + versió gratuïta. Publicació a Google Play.
3. Fase 2 – Monetització (mes 5-8): introduir subscripció/compra, mesurar conversió, iterar.
4. Fase 3 – Creixement (mes 9-12): marketplace de temes, aliances amb creadors, expansió a mercats on la personalització té més demanda.

Aquest calendari és una proposta, no un pla verificat.

Totes les xifres són estimacions de rang, a validar:

• Equip mínim (1-2 desenvolupadors Android + 1 dissenyador a temps parcial): cost dependent de la ubicació; en un context europeu, un rang orientatiu de 8.000-20.000 €/mes per a un equip petit, o menys si és fundador-treballador.
• Desenvolupament MVP: 3-4 mesos d'equip → rang orientatiu de 30.000-80.000 € segons equip i ubicació.
• Infraestructura i serveis (Play Console, backend lleuger, analítica): rang orientatiu de 100-500 €/mes.
• Màrqueting inicial i comunitat: 5.000-15.000 € per a la primera fase.
• Total orientatiu per arribar a MVP publicat: rang de 40.000-100.000 €, a validar amb pressupostos reals.

• Risc de plataforma: dependència total de Google Play i de les polítiques d'Android; canvis de sistema poden trencar funcionalitats.
• Risc de monetització: baixa disposició a pagar en aquesta categoria.
• Risc competitiu: llançadors gratuïts i el propi llançador de fàbrica competeixen directament.
• Risc de marca: el nom "Nova Launcher" pot estar subjecte a drets; caldria verificar la titularitat abans de reutilitzar-lo.
• Causa del tancament desconeguda: com que la causa verificada no consta, no es pot descartar que fos per pressió de plataforma, competència o manca de rendibilitat; caldria investigar-ho abans de replicar el model.

Lliçons de l'informe original (a partir dels fets verificats i de la font disponible):

• Un producte de nínxol pot tenir èxit d'ús i, tot i així, tancar: la mida de la comunitat no garanteix la sostenibilitat econòmica.
• La dependència d'una sola plataforma (Android/Google Play) és un risc estructural que cal gestionar des del dia u.
• La proposta de valor percebuda ("modos de WhatsApp") pot ser més estreta que el producte real; convé validar què paga la gent abans d'invertir.
• Qui ho hauria de fer: un equip petit, tècnic i proper a la comunitat d'usuaris avançats, amb capacitat de validar monetització aviat i amb un pla explícit per al risc de plataforma.

Nova Launcher era popular perquè permetia automatitzar canvis d'estat del telèfon: silenciar WhatsApp en un mode, canviar iconografia en un altre, etc. El tancament deixa un buit funcional: usuaris que tenien "modes" configurats es queden sense mecanisme integrat, i les alternatives (Tasker, Routines de Samsung) són cares, fragmentades per fabricant o poc descobribles.

El producte que proposo no és un launcher: és una capa de perfils que qualsevol launcher o el sistema pot invocar. Resol tres coses concretes:

1. Definir perfils declaratius (notificacions per app, DND, brillantor, rotació, wallpaper/icon pack si el launcher ho suporta).
2. Activar-los des de Quick Settings, widgets, calendaris o geofencing.
3. Sincronitzar-los entre dispositius del mateix usuari.

El motiu de no fer un launcher és directe: el mercat de launchers està saturat, la distribució a Play Store és costosa i el risc de política (permisos d'accessibilitat) és alt. Un servei de perfils té superfície més petita i es pot vendre com a complement.

Tres components, tots amb una responsabilitat clara:

``` [App Android (Kotlin)] ├─ UI de perfils (Compose) ├─ ProfileEngine (aplica perfils via APIs del sistema) ├─ QSTileService + WidgetProvider (activació ràpida) └─ SyncClient (Retrofit + WorkManager) │ HTTPS/JSON ▼ [Backend (Go, desplegat a Fly.io o similar)] ├─ API REST /v1/profiles ├─ Auth (OIDC via Google Sign-In, tokens JWT curts) └─ Postgres (perfils + versions) │ ▼ [Consola web (opcional, fase 2)] ```

Decisions i motius:

• Kotlin + Jetpack Compose: és l'stack estàndard per a apps Android modernes i redueix el temps de construcció de la UI de perfils.
• ProfileEngine basat en `NotificationManager.Policy`, `AudioManager` i `Settings.System`: són APIs públiques estables; evito `AccessibilityService` en la v1 perquè Play Store el revisa amb lupa i perquè molts canvis de notificació per app es poden fer amb `NotificationChannel` i polítiques de DND per paquet.
• Quick Settings Tile com a entrada principal: és el punt d'accés que feia servir la gent amb Nova; no requereix permisos especials i és descobrible.
• Backend en Go + Postgres: el domini és petit (CRUD de perfils versionats); Go dona binaris petits i desplegament senzill, i Postgres cobreix la necessitat de versionat amb `jsonb`.
• Sync opcional i xifrat client-side: els perfils poden contenir noms d'apps i horaris; xifro el payload amb una clau derivada del compte perquè el backend no vegi el contingut.

Entitats principals (Postgres, però el client en té una còpia local a Room):

```sql -- Usuaris (només identificador i clau pública de sincronització) users(id uuid pk, oidc_sub text unique, created_at timestamptz)

-- Perfils versionats: cada edició crea una versió nova profiles( id uuid pk, user_id uuid fk, name text, -- "Feina", "Nit" icon text, -- nom d'icona Material current_version int, deleted_at timestamptz null )

profile_versions( profile_id uuid fk, version int, payload_enc bytea, -- JSON xifrat client-side payload_hash text, -- SHA-256 per detectar conflictes created_at timestamptz, primary key (profile_id, version) )

-- Dispositius per a sync selectiu devices(id uuid pk, user_id uuid fk, name text, last_seen timestamptz, push_token text null) ```

El `payload` (abans de xifrar) té aquesta forma:

```json { "dnd": {"mode": "priority", "allow": ["com.whatsapp"]}, "notifications": {"com.whatsapp": "silent", "com.slack": "default"}, "sound": {"ring": "vibrate", "media_volume": 0.3}, "display": {"brightness": 0.4, "rotation_lock": "portrait"}, "triggers": [{"type": "schedule", "cron": "0 22 1-5"}] } ```

Motiu del versionat: permet revertir un canvi dolent i resol conflictes entre dispositius sense bloquejos; el client compara `payload_hash` i, si difereix, mostra un diàleg de resolució.

API REST mínima, autenticada amb JWT emès després de Google Sign-In:

``` GET /v1/profiles -> llista (metadades, no payload) GET /v1/profiles/{id}?version=N -> payload xifrat POST /v1/profiles -> crea perfil (versió 1) PUT /v1/profiles/{id} -> nova versió (If-Match: hash) DELETE /v1/profiles/{id} -> soft delete POST /v1/devices -> registra dispositiu per push ```

Integracions al dispositiu:

• Quick Settings Tile: `TileService` que obre un selector de perfils; un toc aplica l'últim perfil actiu.
• Widgets: `AppWidgetProvider` amb un botó per perfil.
• Calendar / geofencing (fase 2): `AlarmManager` per horaris i `GeofencingClient` per ubicacions; tots dos són APIs del sistema, sense permisos d'accessibilitat.
• Importador de Nova: parsejar backups `.novabackup` (zip amb JSON) per extreure configuracions de carpetes i modes i convertir-les en perfils. Això és el ganxo de migració i el motiu pel qual val la pena començar per aquí.

El que no faré servir a la v1: `AccessibilityService`. Motiu: Play Store exigeix justificació i revisió manual; el risc de rebuig és massa alt per a un MVP.

Ordre pensat per validar el valor abans d'invertir en infraestructura:

1. Importador de backups de Nova (2-3 setmanes): converteix un `.novabackup` en un conjunt de perfils locals. És la manera de captar usuaris orfes de Nova amb una promesa concreta.
2. ProfileEngine local + QS Tile (3 setmanes): aplicar perfils sense backend. Aquí es valida si les APIs públiques cobreixen prou casos.
3. Persistència local amb Room i export/import JSON (1 setmana): permet backup manual sense compte.
4. Backend de sync i auth (3 setmanes): només quan hi hagi usuaris que ho demanin.
5. Widgets i triggers per horari (2 setmanes).

Motiu de l'ordre: l'importador i el motor local són el producte; el sync és una comoditat. Si el motor no cobreix prou casos, el sync no salva el producte.

Mides orientatives per a un equip de 2 enginyers Android + 1 backend a temps parcial:

• MVP (passos 1-3): ~6-8 setmanes.
• Sync (pas 4): +3 setmanes.
• Cost d'infraestructura: <50 €/mes amb Postgres gestionat i un parell d'instàncies petites.

Riscos i mitigacions:

• Fragmentació de fabricants: alguns OEM bloquegen canvis de DND o de brillantor des d'apps de tercers. Mitigació: detectar capacitats a l'startup (`PackageManager`, `Settings.System.canWrite`) i degradar el perfil amb un avís clar.
• Polítiques de Play Store: si més endavant cal `AccessibilityService`, el risc de rebuig és alt. Mitigació: no dependre'n mai; si s'usa, que sigui opcional i amb justificació explícita.
• Conflictes de sync: dos dispositius editant el mateix perfil. Mitigació: versionat + `If-Match` amb hash; el client resol manualment.
• Privacitat: els perfils revelen hàbits. Mitigació: xifrat client-side i opció de no sincronitzar mai.
• Marca: "Nova" està associada a un producte mort; cal un nom nou i comunicar la migració, no la continuïtat.

Criteris mesurables per fase:

1. Importador: sobre 20 backups reals de Nova, extreure ≥80% de les configuracions de modes i carpetes sense errors. Mètrica: percentatge de camps reconeguts i nombre d'avisos per backup.
2. Motor local: sobre 10 dispositius de 5 fabricants diferents, aplicar un perfil de prova (DND + volum + brillantor) i verificar l'estat final amb `dumpsys` o lectura d'APIs. Èxit si ≥8/10 dispositius apliquen tots els camps o informen correctament dels no suportats.
3. QS Tile: test d'usabilitat amb 5 usuaris; han d'activar un perfil en ≤2 tocs des de la pantalla d'inici.
4. Sync: test de conflicte amb dos dispositius editant el mateix perfil; el sistema ha de detectar el conflicte i no perdre cap versió.
5. Telemetria mínima: comptador anònim d'activacions per tipus de trigger, sense contingut de perfils, per mesurar adopció.

La validació global és: un usuari que venia de Nova pot reproduir els seus modes habituals en menys de 10 minuts des de la instal·lació, i el 80% dels seus perfils funcionen sense configuració manual addicional.