INFORMATICA Q SL

INFORMATICA Q SL era una sociedad mercantil española con domicilio en Madrid, clasificada dentro del sector del software y SaaS. Su razón social consta como INFORMATICA Q SL.

Según la ficha registral publicada en OpenMercantil a partir del BORME, la sociedad se constituyó en el año 2026 y ese mismo año quedó inscrita en situación concursal. Se trata, por tanto, de una compañía de vida registral muy corta: no consta que llegara a operar de manera sostenida antes de la apertura del concurso.

De acuerdo con el registro, la constitución de la sociedad se produjo en el año 2026. Los datos disponibles no incluyen la fecha exacta de la escritura de constitución, el importe del capital social, la forma de constitución (simultánea o sucesiva) ni la identidad de los socios fundadores.

Tampoco consta en la documentación consultada cuál era la estructura accionarial inicial ni si hubo ampliaciones de capital o entradas de inversores antes de la declaración de concurso.

La clasificación sectorial disponible sitúa a la empresa en el ámbito del software y SaaS. Más allá de esta adscripción genérica, no consta qué producto o servicio concreto ofrecía, qué modelo de negocio tenía (suscripción, licencia, servicios profesionales), a qué segmento de clientes se dirigía ni qué dimensión de facturación o plantilla alcanzó.

Dada la cronología registral —constitución y concurso dentro del mismo año 2026—, no hay constancia de que la empresa hubiera consolidado una cartera de clientes o una actividad comercial estable antes de la insolvencia.

No consta ningún período de actividad próspera. La secuencia registral disponible muestra una constitución en 2026 y una inscripción de situación concursal el 21 de agosto de 2026, sin que los datos permitan identificar ejercicios con resultados positivos, crecimiento de clientes o hitos comerciales.

La única información verificada es que, según el BORME (ficha en OpenMercantil, 21 de agosto de 2026), la sociedad quedó inscrita en situación concursal. El registro no detalla en la información disponible la causa de la insolvencia, el importe del pasivo, la identidad de los acreedores ni si el concurso derivó en liquidación.

No consta, por tanto, si el concurso fue consecuencia de una falta de financiación, de un producto que no encontró mercado, de costes superiores a los ingresos o de otros factores. Cualquier afirmación en este sentido sería una suposición no respaldada por las fuentes.

No consta que la sociedad dejara ningún activo relevante, producto en funcionamiento, cartera de clientes o propiedad intelectual transferida a terceros. La información registral disponible no incluye el resultado del procedimiento concursal ni eventuales operaciones de venta de activos.

Los datos disponibles no identifican a los fundadores ni a los administradores de la sociedad, de modo que no consta cuál es su situación actual ni si han impulsado otros proyectos.

Para completar esta información se podría consultar la ficha completa de la sociedad en el Registro Mercantil de Madrid, la certificación de actos registrales (nombramientos y ceses de administradores) y el Registro Público Concursal, que recoge la identidad del administrador concursal y el estado del procedimiento.

• En el sector del software y SaaS, el ciclo entre constitución y primera facturación recurrente puede ser largo; una sociedad que nace y concursa dentro del mismo año sugiere que habría que verificar, en casos similares, si el plan de financiación cubría el período previo a la llegada de ingresos recurrentes.
• La inscripción concursal en el BORME es el primer dato público fiable sobre la salud de una sociedad de nueva creación; para un analista, la fecha de constitución y la fecha de concurso son dos indicadores objetivos que permiten medir la duración real del proyecto sin depender de la narrativa de la empresa.
• Cuando una compañía tecnológica concursa muy pronto, la información relevante para entender qué falló (capital inicial, socios, acreedores) se encuentra en el Registro Mercantil y en el Registro Público Concursal, no en la nota de prensa; conviene consultarlos antes de sacar conclusiones sobre las causas.

