KHAOS DIGITAL SOCIEDAD LIMITADA

Khaos Digital Sociedad Limitada era una sociedad mercantil de responsabilidad limitada con domicilio en Valencia, clasificada dentro del sector del software y SaaS. De acuerdo con la ficha registral consultada en OpenMercantil a partir del BORME, la sociedad se constituyó en 2026 y ese mismo año quedó inscrita en situación concursal.

No consta en los datos disponibles ninguna otra información sobre el objeto social detallado, el capital, la plantilla o los productos de la empresa.

La sociedad se constituyó en 2026. No constan en los datos disponibles ni la fecha exacta de constitución, ni los socios fundadores, ni la escritura de constitución, ni el capital social inicial. Esta información se podría obtener consultando la ficha registral completa en el Registro Mercantil de Valencia o bien el BORME del día de la constitución.

La clasificación sectorial disponible la sitúa en el software y SaaS. No consta en los datos ninguna descripción de la actividad concreta, de los productos, de los clientes ni del modelo de negocio. Cualquier afirmación sobre qué vendía o a quién se dirigía sería una suposición y, por tanto, no se hace.

No consta ningún periodo de actividad próspera. La cronología registral disponible solo recoge la constitución en 2026 y la inscripción en situación concursal el 18 de agosto de 2026, dentro del mismo año. No hay datos de facturación, clientes ni crecimiento.

Según el BORME, el 18 de agosto de 2026 se inscribió la situación concursal de Khaos Digital Sociedad Limitada. La fuente registral no detalla en los datos disponibles el tipo de procedimiento concursal, la causa de la insolvencia ni el resultado final del procedimiento. No consta, por tanto, si se trata de un concurso voluntario o necesario, ni si la sociedad ha sido disuelta o liquidada.

No consta en los datos ninguna información sobre activos, propiedad intelectual, cartera de clientes, marca o código fuente que haya podido sobrevivir a la situación concursal. La ficha registral consultada no recoge transmisiones ni operaciones posteriores.

No consta en los datos el nombre de ningún fundador ni de ningún administrador de la sociedad. Para identificarlos y conocer su situación actual habría que consultar la ficha completa del Registro Mercantil de Valencia (nombramientos y ceses de administradores) y el BORME de los actos societarios. Con la información disponible no se puede decir nada sobre las personas que había detrás.

• En una sociedad de software constituida y concursada dentro del mismo año, el primer indicador a vigilar no es el crecimiento sino la ratio de gasto fijo comprometido antes de tener ingresos recurrentes: los contratos de servicios cloud, licencias y sueldos firmados en la constitución determinan la viabilidad si la facturación tarda en llegar.
• Para un SaaS, la fecha de inscripción concursal respecto a la fecha de constitución es una señal de que el modelo de financiación inicial (capital propio o deuda) no cubría el periodo hasta el primer ingreso relevante; conviene dimensionar la tesorería por meses reales de desarrollo, no por expectativas comerciales.
• La clasificación sectorial "software y SaaS" es demasiado amplia para evaluar riesgo: en el análisis de una sociedad nueva hay que exigir el objeto social literal y el detalle de producto antes de cualquier valoración.
• Cuando una sociedad entra en concurso el mismo año de constitución, la información registral pública (BORME) es la única fuente fiable disponible; los perfiles comerciales y las webs corporativas pueden seguir activos y no reflejar la situación real.

No tenim dades verificades sobre quin producte feia KHAOS DIGITAL SL. L'únic que sabem del cert és el sector (software i SaaS), la ubicació (València) i que va concursar el 2026, el mateix any de constituir-se [BORME/BOE via OpenMercantil, 2026-08-18]. Aquesta cronologia tan curta és, en si mateixa, la lliçó més important: una SL de software que neix i concursa en mesos normalment indica que es va muntar amb costos fixos (sou propi, oficina, equip) abans de tenir ingressos recurrents.

La proposta, doncs, no és "refer KHAOS", sinó construir avui un SaaS de nínxol amb l'essència del que hauria pogut ser: producte digital, mercat B2B, equip mínim, des de València. Concretament, proposo (marcat com a proposta meva, no dada de l'empresa) un micro-SaaS vertical per a un sector local fort — per exemple, gestió de quotes i comunicacions per a clubs esportius, acadèmies o col·legis professionals—, venut per subscripció mensual.

El mercat rellevant no és "SaaS" en abstracte, sinó el nínxol concret que triïs. Dades de mercat específiques de KHAOS DIGITAL SL: no n'hi ha de verificades. El que sí que és verificable i rellevant:

• València té un ecosistema tecnològic actiu (universitats, parcs tecnològics, associacions d'startups), cosa que facilita trobar primers clients i talent.
• El mercat de micro-SaaS B2B per a pimes i entitats petites a Espanya és gran i fragmentat; la competència és local i sovint amb eines obsoletes.

Qualsevol xifra de mida de mercat que et doni aquí seria inventada. Cal validar-la amb: nombre d'entitats objectiu a la Comunitat Valenciana, quantes paguen ja per una eina similar, i quin preu aguanten. Això és feina de les primeres 2-3 setmanes, no d'aquest informe.

Proposta (no dada verificada):

• Ingressos: subscripció mensual per entitat (no per usuari, per simplificar la venda a entitats petites). Rang estimat a validar: 29–99 €/mes segons mida del client.
• Cost d'adquisició: venda directa i referències; res de màrqueting de pagament fins a tenir 10 clients.
• Estructura de costos: gairebé tota variable o mínima — allotjament cloud, eines, i hores del fundador. Aquesta és precisament la correcció respecte al que probablement va matar KHAOS: no comprometre costos fixos fins que hi hagi ingressos recurrents.
• Objectiu mínim viable: 20–30 clients de pagament per cobrir costos i un sou modest de fundador (estimació a validar amb els preus reals que aconsegueixis).

Proposta, en fases:

1. Setmanes 1–3 — Validació: 15–20 entrevistes amb entitats objectiu. Pregunta clau: què paguen avui i per què. Sense producte.
2. Setmanes 3–8 — Prototip: versió mínima que resolgui un problema (p. ex. cobrament de quotes). 3–5 clients pilot, encara gratuïts o a preu reduït.
3. Mesos 3–5 — Primers ingressos: convertir pilots en subscripcions. Objectiu estimat: 5–10 clients de pagament.
4. Mesos 5–12 — Repetició: créixer per referències fins a 20–30 clients; només llavors plantejar contractar o fer societat.

Nota important: no constituir la SL fins a la fase 3. KHAOS es va constituir i concursar el mateix any; operar com a autònom o en fase de prova redueix el risc formal i els costos.

Totes les xifres són estimacions meves, a validar:

• Cost de validació (fases 1–2): 0–500 € (eines, domini, allotjament bàsic). El cost real és temps del fundador.
• Cost de prototip i primers clients: rang estimat de 1.000–3.000 € en eines, allotjament i algun servei extern.
• Cost de constituir la SL (si s'arriba a la fase 3): rang estimat de 600–1.500 € entre notaria, registre i gestoria inicial; més el capital social mínim (3.000 € en SL, avui sovint amb constitució telemàtica reduïda — a confirmar amb gestor).
• Cost de vida del fundador: la part que mata més projectes. Cal comptar 12 mesos de despesa personal coberta d'alguna manera (estalvi, feina a temps parcial). Estimar-la tu; no la invento.

Total orientatiu per arribar a primers ingressos: rang estimat de 2.000–5.000 € més el cost de vida del fundador. Molt per sota del que sol implicar muntar una SL amb equip des del dia u.

• El risc que va matar KHAOS: costos fixos abans d'ingressos. És el risc número u i el que aquest pla intenta eliminar.
• Risc de nínxol equivocat: si les entitats objectiu no paguen o no tenen dolor real, tot cau. Per això la fase 1 és entrevistes, no codi.
• Risc de fundador sol: vendre, construir i donar suport alhora és lent; cal acceptar-ho o buscar un soci complementari.
• Risc legal/fiscal: operar sense SL té límits de responsabilitat; constituir-la massa aviat té costos. El moment de la constitució és una decisió a consultar amb un gestor.
• Risc de dades: si el producte toca dades de clients (quotes, socis), cal complir RGPD des del primer dia.

Les lliçons que es poden extreure del cas original (l'únic fet verificat: constitució i concurs el 2026 [BORME/BOE via OpenMercantil, 2026-08-18]):

1. Constituir una SL no és començar un negoci; és un cost. KHAOS va existir formalment molt poc temps. Valida primer, constitueix després.
2. En SaaS, l'ingrés recurrent és l'única prova de vida. Sense clients que paguen cada mes, no hi ha negoci, només producte.
3. Els costos fixos són el verí dels projectes joves. Equip mínim, oficina zero, eines barates fins a tenir tracció.
4. València és una bona base, però el mercat és el client, no la ciutat. El nínxol i el primer client valen més que l'ecosistema.
5. Qui ho hauria de fer: una persona (o dues) amb capacitat de vendre i construir, disposada a passar 3 mesos validant abans d'escriure codi seriós, i amb 12 mesos de coixí personal. No cal un equip gran ni inversió externa per començar; cal disciplina de costos i proximitat al client.

Aquest informe no reconstrueix KHAOS DIGITAL SL —no hi ha dades públiques verificades sobre el seu producte o clients— sinó que proposa, amb lliçons del seu cas, què es podria construir avui amb la mateixa essència.

Quan una empresa de software tanca —com KHAOS DIGITAL, SL, en situació concursal inscrita al BORME el 2026-08-18 [BORME / BOE via OpenMercantil, 2026-08-18]— el codi pot sobreviure (repositoris, contractes, adquisicions) però el raonament que el sosté desapareix amb l'equip. Els qui hereten el codi es troben amb decisions òrquenes: per què aquesta base de dades, per què aquesta cua, per què aquesta excepció al desplegament.

El producte és un registre de decisions d'arquitectura (ADR) vinculat al codi i amb valor probatori: cada decisió té autor, data, alternatives descartades i estat, i queda segellada de manera que no es pot reescriure la història. No és un wiki: és un log append-only amb verificació criptogràfica i exportació portable.

El motiu de fer-ho així: un wiki es podreix i no és auditable; un fitxer `docs/adr/` al repo es perd quan el repo es migra o es fa privat. La traçabilitat ha de viure fora del codi però apuntar-hi per hash.

Tres components, tots desplegables en un sol VPS o en un proveïdor de contenidors:

1. API de decisions (Node.js + Fastify + PostgreSQL). És l'única via d'escriptura. Cada escriptura genera una entrada encadenada per hash (estil hash chain): `hash_n = SHA256(hash_{n-1} || payload_canònic)`. Motiu: permet detectar manipulació retroactiva sense necessitat de blockchain ni de tercers.
2. Worker d'ancoratge (procés separat, cron cada hora). Agafa el hash de capçalera de la cadena i el publica en un registre extern barat: un fitxer a un bucket object storage amb object lock i, opcionalment, un timestamp RFC 3161 d'una TSA. Motiu: separar el càlcul de l'ancoratge evita que un compromís de l'API reescrigui també l'evidència externa.
3. Connector de repositoris (GitHub App / GitLab webhook). Quan es fa merge a `main`, llegeix els fitxers `adr/.md` del repo, en calcula el hash i el vincula a la decisió corresponent. Motiu: el codi és la font de veritat de què s'ha construït; l'ADR és la font de veritat de per què*.

Flux d'una escriptura:

``` client -> POST /v1/decisions -> validació d'esquema (JSON Schema) -> BEGIN tx SELECT hash_cap FROM chain FOR UPDATE (serialitza escriptures) calcula hash_n INSERT decision + INSERT chain_link -> COMMIT -> encua ancoratge (outbox table) worker -> llegeix outbox -> puja hash a bucket amb object lock ```

El patró outbox a la base de dades és deliberat: garanteix que no es perd cap ancoratge si el worker cau, sense necessitat de cues externes.

PostgreSQL. Taules principals:

```sql -- Decisió d'arquitectura CREATE TABLE decisions ( id uuid PRIMARY KEY DEFAULT gen_random_uuid(), project_id uuid NOT NULL REFERENCES projects(id), slug text NOT NULL, -- "0012-usar-postgres" title text NOT NULL, status text NOT NULL CHECK (status IN ('proposed','accepted','deprecated','superseded')), context text NOT NULL, decision text NOT NULL, consequences text NOT NULL, supersedes_id uuid REFERENCES decisions(id), author_id uuid NOT NULL REFERENCES users(id), created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (project_id, slug) );

-- Alternativa descartada (1..n per decisió) CREATE TABLE alternatives ( id uuid PRIMARY KEY DEFAULT gen_random_uuid(), decision_id uuid NOT NULL REFERENCES decisions(id) ON DELETE RESTRICT, label text NOT NULL, rationale text NOT NULL );

-- Cadena d'integritat (append-only) CREATE TABLE chain_links ( seq bigint PRIMARY KEY, -- seqüencial, no uuid decision_id uuid NOT NULL REFERENCES decisions(id), prev_hash bytea NOT NULL, payload_hash bytea NOT NULL, -- SHA256 del payload canònic hash bytea NOT NULL UNIQUE );

-- Ancoratges externs CREATE TABLE anchors ( id uuid PRIMARY KEY DEFAULT gen_random_uuid(), seq bigint NOT NULL REFERENCES chain_links(seq), target text NOT NULL, -- 's3://...' | 'rfc3161:...' external_ref text NOT NULL, created_at timestamptz NOT NULL DEFAULT now() );

-- Vincle amb codi CREATE TABLE code_links ( id uuid PRIMARY KEY DEFAULT gen_random_uuid(), decision_id uuid NOT NULL REFERENCES decisions(id), repo text NOT NULL, commit_sha text NOT NULL, file_path text NOT NULL, file_hash bytea NOT NULL ); ```

Decisions de model i el seu motiu:

• `seq bigint` a `chain_links` en lloc d'UUID: l'ordre de la cadena és semàntic i ha de ser dens i ordenable; els UUID trencarien la seqüència llegible.
• `ON DELETE RESTRICT` a `alternatives`: no es pot esborrar una decisió que té alternatives registrades; s'ha de marcar `deprecated`. Motiu: preservar la memòria.
• `payload_hash` separat de `hash`: permet verificar el contingut sense recalcular tota la cadena.
• Sense `updated_at` a `decisions`: les correccions es fan creant una decisió nova que substitueix l'anterior (`supersedes_id`). Motiu: un registre que es pot editar no és un registre.

REST, versionat a `/v1`, autenticació per token d'API per projecte (Bearer) i OAuth per a usuaris humans.

• `POST /v1/projects/{id}/decisions` — crea decisió; retorna `{id, seq, hash}`.
• `GET /v1/projects/{id}/decisions?status=accepted` — llistat paginat per cursor (`seq`).
• `GET /v1/decisions/{id}` — detall amb alternatives i vincles de codi.
• `POST /v1/decisions/{id}/supersede` — crea la successora i marca l'original.
• `GET /v1/projects/{id}/verify` — recalcula la cadena i retorna `{valid: bool, broken_at_seq?: n}`.
• `GET /v1/projects/{id}/export?format=json|tar` — exportació portable completa (decisió + cadena + ancoratges). Motiu: el producte ha de permetre marxar; si l'empresa tanca, el client ha de poder endur-se l'evidència.

Integracions:

• GitHub App / GitLab: webhook `push` a la branca per defecte; el connector llegeix `adr/*.md`, valida front-matter i crida `POST .../code-links`.
• TSA RFC 3161: opcional, per a clients que necessiten segell de temps qualificat.
• Webhook de sortida: notifica canvis d'estat a Slack/Teams.

Errors: `409` si el `slug` existeix, `422` si l'esquema falla, `423` si es detecta trencament de cadena (el projecte passa a només lectura fins a intervenció manual). Aquest darrer codi és una decisió de seguretat: davant d'integritat dubtosa, es congela l'escriptura.

Fase 1 (MVP, ~6 setmanes): API de decisions + cadena d'hash + `verify` + export JSON. Sense connector de repositoris ni ancoratge extern. Motiu: el nucli de valor és la immutabilitat verificable; la resta són comoditats.

Fase 2: connector GitHub, ancoratge a object storage amb object lock, webhooks de sortida.

Fase 3: TSA RFC 3161, exportació `tar` signada, panell de lectura pública per a codi heretat (un "llegeix el per què" sense compte).

Criteri de tall per passar de fase: la fase 1 no es considera acabada fins que `verify` detecta correctament una manipulació simulada en test d'integració.

Mides: un equip de 2-3 persones; ~4.000 línies de codi per al nucli. Cost d'infraestructura baix (un Postgres gestionat + un bucket + un contenidor).

Riscos:

• Serialització d'escriptures: el `SELECT ... FOR UPDATE` sobre la capçalera limita el throughput a unes desenes d'escriptures per segon. Acceptable per a l'ús previst (decisions, no esdeveniments). Si calgués, es particiona la cadena per projecte —de fet, la cadena ja és per projecte, cosa que elimina el coll d'ampolla global.
• Pèrdua de la clau d'ancoratge: si el bucket extern es perd, la cadena interna encara es pot verificar localment però perd valor probatori extern. Mitigació: replicar l'ancoratge a dos proveïdors.
• Adopció: el risc real no és tècnic sinó de disciplina; si l'equip no escriu ADRs, el producte no serveix. Mitigació: el connector pot fallar el CI si un PR toca `src/core/` sense un ADR vinculat (mode estricte opcional).
• Compliment: no és un producte de compliment normatiu; no s'ha de vendre com a tal.

1. Test d'integritat: suite que crea N decisions, manipula una fila directament a la BD i comprova que `GET /verify` retorna `valid:false` amb el `seq` correcte.
2. Test de concurrència: 50 escriptures paral·leles; la cadena resultant ha de ser densa i verificable.
3. Test d'exportació: exportar, esborrar el projecte, reimportar en una instància neta i verificar que la cadena es reconstrueix idèntica.
4. Pilot amb un equip real: 4 setmanes, mínim 20 decisions registrades i un `verify` setmanal. Mètrica d'èxit: el 100% de les decisions tenen almenys una alternativa descartada (senyal que s'usa per pensar, no per complir).
5. Validació del cas "empresa tancada": simular el tancament —revocar tots els accessos— i comprovar que un tercer amb només l'exportació pot verificar la cadena i llegir el per què. Aquest és el criteri final: el producte ha de sobreviure al seu client.