TECNOTRAMIT GESTION SL

Tecnotramit Gestión SL era una sociedad mercantil con domicilio en Barcelona, constituida en el año 2012 y adscrita al sector del software y SaaS. El capital social consta en 6.700 euros. De acuerdo con el registro, la sociedad se encuentra en estado de disolución y extinción, con lo que su vida activa se extiende, según los datos disponibles, de 2012 a 2025.

La sociedad se constituyó en 2012. El corpus facilitado no incluye información sobre los socios fundadores, el origen del capital, la motivación de la constitución ni el proceso de puesta en marcha. Estos datos no constan.

La clasificación sectorial disponible sitúa a la empresa en el software y SaaS. Más allá de esta adscripción, el corpus no detalla qué producto o servicio ofrecía, a qué tipo de cliente se dirigía ni qué modelo de negocio seguía. Esta información no consta en las fuentes consultadas.

No consta ningún dato sobre la evolución de la facturación, la plantilla, los clientes o los hitos de crecimiento de la sociedad. El corpus no permite identificar cuáles fueron los años de mejor desempeño ni cuantificar su actividad en ningún momento del periodo 2012-2025.

La causa verificada del cierre es la extinción de la sociedad inscrita en el BORME, con estado documental de "disuelta". Según el registro, la disolución y extinción constan como hecho registral; las fuentes disponibles no indican el motivo material de la disolución (por ejemplo, si fue una liquidación voluntaria, una fusión, una absorción u otra causa), ni la fecha exacta del acuerdo de disolución. Este extremo no consta.

El corpus no contiene información sobre el destino de los activos, la cartera de clientes, la propiedad intelectual o el software de la sociedad, ni sobre si alguna otra empresa ha asumido su actividad. Esta información no consta.

El corpus no identifica a los fundadores ni a los socios de la sociedad, y por tanto no permite trazar su trayectoria posterior. Las personas que aparecen en la cronología registral lo hacen en calidad de apoderados solidarios en actos de nombramiento, no como fundadores, y el corpus no indica qué relación tienen con la sociedad más allá de estos nombramientos. Para completar esta información habría que consultar la ficha registral completa en el Registro Mercantil de Barcelona (composición del consejo de administración y socios), así como las fuentes públicas de identificación de administradores de otras sociedades.

• En el sector del software y SaaS, la continuidad del negocio depende a menudo de la cartera de clientes y de los contratos recurrentes; cuando una sociedad se disuelve, la clave para valorar el impacto es saber si estos activos se han trasladado a otra entidad, dato que aquí no consta y que habría que verificar registralmente.
• La información registral (BORME) documenta la disolución y extinción, pero no explica la causa material; para un seguimiento riguroso hay que cruzarla con las cuentas depositadas y, en su caso, con notas de prensa o comunicaciones de la empresa.
• Una sociedad con un capital social de 6.700 euros y trece años de actividad ilustra que la dimensión del capital no es indicativa del alcance del negocio; el análisis debe apoyarse en las cuentas anuales, no en el capital.
• La presencia de numerosos apoderados solidarios en los últimos años puede ser relevante para entender la estructura operativa, pero no equivale a cambio de propiedad; no hay que confundir apoderamientos con cambios en el accionariado.

TECNOTRAMIT GESTION SL consta al registre com a societat de software i SaaS amb seu a Barcelona, constituïda el 2012 i extingida segons la inscripció al BORME [BORME / BOE (via OpenMercantil), 2026-07-13]. El que es pot reconstruir avui, amb la mateixa essència sectorial, és una plataforma SaaS vertical per a la gestió de tràmits i documentació en despatxos professionals: gestories, assessories, advocats i departaments administratius.

La proposta no és obrir una gestoria, sinó vendre programari a les gestories. El nucli seria: expedients digitals, formularis intel·ligents per a tràmits recurrents (laboral, fiscal, mercantil, estrangeria), signatura electrònica, arxiu documental amb traçabilitat i integració amb seus electròniques i administracions.

Aquesta és una proposta nova, no una recuperació de producte: de l'empresa original només en sabem el sector, la ubicació, l'antiguitat i l'estructura registral, no el catàleg de productes ni els clients.

El mercat rellevant és el de programari de gestió per a despatxos professionals a Espanya. És un mercat real i competitiu, amb actors consolidats en gestió de despatxos, facturació, laboral i fiscal, i amb una pressió creixent cap a la digitalització de tràmits administratius.

El que justifica l'oportunitat no és tant el mercat general com el nínxol: tràmits administratius concrets i repetitius on els despatxos perden hores en formularis, documentació i seguiment d'estats. Un SaaS que empaqueti aquests fluxos per vertical (per exemple, estrangeria o laboral) pot competir sense enfrontar-se frontalment als grans ERP de despatx.

No disposem de dades verificades sobre la mida de mercat específica ni sobre la quota que tenia TECNOTRAMIT GESTION SL: qualsevol xifra de mercat en aquest informe seria una estimació a validar amb fonts sectorials.

Model proposat (a validar):

