Freshly Cosmetics

Freshly Cosmetics és una empresa catalana dedicada a la cosmètica natural, amb seu a Barcelona. La informació disponible la identifica com una startup. Cal assenyalar una discrepància entre les dades facilitades i la font: les dades la classifiquen dins del sector "Software i SaaS", mentre que la font consultada la descriu com una empresa de cosmètica. Aquesta contradicció no es pot resoldre amb el corpus disponible i, per tant, es deixa constància sense prendre partit.

La informació del corpus no permet detallar les circumstàncies, la data ni els promotors de la fundació. Aquestes dades no consten a la font disponible.

Segons la font, l'activitat de l'empresa és la cosmètica natural. El corpus no permet precisar el catàleg de productes, els canals de venda ni el perfil de client més enllà d'aquesta descripció general.

No consta al corpus informació sobre l'evolució del negoci, xifres de facturació, creixement o fites rellevants. Aquest apartat no es pot desenvolupar amb les dades disponibles.

L'empresa no consta com a tancada: segons les dades facilitades, l'estat registral és actiu. Per tant, no hi ha cap tancament a explicar. Aquest apartat s'inclou per coherència amb l'estructura demanada, però no hi ha fet de cessament a documentar.

Atès que l'empresa continua activa segons les dades disponibles, no es pot parlar d'herència en el sentit de llegat d'un negoci desaparegut. El corpus no aporta informació sobre l'impacte o la petjada de l'empresa.

El corpus no identifica les persones fundadores ni n'aporta cap traça. Aquesta informació no consta. Per completar-la caldria consultar el registre mercantil (BORME i Registre Mercantil de Barcelona) per identificar els administradors i socis, i fonts corporatives o periodístiques per conèixer la seva situació actual.

Amb la informació disponible no es poden extreure lliçons operatives específiques del sector: el corpus es limita a una descripció general de l'activitat i no aporta dades sobre estratègia, canals, marges, logística o gestió de marca. Qualsevol lliçó que s'hi afegís seria una suposició i no es pot sostenir amb les fonts. Per obtenir-ne, caldria disposar d'informació sobre l'evolució comercial de l'empresa i del sector de la cosmètica natural a Catalunya.

Reconstruir una marca de cosmètica natural d'alta rotació, venuda directament al consumidor per canal digital, però amb una estructura radicalment més lleugera que la d'una startup que fabrica i emmagatzema el seu propi producte.

La proposta: un catàleg curt (estimació: 8-12 referències en el llançament), formulació i fabricació subcontractades a tercers certificats, logística externalitzada, i una marca construïda sobre contingut i comunitat en lloc de sobre inversió publicitària massiva. L'essència es manté: natural, transparent, accessible, digital-first. El que canvia és qui assumeix el risc de fabricar i emmagatzemar.

Això és una proposta nova, no una descripció de com operava Freshly Cosmetics.

El mercat de la cosmètica natural i "clean beauty" existeix i és gran, però també està saturat de marques D2C. La barrera d'entrada és baixa (qualsevol pot subcontractar formulació i llançar una marca), cosa que vol dir que la diferenciació no ve del producte sinó de la distribució, la comunitat i el cost d'adquisició de client.

Nota de verificació: la font disponible (Wikipedia) és una entrada d'enciclopèdia i no permet afirmar xifres de mercat ni de facturació de l'empresa original. Qualsevol dada de mida de mercat o de quota s'hauria de validar amb fonts sectorials abans de fer-la servir en un pla real.

Model D2C amb marge brut objectiu alt (estimació: 60-70% sobre PVP, a validar amb proveïdor), sostingut per:

• Venda directa per web pròpia (marge complet, dades de client pròpies).
• Subscripció o recompra programada per als productes de rotació (reducció del cost d'adquisició).
• Un nombre limitat de referències per concentrar estoc i negociació amb el fabricant.
• Màrqueting de contingut i creadors en lloc de només paid media.

El punt crític del model és el cost d'adquisició de client (CAC) enfront del valor de vida (LTV). Sense recompra, una marca D2C de cosmètica no és rendible. Aquesta és una afirmació de model, no una dada de l'empresa original.

Fases, amb terminis estimats i a validar:

1. Validació (mesos 0-3): triar 3-5 productes, tancar un fabricant amb certificacions, muntar web i logística de tercers. Objectiu: vendre abans de produir en volum.
2. Llançament tancat (mesos 3-6): comunitat petita, mesurar recompra i CAC real.
3. Escalat selectiu (mesos 6-12): ampliar catàleg només si la recompra ho justifica; invertir en paid media només amb CAC conegut.

La disciplina del pla és no escalar despesa fins que la recompra estigui provada.

Totes les xifres són estimacions de rang, a validar amb pressupostos reals de proveïdors:

• Formulació i primera producció (8-12 referències, lots petits): rang estimat 25.000-60.000 €.
• Certificacions i compliment normatiu cosmètic (UE): estimació 5.000-15.000 €.
• Web, marca i contingut inicial: estimació 8.000-20.000 €.
• Logística de tercers i estoc inicial: estimació 10.000-25.000 €.
• Màrqueting de llançament: estimació 10.000-30.000 €.
• Total de rang estimat per començar: 60.000-150.000 €, depenent de si es fabrica estoc propi o es treballa amb producció sota demanda.

Aquestes xifres són una proposta de pressupost, no dades de Freshly Cosmetics.

• Saturació i CAC creixent: el cost d'adquirir client en cosmètica D2C puja any rere any; el model només funciona amb recompra forta.
• Marge pressionat pel fabricant: subcontractar formulació dona poc poder de negociació al principi.
• Regulació cosmètica: els requisits de compliment a la UE són estrictes i costosos per a lots petits.
• Estoc mort: un catàleg curt redueix el risc, però un producte que no ven immobilitza capital.
• Risc de marca: el nom i l'herència de l'empresa original poden tenir propietat intel·lectual associada; cal verificar la titularitat abans de fer servir res de l'original.

Lliçons que es desprenen de l'experiència d'una startup de cosmètica D2C que va tancar:

• El producte no és la barrera; la distribució sí. Qui construeixi això ha de saber vendre i mesurar CAC/LTV, no només formular.
• Lleugeresa per sobre de verticalitat. Fabricar i emmagatzemar un mateix multiplica el risc; subcontractar el redueix.
• Validar abans d'escalar. La causa habitual de mort en aquest sector és escalar despesa abans de provar la recompra.
• El perfil adequat és un equip petit amb capacitat de màrqueting digital i disciplina financera, no un equip gran de laboratori.

Les marques de cosmètica neta de mida mitjana (com el model que va popularitzar Freshly Cosmetics, segons la font disponible [Wikipedia] Freshly Cosmetics — Wikipédia, https://es.wikipedia.org/wiki/Freshly_Cosmetics) operen amb un volum alt de referències i reformulacions freqüents. El coll d'ampolla no és la fabricació sinó la informació: cada ingredient té múltiples identificadors (INCI, CAS, EINECS), restriccions per annex del Reglament (CE) 1223/2009, i cada claim de màrqueting ("sense sulfats", "vegà", "reef-safe") ha de poder-se traçar a una dada verificable de la fórmula.

Avui això es resol amb fulls de càlcul versionats a mà, correu electrònic amb proveïdors i documents PDF dispersos. Les conseqüències concretes són: (1) reformulacions que trenquen un claim sense que ningú ho detecti, (2) PIF incomplets en auditoria, (3) temps de QA documental de setmanes per llançament, i (4) impossibilitat de respondre ràpidament a un client o distribuïdor que pregunta per la composició.

La solució no és un ERP genèric ni un PLM industrial: és una eina vertical on el model de dades és la normativa cosmètica.

Arquitectura de monolític modular amb serveis separables, triada perquè l'equip inicial és petit i el domini és fortament transaccional i relacional (fórmules, versions, restriccions). No cal microserveis el dia u; sí que cal que el motor de regles normatives sigui un mòdul aïllat amb interfície estable, perquè és l'actiu diferencial i canviarà amb cada actualització d'annexos.

``` [SPA React] --HTTPS--> [API Gateway] | [App core: Node/NestJS] | | | [Postgres] [Motor regles] [Cua de jobs] (dades + (servei (generació PDF, JSONB) normatiu) càlculs, exports) | [Object storage S3] (PIF, certificats proveïdor) ```

Decisions i motius:

• PostgreSQL amb columnes JSONB per a l'estructura d'ingredients i paràmetres de fórmula: el domini és relacional però els atributs d'ingredient varien molt entre famílies; JSONB evita migracions constants sense perdre consultes indexades.
• Motor de regles com a servei separat (stateless, determinista): les restriccions normatives s'han de poder versionar i auditar independentment del codi d'aplicació. Mateix input + mateixa versió de regles = mateix output, requisit per a validació.
• Cua de jobs asíncrona per a generació de PIF i càlculs de percentatges: són operacions costoses i no han de bloquejar la UI.
• Object storage immutable amb versionat per a documents: cada PIF generat queda amb hash i timestamp; és la prova d'auditoria.
• Multi-tenant per `tenant_id` a totes les taules amb Row Level Security de Postgres: una sola base de dades, aïllament garantit pel motor.

Entitats principals (simplificat):

``` tenant(id, nom, pla) ingredient(id, tenant_id, inci_name, cas, einecs, familia, restriccions JSONB, origen, certificacions[]) proveedor(id, tenant_id, nom, pais) ingredient_proveedor(ingredient_id, proveedor_id, ref, cost, certificat_url) formula(id, tenant_id, nom, estat, creada_per) formula_versio(id, formula_id, num_versio, data, estat, percentatges JSONB, notes) formula_versio_ingredient(formula_versio_id, ingredient_id, pct) claim(id, tenant_id, text, tipus, regla_validacio_id) producte(id, tenant_id, formula_id, nom_comercial, ean) pif(id, producte_id, versio, hash, storage_url, generat_el) auditoria(id, tenant_id, entitat, entitat_id, accio, abans JSONB, despres JSONB, usuari, ts) ```

Punts clau:

• `formula_versio` immutable un cop publicada: qualsevol canvi crea una versió nova. Motiu: la traçabilitat del PIF exigeix saber exactament quina composició es va declarar.
• `percentatges JSONB` a la versió de fórmula per permetre càlculs ràpids de suma i validació de rang (ha de sumar 100 ± tolerància).
• `claim.regla_validacio_id` enllaça cada claim a una regla executable; un claim sense regla no es pot publicar. Això converteix el màrqueting en dada verificable.
• `auditoria` append-only amb trigger que bloqueja UPDATE/DELETE.

API REST versionada (`/v1`), autenticació OAuth2 + JWT per tenant, claus d'API per a integracions màquina-màquina.

Endpoints representatius:

``` GET /v1/ingredients?q=&familia=&restriccio= POST /v1/formulas POST /v1/formulas/{id}/versions POST /v1/formulas/{id}/versions/{v}/validate -> informe de regles POST /v1/products/{id}/pif -> job asíncron GET /v1/products/{id}/claims/check POST /v1/webhooks -> subscripció a events ```

Integracions prioritàries i el seu motiu:

• Importació CSV/XLSX de fitxes de proveïdor cap al catàleg d'ingredients: és el punt d'entrada real de dades; sense això l'adopció és nul·la.
• Exportació a format PIF i fitxa tècnica PDF: sortida que el client ja fa servir avui.
• Webhook `formula.version.published` perquè sistemes de màrqueting o e-commerce validin claims abans de publicar.
• Catàleg normatiu versionat (annexos del Reglament 1223/2009) carregat com a dades, no com a codi, per actualitzar-lo sense desplegament.

Ordre deliberat per validar el valor abans d'ampliar:

1. Catàleg d'ingredients amb importació CSV i restriccions bàsiques (prohibits, límits de concentració). És la base de tot i el que més dolor elimina.
2. Fórmules versionades amb validació de suma i detecció d'ingredients prohibits. Aquí es demostra el valor central.
3. Motor de regles mínim per a 5-10 claims freqüents ("sense sulfats", "vegà", "sense parabens") executat sobre la versió de fórmula.
4. Generació de fitxa tècnica PDF (no encara PIF complet).
5. Auditoria i historial de versions visible a la UI.

El PIF complet, les integracions de proveïdor avançades i el multi-idioma queden per a la fase 2: no són necessaris per demostrar el producte.

• Risc: el motor de regles és el producte i és difícil. Un claim com "vegà" depèn de l'origen de cada ingredient i de certificacions de proveïdor que sovint falten. Mitigació: començar amb regles deterministes sobre dades que l'usuari ja té, i marcar explícitament els claims com a "no verificables" quan falta dada, en lloc de bloquejar.
• Risc: qualitat de dades d'entrada. Les fitxes de proveïdor són heterogènies. Mitigació: importador amb previsualització i mapa de columnes configurable, no un parser automàtic "màgic".
• Risc normatiu. Els annexos canvien; una regla mal codificada dona falsa seguretat. Mitigació: versionat de regles, tests de regressió per regla amb casos de referència, i disclaimer que l'eina assisteix però no substitueix l'avaluació de seguretat (RP).
• Mida d'equip realista: 3-4 enginyers per al nucli (backend + frontend + motor de regles), 1 persona de domini cosmètic a temps parcial. Escalatge de dades modest: desenes de milers d'ingredients i fórmules per tenant, no big data; Postgres és suficient.

• Validació funcional del motor de regles: suite de casos de referència per regla (ingredient prohibit, límit superat, claim trencat per reformulació) amb resultat esperat; ha de passar al 100% abans de publicar cap regla.
• Test d'integració del flux complet: importar catàleg → crear fórmula → validar → generar fitxa → comprovar hash i auditoria.
• Prova d'acceptació amb usuari real: una marca pilot ha de poder reproduir una fórmula existent i obtenir un informe de validació en menys d'una hora, contra el criteri d'èxit de reduir el QA documental de setmanes a dies.
• Test de reformulació: canviar un ingredient en una versió nova i verificar que el sistema detecta i marca el claim afectat; és la prova que el producte resol el problema central.
• Auditoria: verificar que cap operació sobre `auditoria` permet modificació i que cada PIF generat és reproduïble a partir de la versió de fórmula i la versió de regles registrades.