L'única cosa que sabem del cert és el que diu el registre: INFORMATICA Q SL es va constituir el 2026 i el 21 d'agost de 2026 ja tenia una situació concursal inscrita al BORME [BORME/BOE via OpenMercantil, 2026-08-21]. És a dir, una societat de software/SaaS madrilenya que va cremar el marge de maniobra en mesos. No tenim dades verificades del producte, dels clients, dels ingressos ni de la causa concreta del concurs.

Per tant, la reconstrucció que proposo és una proposta, no una continuació documentada: un micro-SaaS vertical de facturació, despeses i gestió bàsica per a pimes i autònoms, venut per subscripció mensual i amb un abast deliberadament estret (un nínxol, no "software de gestió per a tothom"). La lògica és simple: el sector SaaS permet arrencar amb equip mínim i cost marginal baix, i el mercat espanyol de facturació electrònica i gestió per a autònoms té pressió reguladora i demanda recurrent.

El que no proposo és replicar l'estructura anterior, perquè no la coneixem i perquè el resultat registral (concurs en mesos) suggereix que el model original no era sostenible amb els recursos disponibles.

El mercat de software de facturació i gestió per a pimes i autònoms a Espanya és gran, madur i molt competitiu: hi ha actors consolidats de facturació, gestió comptable i programari de gestoria, i una capa creixent d'eines verticals per sector (hostaleria, clíniques, tallers, etc.).