• Subscripció SaaS per despatx, amb preus escalonats per nombre d'usuaris o expedients. Rang estimat: 30–150 €/mes per despatx petit, 200–600 €/mes per despatx mitjà. Són estimacions de referència, no dades de mercat contrastades.
• Mòduls verticals de pagament addicional (estrangeria, laboral, mercantil), que permeten monetitzar per flux de treball.
• Setup i migració com a ingrés puntual d'entrada.
• Serveis gestionats opcionals (presentació de tràmits per compte del client), que converteixen part del SaaS en servei i augmenten el ticket.

La clau del model és la retenció: un cop el despatx té els expedients i l'arxiu al sistema, el cost de canvi és alt. Això fa que el valor es construeixi en els primers mesos de cada client.

Fases proposades:

1. Validació (mesos 0–3). Entrevistes amb 20–30 despatxos per confirmar quins tràmits concentren més dolor i quant pagarien. Sense producte encara.
2. MVP (mesos 3–9). Un sol vertical, expedients, formularis i arxiu documental. Objectiu: 5–10 despatxos pilots, alguns de pagament.
3. Tracció (mesos 9–18). Segon vertical, integracions amb seus electròniques, primers contractes anuals. Mètrica objectiu estimada: 30–60 despatxos de pagament.
4. Escala (mesos 18–36). Equip comercial, màrqueting de continguts per vertical, possible canal via col·legis professionals i associacions de gestors.

El calendari és una estimació; dependrà de la velocitat de desenvolupament i de la resposta del mercat.

Estimacions a validar, en rang:

• Equip fundador i desenvolupament (any 1): 120.000–250.000 €, segons si es contracta equip tècnic o es desenvolupa amb socis.
• Infraestructura i eines (any 1): 6.000–20.000 €.
• Legal, constitució i compliment (RGPD, contractes): 5.000–15.000 €.
• Comercial i màrqueting inicial: 20.000–60.000 €.
• Total orientatiu any 1: rang ampli de 150.000–350.000 €, a validar segons ambició i equip.

No hi ha dades verificades sobre el capital amb què va operar l'empresa original més enllà del capital social registral de 6.700 € [BORME / BOE (via OpenMercantil), 2026-07-13], que no reflecteix la inversió real necessària avui.

• Competència establerta. Els despatxos ja fan servir programari; caldrà un nínxol clar i un argument de substitució convincent.
• Cost de desenvolupament i integracions. Les seus electròniques i administracions canvien; mantenir integracions és costós i continu.
• Cicle de venda lent. Els despatxos petits decideixen a poc a poc i sovint per recomanació.
• Risc de "producte sense mercat". L'MVP ha de néixer de validació real, no d'una idea tancada.
• Lliçó del registre: l'estructura de molts apoderats solidaris en pocs mesos (2025–2026) [BORME / BOE, 2026-07-13] suggereix una operativa distribuïda i possiblement costosa de coordinar; una reconstrucció hauria de néixer amb estructura més lleugera.

Les lliçons de l'informe original, aplicables a qualsevol reconstrucció:

1. El sector és la pista, no el producte. Sabem que era software i SaaS a Barcelona; no sabem què venia exactament. Reconstruir vol dir partir del nínxol, no d'imitacions.
2. L'antiguitat (2012–2026) indica un mercat real, però el tancament recorda que longevitat no garanteix continuïtat: cal un model rendible des del primer client.
3. L'estructura registral de molts apoderats apunta a una organització àmplia; una reconstrucció hauria de prioritzar un equip petit i un producte enfocat abans d'escalar estructura.
4. El capital social registral (6.700 €) no és indicador de la inversió necessària: qualsevol pla financer seriós s'ha de construir amb estimacions validades, no amb el que consta al registre.
5. Qui ho hauria de fer: un equip fundador amb coneixement real del dia a dia d'una gestoria o despatx professional, capacitat tècnica per construir SaaS i disciplina per validar abans d'invertir.

Les gestories que tramiten en nom de tercers (altes, baixes, recursos, sol·licituds davant administracions) treballen amb un embut de documents, poders notarials i terminis que avui es gestiona amb correu, carpetes compartides i fulls de càlcul. El resultat és pèrdua de traçabilitat, risc de presentar un tràmit amb un poder caducat o insuficient, i impossibilitat de saber qui va fer què i quan.

La ficha registral de TECNOTRAMIT GESTION SL [BORME / BOE (via OpenMercantil), 2026-07-13] mostra desenes de nomenaments d'apoderats solidaris concentrats entre finals de 2025 i principis de 2026. Amb independència de la lectura societària d'aquestes dades, il·lustra un patró operatiu real: moltes persones delegades actuant en nom d'una estructura central. Un producte que governi aquesta delegació (qui pot signar què, amb quin poder i fins a quina data) té un problema concret a resoldre.

Proposo un backend modular monolític amb separació per dominis, desplegat en un sol servei de contenidors, perquè l'equip inicial és petit i la complexitat distribuïda no es justifica.

