KHAOS DIGITAL SOCIEDAD LIMITADA

Khaos Digital Sociedad Limitada era una societat mercantil de responsabilitat limitada amb domicili a València, classificada dins del sector del software i SaaS. D'acord amb la fitxa registral consultada a OpenMercantil a partir del BORME, la societat es va constituir l'any 2026 i el mateix any va quedar inscrita en situació concursal.

No consta a les dades disponibles cap altra informació sobre l'objecte social detallat, el capital, la plantilla o els productes de l'empresa.

La societat es va constituir l'any 2026. No consten a les dades disponibles ni la data exacta de constitució, ni els socis fundadors, ni l'escriptura de constitució, ni el capital social inicial. Aquesta informació es podria obtenir consultant la fitxa registral completa al Registre Mercantil de València o bé el BORME del dia de la constitució.

La classificació sectorial disponible la situa en el software i SaaS. No consta a les dades cap descripció de l'activitat concreta, dels productes, dels clients ni del model de negoci. Qualsevol afirmació sobre què venia o a qui s'adreçava seria una suposició i, per tant, no es fa.

No consta cap període d'activitat pròspera. La cronologia registral disponible només recull la constitució el 2026 i la inscripció en situació concursal el 18 d'agost de 2026, dins del mateix any. No hi ha dades de facturació, clients ni creixement.

Segons el BORME, el 18 d'agost de 2026 es va inscriure la situació concursal de Khaos Digital Sociedad Limitada. La font registral no detalla a les dades disponibles el tipus de procediment concursal, la causa de la insolvència ni el resultat final del procediment. No consta, per tant, si es tracta d'un concurs voluntari o necessari, ni si la societat ha estat dissolta o liquidada.

No consta a les dades cap informació sobre actius, propietat intel·lectual, cartera de clients, marca o codi font que hagi pogut sobreviure a la situació concursal. La fitxa registral consultada no recull transmissions ni operacions posteriors.