La demanda existeix i és recurrent: els autònoms i les microempreses necessiten facturar, quadrar despeses i complir obligacions fiscals. La pressió reguladora (facturació electrònica, digitalització de la relació amb l'administració) genera finestres d'oportunitat per a eines noves, però també obliga a mantenir el producte actualitzat, cosa que té cost.

Estimació (a validar): un nínxol vertical concret (per exemple, un subsector d'autònoms amb necessitats de facturació específiques) pot tenir entre uns pocs milers i desenes de milers d'usuaris potencials a Espanya. Aquesta xifra és una hipòtesi de treball, no una dada verificada, i s'ha de contrastar amb recerca de mercat abans de construir res.

Proposta: subscripció SaaS mensual per compte, amb un pla bàsic i un pla professional, i un complement opcional de serveis (suport prioritari, integracions, migració de dades).

• Ingressos: quota mensual recurrent per usuari o per compte, més ingressos puntuals d'alta i migració.
• Costos: infraestructura cloud (baixa), desenvolupament i manteniment (el cost principal), suport, compliment normatiu i màrqueting.
• Mètrica clau: retenció mensual i cost d'adquisició de client. En un micro-SaaS, la rendibilitat depèn gairebé tota de la retenció.

Estimació (a validar): amb un preu de 10–30 €/mes per compte i un objectiu de 300–800 comptes actius, l'ingrés recurrent podria situar-se en un rang d'uns 3.000–24.000 €/mes. Són xifres il·lustratives per dimensionar el model, no previsions.

Fase 1 — Validació (0–3 mesos). Entrevistes amb 20–30 autònoms i pimes del nínxol triat, prototip de baixa fidelitat i llista d'espera. Cost baix, sense producte complet. Objectiu: confirmar que el problema és prou dolorós per pagar.

Fase 2 — Producte mínim (3–9 mesos). Construir només el nucli (facturació, despeses, exportació per a la gestoria), amb un sol canal d'adquisició (per exemple, col·laboració amb gestories o comunitats del nínxol). Objectiu: primers 50–100 clients de pagament.

Fase 3 — Escalat controlat (9–18 mesos). Iterar sobre retenció, afegir integracions i ampliar el canal de màrqueting només si la unitat econòmica funciona. Contractar només quan el flux de caixa ho permeti.

La lliçó del registre és clara: la societat original va arribar al concurs en mesos. Això obliga a un pla on cada fase tingui un criteri d'aturada explícit (si no es compleixen les mètriques, no es passa a la següent).

Estimació (rang, a validar): 15.000–40.000 € per cobrir els primers 9–12 mesos, amb un equip mínim (1–2 persones fundadores i col·laboradors puntuals). Desglossament orientatiu:

• Infraestructura i eines: 100–300 €/mes.
• Desenvolupament: el cost principal; pot ser temps dels fundadors o 8.000–25.000 € si es subcontracta.
• Màrqueting i vendes inicials: 2.000–6.000 €.
• Lleis, compliment i constitució: 1.000–3.000 €.
• Marge de seguretat: 20–30% del total.

Aquestes xifres són una estimació de consultor, no una dada verificada de l'empresa original.

• Risc de mercat: el nínxol pot no tenir prou disposició a pagar; cal validar-ho abans de construir.
• Risc de competència: els actors consolidats poden cobrir el nínxol amb poc esforç.
• Risc regulatori: canvis en facturació electrònica o obligacions fiscals poden exigir desenvolupament no previst.
• Risc financer: el precedent verificat és un concurs en mesos; qualsevol pla ha de tenir un coixí de caixa i criteris d'aturada.
• Risc de govern: no sabem per què va fallar l'original; si la causa va ser de gestió o de societat, cal assegurar que la nova estructura no repeteixi el patró.

Aquest informe no és un currículum ni una recomanació de persones concretes. El que es desprèn de la dada verificada —concurs inscrit al BORME el 2026-08-21, pocs mesos després de la constitució— és una lliçó de mètode:

1. Validar abans de construir. La dada registral no diu què va fallar, però un cicle tan curt obliga a no comprometre recursos grans sense proves de demanda.
2. Estructura lleugera i reversible. Costos fixos baixos i decisions reversibles fins que la unitat econòmica estigui provada.
3. Criteris d'aturada explícits. Cada fase amb mètriques i un punt de no-retorn definit per endavant.
4. Transparència sobre el que no se sap. La reconstrucció ha de distingir sempre entre dada verificada (el concurs) i proposta (el producte, el mercat, els números).

Qui ho faci hauria de ser algú amb capacitat tècnica per construir el producte mínim i capacitat comercial per parlar amb el nínxol, o un equip petit que combini les dues coses.

El cas d'INFORMATICA Q SL il·lustra el forat: una societat es constitueix el 2026 i el 2026-08-21 ja té una Situación concursal inscrita al BORME [BORME / BOE (via OpenMercantil), 2026-08-21]. Entre la constitució i el concurs no hi ha cap senyal públic estructurat que un proveïdor pugui consultar de forma automatitzada; l'única font és la ficha registral a OpenMercantil, que cal anar a mirar manualment.

El problema concret que resol Vigia és la latència d'informació: qui ven a crèdit a una SL descobreix el concurs quan deixa de cobrar, no quan es publica al BORME. No resolem el risc de crèdit (això és un model financer), resolem la detecció i el lliurament del senyal registral amb traçabilitat de la font.

Tres components, tots justificats per la naturalesa de la font:

1. Ingestor de fonts registrals. Un job programat que consulta periòdicament les fonts disponibles (BORME via OpenMercantil i, si s'obté accés, el propi BORME/BOE) i descarrega les fitxes i els anuncis. Motiu: les fonts són públiques però no ofereixen webhooks; el polling és l'única via fiable i és barat a la freqüència que necessitem (diària o cada poques hores).
2. Normalitzador + magatzem d'esdeveniments. Converteix cada publicació en un esdeveniment immutable amb data, tipus (constitució, concurs, canvi d'administrador, etc.), identificador fiscal i URL de la font. Motiu: volem un registre append-only auditable; si una alerta és qüestionada, hem de poder mostrar exactament quina publicació la va originar.
3. Motor de subscripcions i alertes. Cada client subscriu un conjunt d'empreses (per NIF) i un conjunt de tipus d'esdeveniment. Quan arriba un esdeveniment que encaixa, s'envia una notificació (email/webhook) amb la cita de la font. Motiu: el valor no és la dada, és el match entre dada i interès del client.

Flux:

``` [cron diari] -> Ingestor -> descarrega fitxes/anuncis | v Normalitzador -> events (append-only) | v Motor de subscripcions -> email / webhook | v Registre d'enviaments (auditoria) ```

No hi ha ML ni scoring en la v1; un score sense dades històriques (tenim una sola empresa al dataset) seria inventat.

Entitats mínimes, totes amb `created_at` i traçabilitat de font:

• `company`: `nif` (PK), `name`, `registry_id`, `status`, `first_seen_at`, `last_seen_at`.
• `source_document`: `id`, `source` (`openmercantil`|`borme`), `url`, `fetched_at`, `raw_hash`. Motiu: `raw_hash` permet detectar canvis i evitar duplicats.
• `event`: `id`, `nif`, `type` (`constitution`|`insolvency`|`dissolution`|`officer_change`), `effective_date`, `published_at`, `source_document_id`, `payload_json`. Immutable.
• `subscription`: `id`, `account_id`, `nif`, `event_types[]`, `channel`, `active`.
• `delivery`: `id`, `subscription_id`, `event_id`, `sent_at`, `status`.

Exemple d'esdeveniment per al cas real:

```json { "nif": "<NIF d'INFORMATICA Q SL>", "type": "insolvency", "effective_date": "2026-08-21", "source": "openmercantil", "url": "https://openmercantil.es/empresa/informatica-q-sl-b01104488" } ```

• API REST interna (p. ex. `GET /companies/{nif}/events`, `POST /subscriptions`) per al panell i per a clients tècnics.
• Webhook sortint signat amb HMAC perquè el client verifiqui autenticitat. Motiu: les alertes de risc s'integren en eines de compres/ERP, no en un portal web.
• Integració d'entrada: OpenMercantil (HTML/JSON si n'ofereix) i BORME/BOE. Cal respectar `robots.txt` i límits de taxa; per això el polling és diari i no en temps real.
• Email transaccional com a canal per defecte.

1. Ingestor d'OpenMercantil + `source_document` amb `raw_hash` (validat contra la ficha real d'INFORMATICA Q SL).
2. Normalitzador que produeixi `event` de tipus `insolvency` i `constitution`.
3. Subscripció per NIF + enviament per email amb la URL de la font al cos.
4. Panell mínim de lectura d'esdeveniments per NIF.