``` [Client web SPA] --HTTPS--> [API Gateway / BFF] | +--------------+--------------+ | | | [Servei Expedients] [Servei Poders] [Servei Signatura] | | | +------+-------+------+-------+ | | [PostgreSQL] [Object Storage S3] | [Cua de treballs] --> [Worker OCR / validació] ```

Decisions i motius:

• Monòlit modular en lloc de microserveis: el volum inicial no justifica la sobrecàrrega operativa; els límits de domini es mantenen al codi per poder extreure serveis després.
• PostgreSQL com a font de veritat: els expedients requereixen transaccions i integritat referencial fortes (estats, versions de documents, auditories).
• Object storage per als documents: els fitxers no han de viure a la base de dades; es guarden amb hash i referència, i la base en guarda metadades i versions.
• Cua de treballs per a OCR i validacions: són operacions lentes i idempotents que no han de bloquejar la petició HTTP.

Entitats principals (esquema relacional simplificat):

```sql -- Organitzacions i usuaris organitzacio(id, nom, cif, created_at) usuari(id, organitzacio_id, email, rol, actiu)

-- Poders i delegacions poder(id, atorgant_id, apoderat_id, tipus, abast, data_inici, data_fi, document_id, estat) -- estat: vigent | caducat | revocat

-- Expedients de tràmit expedient(id, organitzacio_id, client_id, tipus_tramit, estat, creat_per, created_at, updated_at) -- estat: esborrany | en_validacio | llest | presentat | tancat

-- Documents versionats document(id, expedient_id, nom, mime, hash_sha256, storage_key, versio, pujat_per, created_at)

-- Signatures signatura(id, document_id, signant_id, poder_id, metode, segell_temps, estat, created_at)

-- Auditoria immutable event_auditoria(id, entitat, entitat_id, accio, actor_id, payload_json, created_at) ```

Motius: la taula `poder` amb `data_fi` i `estat` permet bloquejar tràmits amb poders caducats de manera determinista; `event_auditoria` append-only dona traçabilitat legal; el versionat de documents evita sobreescriure proves.

API REST versionada (`/v1`), autenticació OAuth2/OIDC amb JWT i àmbits per organització.

Endpoints clau:

• `POST /v1/expedients` — crea expedient en estat `esborrany`.
• `POST /v1/expedients/{id}/documents` — puja document (multipart), retorna hash i versió.
• `POST /v1/expedients/{id}/validar` — executa regles: documents obligatoris, poders vigents, camps complets.
• `POST /v1/documents/{id}/signar` — inicia signatura electrònica.
• `GET /v1/poders?apoderat_id=&vigent=true` — consulta poders.

Integracions:

• Signatura electrònica: connector a un proveïdor de confiança qualificat (eIDAS) via API; el motiu és la validesa legal davant administracions.
• Notificacions: correu i webhooks per canvis d'estat.
• Importació de poders: càrrega CSV/PDF amb OCR per reduir la feina manual d'alta de delegacions.

1. Model d'expedient i documents versionats amb auditoria: és el nucli sense el qual no hi ha producte.
2. Motor de regles de validació (documents i poders vigents): aporta el valor diferencial immediat.
3. Autenticació i multi-tenant per organització: requisit de seguretat des del dia u.
4. Signatura electrònica en segona fase, un cop el flux d'expedient és estable.

No construir primer: integracions amb administracions concretes ni analítica avançada; depenen d'un nucli que encara no existeix.

• Mida: MVP viable amb 2–3 desenvolupadors en ~3 mesos per al nucli (expedients, documents, validació, auth).
• Risc: complexitat de la signatura qualificada — dependència de proveïdor extern i requisits regulatoris; mitigació: encapsular darrere d'una interfície `SignaturaProvider`.
• Risc: OCR imprecís en poders — mitigació: validació humana obligatòria abans de marcar un poder com a vigent.
• Risc: multi-tenant mal aïllat — mitigació: filtre per `organitzacio_id` a nivell de repositori i tests d'aïllament.
• Risc: retenció i RGPD — els documents contenen dades personals; cal política de retenció i xifrat en repòs.

• Tests d'integració sobre el flux complet: crear expedient → pujar documents → validar → signar → tancar.
• Tests de regles: un expedient amb poder caducat ha de quedar bloquejat a `en_validacio`.
• Tests d'aïllament multi-tenant: cap usuari pot llegir expedients d'una altra organització.
• Prova pilot amb una gestoria real sobre 20–30 expedients reals, mesurant temps per tràmit i errors de validació.
• Auditoria de traçabilitat: verificar que cada canvi d'estat té un event associat i que l'historial és reproduïble.

Nota sobre les fonts: les afirmacions sobre l'activitat i el tancament de TECNOTRAMIT GESTION SL es basen en la ficha registral citada [BORME / BOE (via OpenMercantil), 2026-07-13] i en els actes BORME [BOE / BORME, 2026-07-13]. La interpretació del patró d'apoderats com a senyal operatiu és una lectura de disseny, no una dada registral.