No consta a les dades el nom de cap fundador ni de cap administrador de la societat. Per identificar-los i conèixer la seva situació actual caldria consultar la fitxa completa del Registre Mercantil de València (nomenaments i cessaments d'administradors) i el BORME dels actes societaris. Amb la informació disponible no es pot dir res sobre les persones que hi havia darrere.

• En una societat de software constituïda i concursada dins del mateix any, el primer indicador a vigilar no és el creixement sinó la ràtio de despesa fixa compromesa abans de tenir ingressos recurrents: els contractes de serveis cloud, llicències i sous signats a la constitució determinen la viabilitat si la facturació triga a arribar.
• Per a un SaaS, la data d'inscripció concursal respecte a la data de constitució és un senyal que el model de finançament inicial (capital propi o deute) no cobria el període fins al primer ingrés rellevant; convé dimensionar la tresoreria per mesos reals de desenvolupament, no per expectatives comercials.
• La classificació sectorial "software i SaaS" és massa àmplia per avaluar risc: en l'anàlisi d'una societat nova cal exigir l'objecte social literal i el detall de producte abans de qualsevol valoració.
• Quan una societat entra en concurs el mateix any de constitució, la informació registral pública (BORME) és l'única font fiable disponible; els perfils comercials i les webs corporatives poden continuar actius i no reflectir la situació real.

El punt de partida honest és aquest: de Khaos Digital SL només sabem que era una societat de software i SaaS amb seu a València, constituïda el 2026 i declarada en situació concursal el 18 d'agost de 2026 [BORME/BOE via OpenMercantil, 2026-08-18]. No hi ha cap font pública disponible que ens digui quin producte venia, a qui, amb quins ingressos ni amb quina estructura.

Això té una conseqüència directa: no podem "reconstruir" el seu negoci. El que sí que podem fer és proposar un projecte nou que reculli l'essència raonable d'una empresa SaaS valenciana nascuda el 2026 —producte digital, equip petit, cost marginal baix— i dissenyar-lo perquè no repeteixi el patró que porta una SL de software a concursar en mesos.

La proposta (a validar, no verificada): un micro-SaaS vertical per a un nínxol concret de pimes de la Comunitat Valenciana, venut per subscripció anual, amb un sol producte i un sol canal. L'objectiu no és créixer ràpid sinó arribar a facturació recurrent abans de necessitar capital extern.

No tenim dades verificades del mercat que atenia Khaos Digital. El que sí que és comprovable és l'entorn: València té un ecosistema tecnològic actiu (universitats, parcs tecnològics, clústers digitals) i un teixit dens de pimes i micropimes que consumeixen programari de gestió. Aquest és el mercat genèric on encaixaria la proposta.

La tesi de mercat (estimació, a validar amb recerca primària): hi ha espai per a eines verticals petites que resolguin un problema molt concret d'un sector (per exemple, gestió de comandes, traçabilitat, facturació específica o comunicació amb clients) millor que un ERP generalista. El nínxol concret s'ha de triar amb 20-30 entrevistes a pimes reals abans d'escriure codi.

Model proposat (no verificat, és disseny nou):

• Subscripció SaaS mensual o anual per compte, amb preu baix (rang estimat de 30-150 €/mes segons el nínxol; a validar amb el mercat).
• Un pla únic o dos com a màxim, per reduir complexitat comercial.
• Autoservei amb onboarding assistit els primers mesos; vendes per canal directe i per partenariat amb gestories o associacions sectorials.
• Cost marginal baix per client; l'objectiu és que el marge brut se situï per sobre del 70% (estimació estàndard del sector, a validar).

El que no faríem: vendre serveis a mida barrejats amb producte, ni dependre d'un sol client gran. Aquests són patrons habituals de fracàs en SaaS primerenc, però no podem afirmar que fossin la causa del concurs de Khaos Digital: no hi ha informació pública que ho confirmi.

Fases proposades (a validar):

1. Mesos 0-2 — Validació. 20-30 entrevistes a pimes del nínxol triat, definició del problema i del preu disposat a pagar. Cost: temps, no diners.
2. Mesos 2-5 — Prototip. MVP funcional amb un sol flux de valor. Objectiu: 3-5 clients pilots, encara que sigui gratuït o amb descompte.
3. Mesos 5-9 — Primers ingressos. Conversió de pilots a subscripció de pagament; primera mètrica de retenció. Objectiu orientatiu: 10-20 clients de pagament (estimació, a validar).
4. Mesos 9-18 — Repetibilitat. Canal de captació estable, contractació del primer perfil comercial o de suport, i decisió sobre aixecar capital o créixer amb caixa.

Xifres estimades, no verificades, per a un equip de 1-3 persones a València:

• Desenvolupament i infraestructura: 0-15.000 € el primer any si el fundador programa; 40.000-70.000 € si es subcontracta (rang estimat).
• Legal i constitució: 1.000-3.000 € (estimació), incloent constitució de SL, estatuts i assessoria inicial.
• Màrqueting i vendes inicials: 3.000-10.000 € el primer any (estimació).
• Costos d'equip: si hi ha dos fundadors a temps complet, 40.000-70.000 € anuals de cost d'oportunitat o sous (estimació).
• Total orientatiu per arrencar amb un MVP i arribar a primers clients: rang de 15.000 a 60.000 € segons si es paga equip o no (estimació, a validar amb pressupostos reals).

• Risc de validació: construir producte sense haver confirmat que algú el paga. És el risc número u en SaaS primerenc.
• Risc de caixa: una SL de software pot cremar diners mesos abans del primer ingrés recurrent. Cal un coixí de 6-12 mesos (estimació).
• Risc de concentració: dependre de pocs clients o d'un sol canal.
• Risc de governança: el cas de Khaos Digital mostra que una SL pot arribar a situació concursal molt ràpidament [BORME/BOE via OpenMercantil, 2026-08-18]; no sabem per què, i per tant no podem descartar causes que vagin des de manca de finançament fins a problemes entre socis. Aquesta incertesa és, en si mateixa, un motiu per dissenyar el nou projecte amb reserves i amb comptes clars des del dia u.

Les lliçons que es poden extreure de l'expedient original són poques i cal no exagerar-les: una societat de software constituïda i concursada el mateix any indica que la velocitat de constitució no garanteix viabilitat, i que la inscripció al BORME és el rastre públic mínim que deixa un fracàs. La lliçó operativa és que qualsevol projecte nou ha de néixer amb validació de mercat abans de despesa, amb caixa controlat i amb una estructura societària simple.

Qui ho hauria de fer: un equip fundador petit (1-3 persones) amb capacitat tècnica i comercial, arrelat a València o amb accés al seu teixit de pimes, disposat a validar abans de construir i a operar amb pressupost ajustat. No recomanem replicar l'estructura de Khaos Digital perquè no en coneixem el detall; recomanem començar de nou amb les precaucions descrites.

Un creditor, un proveïdor o un equip de compres descobreix que un client o contrapart està en situació concursal quan ja és tard: la informació existeix al BORME, però arriba en un butlletí diari en text pla, sense estructura, sense historial per empresa i sense cap mecanisme d'alerta. La ficha registral de KHAOS DIGITAL a OpenMercantil (BORME, 2026-08-18) n'és l'exemple: l'acte «Situación concursal» és públic i datat, però ningú no el rep com a senyal accionable el mateix dia.

El producte resol tres coses concretes: (1) convertir publicacions registrals en esdeveniments estructurats i consultables per CIF/nom; (2) avaluar aquests esdeveniments amb regles de risc explícites i versionades; (3) notificar els subscriptors que segueixen una empresa o un sector quan es creua un llindar. No pretén predir la fallida: pretén reduir el temps entre la inscripció d'un acte i la reacció de qui hi té exposició.

Arquitectura en quatre etapes, desacoblada per cues, amb un principi: cap dada sense procedència. Cada registre persistit porta `source_id`, `source_url`, `published_at` i `ingested_at`.

``` [BORME/BOE + OpenMercantil] │ (fetch diari, ETag/If-Modified-Since) ▼ [Ingester] ──► raw_documents (object storage, immutable) │ ▼ [Parser/Normalizer] ──► registry_events (Postgres) │ ▼ [Risk Engine] ──► risk_scores + risk_findings │ ▼ [Notifier] ──► alerts (email / webhook) │ ▼ [API + Web] ◄── clients ```

Decisions i motius:

• Postgres com a magatzem principal perquè el model és relacional (empreses, actes, subscripcions) i les consultes per CIF i per data són el cas d'ús dominant; no cal un motor de cerca dedicat fins que el volum ho justifiqui.
• Raw documents immutables a object storage perquè la defensa legal i l'auditoria exigeixen reproduir exactament què es va llegir i quan; el parser es pot re-executar sobre el cru si canvia la lògica.
• Cua entre etapes (Redis Streams o SQS) perquè un canvi de format al BORME no ha de tombar la ingesta ni les alertes: cada etapa falla i reintenta de manera independent.
• Motor de regles versionat en codi, no en base de dades, perquè les decisions de risc han de passar per revisió (pull request) i quedar traçables amb el commit que les va introduir.

Taules principals (Postgres):

```sql companies ( id uuid pk, cif text unique, -- pot ser null si la font no el publica legal_name text not null, normalized_name text, -- per deduplicar variants created_at timestamptz )

raw_documents ( id uuid pk, source_id text, -- 'borme', 'openmercantil' source_url text, fetched_at timestamptz, content_hash text unique, -- idempotència: no reingestar el mateix storage_key text -- objecte immutable )

registry_events ( id uuid pk, company_id uuid fk, raw_document_id uuid fk, event_type text, -- 'concurso', 'disolucion', 'cambio_administrador', ... event_date date, published_at timestamptz, payload jsonb, -- camps específics del tipus unique (company_id, event_type, event_date, raw_document_id) )

risk_rules ( id text pk, -- 'concurso_inscrito_v1' version int, severity smallint, -- 1..5 definition jsonb )

risk_findings ( id uuid pk, company_id uuid fk, rule_id text fk, fired_at timestamptz, evidence_event_ids uuid[] )

subscriptions ( id uuid pk, tenant_id uuid, target_type text, -- 'company' | 'sector' | 'cif_list' target_value text, channels jsonb -- {email: [...], webhook: url} )

alerts ( id uuid pk, subscription_id uuid fk, finding_id uuid fk, status text, -- 'pending' | 'sent' | 'failed' sent_at timestamptz ) ```

Motius: `content_hash` únic fa la ingesta idempotent davant de re-execucions; `evidence_event_ids` obliga que tota puntuació de risc apunti als actes que la justifiquen; `payload jsonb` permet afegir tipus d'acte sense migracions immediates.

API REST versionada (`/v1`), autenticació per clau d'API per tenant.

• `GET /v1/companies?cif=...` i `GET /v1/companies/{id}/events` — consulta d'historial registral amb `source_url` a cada event.
• `GET /v1/companies/{id}/risk` — puntuació actual, regles disparades i evidències.
• `POST /v1/subscriptions` — alta de seguiment per empresa, CIF o sector.
• `POST /v1/webhooks/test` — verificació d'endpoint.
• Webhook de sortida: `POST` a l'URL del client amb cos `{alert_id, company, finding, evidence[]}` i signatura HMAC-SHA256 a la capçalera `X-Khaos-Signature`; reintents amb backoff exponencial (1m, 5m, 30m, 2h, 12h) i dead-letter queue.

Integracions d'entrada: BORME/BOE via OpenMercantil (font citada: ficha registral de KHAOS DIGITAL, OpenMercantil/BORME 2026-08-18) i el portal del BOE. El connector ha de respectar `robots.txt`, fer servir ETag i limitar la freqüència; cada resposta es desa crua abans de parsejar.

1. Connector d'ingesta + `raw_documents`: descarregar el butlletí, desar-lo immutable i registrar hash. Sense això no hi ha res auditable.
2. Parser de l'acte «situación concursal» i d'altres actes bàsics cap a `registry_events`, amb tests sobre documents reals (incloent-hi el cas KHAOS DIGITAL com a fixture).
3. Motor de regles mínim amb una sola regla (`concurso_inscrito_v1`) i `risk_findings` amb evidències.
4. Notificació per correu per a subscripcions per CIF.
5. Només després: API pública, webhooks i UI.

Ordre motivat: el valor és l'alerta fiable; la UI sense pipeline és una maqueta. La regla única permet validar el circuit complet abans d'ampliar el catàleg.

• Volum: el BORME publica centenars d'anuncis diaris; l'ingesta diària cap en un sol worker amb cues, i Postgres aguanta anys d'historial sense particionar. El risc escala si s'afegeixen registres provincials.
• Risc de parsing: els formats del BORME canvien i el text és irregular. Mitigació: fixtures versionats, alerta quan la taxa de parseig falla per sobre d'un llindar, i quarantena de documents no interpretats en lloc de descartar-los.
• Fals positiu/negatiu en la identificació d'empreses: noms duplicats i CIF absents. Mitigació: `normalized_name` + revisió manual assistida i marcatge de confiança a l'event.
• Risc legal: redistribuir text registral pot tenir límits; es publica l'enllaç a la font i només extractes, no el butlletí sencer.
• Risc de producte: la mateixa empresa que es proposa va tancar en situació concursal el 2026; cal no confondre el senyal amb una garantia. La comunicació ha de dir explícitament que el servei informa d'actes inscrits, no prediu insolvències.

• Test d'idempotència: re-executar la ingesta del mateix dia no crea duplicats (`content_hash` únic).
• Test de traçabilitat: cada `risk_finding` retorna almenys un `registry_event` amb `source_url` resoluble; el cas KHAOS DIGITAL (BORME 2026-08-18) ha de generar un finding de severitat màxima.
• Test de latència d'alerta: des de la publicació simulada fins a l'enviament del correu en menys de 24 h en entorn de staging.
• Test de fallada parcial: si el parser falla, la ingesta es completa i el document queda en quarantena; cap alerta falsa s'envia.
• Validació amb usuaris: un grup pilot de compres/proveïdors rep alertes durant quatre setmanes i es mesura la taxa d'alertes considerades útils; per sota d'un llindar acordat, es revisen les regles abans de comercialitzar.