Tot això és construïble amb una sola font i un sol cas de prova: la ficha d'INFORMATICA Q SL serveix de fixture de test de punta a punta.

• Risc de font única: si OpenMercantil canvia el format o bloqueja l'accés, el producte s'atura. Mitigació: capa d'adaptadors per font i alerta interna si un job falla dos cops seguits.
• Risc legal: raspat de dades públiques és legítim, però cal revisar condicions d'ús i no redistribuir fitxes senceres; només esdeveniments i cites.
• Risc de fals positiu: un `insolvency` registral no equival a impagament; el copy ha de dir "situació concursal inscrita", no "empresa en fallida".
• Mida: v1 és un servei petit (un cron, una BD relacional, un worker d'email); no cal infraestructura distribuïda.
• Cobertura: amb una sola empresa no hi ha estadística; el producte ha de comunicar-se com a detecció, no com a predicció.

• Test de punta a punta amb dades reals: carregar la ficha d'INFORMATICA Q SL [BORME / BOE (via OpenMercantil), 2026-08-21] i comprovar que es genera un `event` `insolvency` amb `effective_date` 2026-08-21 i que una subscripció a aquest NIF rep l'email amb la URL correcta.
• Test d'idempotència: reingerir la mateixa ficha no ha de crear un segon `event` (gràcies a `raw_hash`).
• Test de traçabilitat: cada `delivery` ha de poder resoldre's fins a un `source_document` amb URL vàlida.
• Criteri d'acceptació: per a qualsevol alerta enviada, un revisor humà pot obrir la URL citada i veure-hi la publicació que la justifica.