TECNOTRAMIT GESTION SL

Tecnotramit Gestión SL era una societat mercantil amb domicili a Barcelona, constituïda l'any 2012 i adscrita al sector del software i SaaS. El capital social consta en 6.700 euros. D'acord amb el registre, la societat es troba en estat de dissolució i extinció, amb la qual cosa la seva vida activa s'estén, segons les dades disponibles, del 2012 al 2025.

La societat es va constituir el 2012. El corpus facilitat no inclou informació sobre els socis fundadors, l'origen del capital, la motivació de la constitució ni el procés de posada en marxa. Aquestes dades no consten.

La classificació sectorial disponible situa l'empresa en el software i SaaS. Més enllà d'aquesta adscripció, el corpus no detalla quin producte o servei oferia, a quin tipus de client s'adreçava ni quin model de negoci seguia. Aquesta informació no consta a les fonts consultades.

No consta cap dada sobre l'evolució de la facturació, la plantilla, els clients o les fites de creixement de la societat. El corpus no permet identificar quins van ser els anys de millor acompliment ni quantificar-ne l'activitat en cap moment del període 2012-2025.

La causa verificada del tancament és l'extinció de la societat inscrita al BORME, amb estat documental de "disuelta". Segons el registre, la dissolució i extinció consten com a fet registral; les fonts disponibles no indiquen el motiu material de la dissolució (per exemple, si va ser una liquidació voluntària, una fusió, una absorció o una altra causa), ni la data exacta de l'acord de dissolució. Aquest extrem no consta.

El corpus no conté informació sobre el destí dels actius, la cartera de clients, la propietat intel·lectual o el programari de la societat, ni sobre si alguna altra empresa n'ha assumit l'activitat. Aquesta informació no consta.

El corpus no identifica els fundadors ni els socis de la societat, i per tant no permet traçar-ne la trajectòria posterior. Les persones que apareixen a la cronologia registral ho fan en qualitat d'apoderats solidaris en actes de nomenament, no com a fundadors, i el corpus no indica quina relació tenen amb la societat més enllà d'aquests nomenaments. Per completar aquesta informació caldria consultar la fitxa registral completa al Registre Mercantil de Barcelona (composició del consell d'administració i socis), així com les fonts públiques d'identificació d'administradors d'altres societats.

• En el sector del software i SaaS, la continuïtat del negoci depèn sovint de la cartera de clients i dels contractes recurrents; quan una societat es dissol, la clau per valorar l'impacte és saber si aquests actius s'han traslladat a una altra entitat, dada que aquí no consta i que caldria verificar registralment.
• La informació registral (BORME) documenta la dissolució i extinció, però no n'explica la causa material; per a un seguiment rigorós cal creuar-la amb els comptes dipositats i, si escau, amb notes de premsa o comunicacions de l'empresa.
• Una societat amb capital social de 6.700 euros i tretze anys d'activitat il·lustra que la dimensió del capital no és indicativa de l'abast del negoci; l'anàlisi ha de recolzar-se en els comptes anuals, no en el capital.
• La presència de nombrosos apoderats solidaris en els darrers anys pot ser rellevant per entendre l'estructura operativa, però no equival a canvi de propietat; cal no confondre apoderaments amb canvis en l'accionariat.

Reconstruir TECNOTRAMIT com una gestoria digital de tràmits de trànsit i vehicles amb seu a Barcelona: transferències de vehicles, canvis de titularitat, matriculacions, baixes, duplicats de permís de circulació, gestió de multes i recursos, i tràmits davant la DGT i ajuntaments.

La diferència respecte del model original és que avui es pot fer nadiu digital: portal de client, signatura electrònica, pagament en línia, seguiment d'expedients i integració amb els sistemes de la DGT on sigui possible. Això és una proposta, no una dada verificada de l'empresa original.

El que sí que se sap de l'original: era una SL barcelonina constituïda el 2012 amb un capital social de 6.700 €, i el registre mostra una xarxa molt àmplia d'apoderats solidaris (desenes de noms en actes de 2025 i 2026). Això és coherent amb un model de gestoria amb delegacions o punts de servei repartits, on cada apoderat pot signar tràmits en nom de la societat. És un senyal del model operatiu, no una prova del volum de negoci.

El mercat de la gestoria de trànsit és recurrent i regulat: cada compravenda de vehicle, cada canvi de titular, cada baixa i cada matriculació genera un tràmit. No és un mercat que desaparegui; el que canvia és qui el capta (concessionaris, portals de compravenda, asseguradores, gestories tradicionals i plataformes digitals).

Punts a favor d'avui:

• Digitalització creixent del ciutadà i de les empreses de flotes.
• Els concessionaris i portals de cotxes de segona mà necessiten gestoria externa per volum.
• Barcelona té un teixit dens d'empreses, flotes i compravenda de vehicles.

Punts en contra:

• Competència de plataformes digitals nacionals i de gestories locals amb anys de relació.
• Marge per tràmit relativament baix si es competeix només per preu.
• Dependència de la normativa i dels sistemes de l'Administració.

(Aquest apartat és anàlisi de mercat, no dada verificada de l'empresa original.)

Model proposat (a validar):

1. Tràmits a particular (B2C): preu tancat per tràmit, pagament en línia, captació per SEO i publicitat local. Marge per tràmit estimat en un rang de 15–40 € un cop descomptats costos administratius i de personal (estimació, a validar).
2. Contracte amb empreses (B2B): concessionaris, portals de compravenda, flotes i asseguradores. Tarifa per volum i SLA de temps de resolució. És la font d'ingressos més estable.
3. Subscripció SaaS (opcional): si es desenvolupa programari propi, llicenciar-lo a altres gestories o a concessionaris. Aquest era el perfil "Software i SaaS" que consta al registre, però no hi ha dada verificada que l'empresa original vengués programari a tercers; caldria confirmar-ho.
4. Serveis addicionals: multes i recursos, gestió documental, certificats i tràmits municipals.

La clau del model és barrejar B2B recurrent amb B2C de captació, perquè el B2B dona volum estable i el B2C dona marge i marca.

Fases proposades (estimació de temps, a validar):

• Mesos 0–2 — Constitució i compliment: alta de la SL, epígraf d'activitat, assegurança de responsabilitat civil, i verificació dels requisits per operar com a gestoria i per signar tràmits davant la DGT (cal confirmar el règim d'apoderament i col·legiació aplicable).
• Mesos 1–4 — Producte mínim: portal de client, formularis de tràmit, pagament en línia i panell intern de seguiment. Decidir comprar vs. construir el programari.
• Mesos 3–6 — Primers clients B2B: tancar 3–5 concessionaris o portals de compravenda a l'àrea metropolitana de Barcelona amb tarifa per volum.
• Mesos 4–9 — Captació B2C: SEO local, Google Ads i ressenyes; mesurar cost per tràmit.
• Mesos 9–12 — Escalat: afegir apoderats o delegacions si el volum ho justifica, i valorar el llicenciament del SaaS.

Fita de control: si al mes 6 no hi ha almenys un contracte B2B recurrent i un cost per adquisició B2C sostenible, cal revisar el model abans d'escalar.

Xifres estimades i a validar, per a una estructura mínima a Barcelona:

• Constitució, compliment i assegurances: 3.000–8.000 € (estimació).
• Programari: si es compra una solució existent, 3.000–15.000 € l'any (estimació); si es desenvolupa a mida, 25.000–60.000 € (estimació).
• Equip humà inicial (2–3 persones: gestor, administratiu i atenció al client): 60.000–110.000 € anuals de cost total (estimació).
• Local i despeses fixes: 12.000–24.000 € anuals (estimació).
• Màrqueting i captació: 10.000–30.000 € el primer any (estimació).

Total d'arrencada estimat: 60.000–150.000 € segons si es compra o es construeix el programari i segons l'equip inicial. Caldrà validar-ho amb pressupostos reals i amb el règim de col·legiació o apoderament que s'apliqui.

• Compliment normatiu i apoderament: operar tràmits davant la DGT exigeix requisits concrets; un error aquí atura el negoci. Cal verificar-ho abans de res.
• Dependència de l'Administració: canvis de procediment o de sistemes afecten directament el servei.
• Competència de preu: plataformes digitals poden comprimir marges.
• Confiança i reputació: un error en un tràmit genera reclamacions i danys de marca.
• Concentració de clients B2B: perdre un concessionari gran pot fer caure els ingressos.
• El senyal del registre: la xarxa àmplia d'apoderats de l'original suggereix una estructura operativa complexa; replicar-la massa aviat encareix el model.

Lliçons de l'informe original, sense currículum:

• El model funcionava però era intensiu en persones i apoderaments: la reconstrucció ha de començar petita i digital, no replicant la xarxa de delegacions de sortida.
• El programari era part del valor: cal decidir explícitament si es compra o es construeix, perquè és la palanca de marge.
• El B2B és la base estable: els concessionaris i portals donen volum; el B2C dona marca i marge.
• El compliment és el negoci: qui no domina el règim d'apoderament i la normativa no hauria d'entrar-hi.
• Cal validar abans d'escalar: el tancament de l'original recorda que el creixement sense control de costos i de compliment és el risc principal.

(Les lliçons són interpretació a partir de les dades verificades disponibles; no consten com a conclusions de l'empresa original.)

Les gestories i despatxos que tramiten expedients davant d'administracions públiques treballen amb una combinació de correu, carpetes compartides, fulls de càlcul de terminis i documents signats en paper o PDF. Això genera tres problemes recurrents: pèrdua de terminis perquè el còmput de dies hàbils no és automàtic, manca de traçabilitat de qui pot signar o representar el client en cada moment (poders, apoderaments, revocacions) i duplicació de feina en generar formularis i escrits.

La informació registral disponible de TECNOTRAMIT GESTION SL mostra una activitat intensa de nomenaments d'apoderats solidaris en el període 2025–2026 [BORME / BOE (via OpenMercantil), 2026-07-13]. Aquest patró és exactament el tipus de dada que una gestoria ha de mantenir sincronitzada: qui té poder vigent, per a què i fins quan. El producte que es proposa tracta aquesta dimensió com a dada de primer nivell, no com un annex.

El problema, doncs, no és "digitalitzar papers" sinó mantenir un estat coherent i auditable de tres coses alhora: expedients, terminis i representació.

Arquitectura de monolític modular amb desplegament en contenidors, pensada per a un equip petit i un domini amb moltes regles de negoci canviants.

``` [Client web SPA] [App mòbil (PWA)] | | +---- HTTPS ------+ | [API Gateway / Auth] | +------------+-------------+ | | | [Expedients] [Terminis] [Representació] | | | +------+-----+------+------+ | | [PostgreSQL] [Object Storage] | [Cua de jobs] --> [Generador de documents] | [Integració BORME/BOE] [Notificacions email/SMS] ```

Decisions i motius:

• Monolític modular en lloc de microserveis. El domini és fortament transaccional (un expedient, els seus terminis i els seus apoderats es consulten junts). Separar-ho en serveis obligaria a transaccions distribuïdes o a consistència eventual per a dades que l'usuari espera veure coherents en una sola pantalla. Amb un equip reduït, un monolític modular redueix cost operatiu.
• PostgreSQL com a base única. Necessitem transaccions, restriccions d'integritat i consultes de finestres temporals (terminis). PostgreSQL cobreix els tres requisits sense afegir un motor addicional.
• Object storage per a documents, base de dades per a metadades. Els PDFs i adjunts no han d'anar a la base de dades; es guarden a S3-compatible amb referència i hash a PostgreSQL per garantir integritat.
• Cua de jobs per a generació de documents i sincronització externa. La generació de PDFs i la consulta a fonts públiques són operacions lentes i no han de bloquejar la petició HTTP.
• Multi-tenant per fila (tenant_id) en lloc de schema per client. Amb clients de mida similar i un nombre moderat, el filtratge per fila amb Row-Level Security de PostgreSQL és més simple d'operar que N schemas.

Esquema relacional simplificat. Totes les taules porten `tenant_id` i `created_at`/`updated_at`.

```sql -- Clients i representació CREATE TABLE client ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, nom text NOT NULL, nif text NOT NULL, tipus text NOT NULL, -- persona_fisica | persona_juridica UNIQUE (tenant_id, nif) );

CREATE TABLE poder ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, client_id uuid NOT NULL REFERENCES client(id), atorgant text NOT NULL, tipus text NOT NULL, -- general | especial | apoderament abast text, -- text lliure o codi d'àmbit data_inici date NOT NULL, data_fi date, estat text NOT NULL, -- vigent | revocat | caducat font_ref text -- URL BORME/registre d'origen );

CREATE TABLE apoderat ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, nom_complet text NOT NULL, document text );

CREATE TABLE poder_apoderat ( poder_id uuid REFERENCES poder(id), apoderat_id uuid REFERENCES apoderat(id), PRIMARY KEY (poder_id, apoderat_id) );

-- Expedients i terminis CREATE TABLE expedient ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, client_id uuid NOT NULL REFERENCES client(id), referencia text NOT NULL, organisme text NOT NULL, estat text NOT NULL, -- obert | en_tramit | tancat | arxivat UNIQUE (tenant_id, referencia) );

CREATE TABLE termini ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, expedient_id uuid NOT NULL REFERENCES expedient(id), descripcio text NOT NULL, data_inici date NOT NULL, dies_habils int NOT NULL, data_limit date NOT NULL, -- calculada pel motor de calendari completat boolean NOT NULL DEFAULT false );

CREATE TABLE document ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, expedient_id uuid REFERENCES expedient(id), nom text NOT NULL, storage_key text NOT NULL, sha256 text NOT NULL, signat_per uuid REFERENCES apoderat(id) );

-- Auditoria CREATE TABLE audit_log ( id bigserial PRIMARY KEY, tenant_id uuid NOT NULL, actor_id uuid NOT NULL, entitat text NOT NULL, entitat_id uuid NOT NULL, accio text NOT NULL, payload jsonb, creat_a timestamptz NOT NULL DEFAULT now() ); ```

Decisions i motius:

• `poder` separat de `client`. Un client pot tenir diversos poders al llarg del temps i un poder pot afectar més d'un apoderat. Modelar-ho com a entitat pròpia permet historiar revocacions sense sobreescriure.
• `data_limit` materialitzada a `termini`. El còmput de dies hàbils depèn de calendaris (festius locals, nacionals, d'organisme). Es calcula en crear el termini i es recalcula si canvia el calendari, però es desa per poder consultar i alertar sense recalcular a cada lectura.
• `sha256` a `document`. Permet detectar duplicats i verificar que el fitxer a l'storage no s'ha alterat.
• `audit_log` append-only. Requisit de traçabilitat: qui va canviar què i quan. No s'actualitza ni s'esborra.

API REST versionada (`/v1`), autenticació per JWT emès per un proveïdor d'identitat, autorització per rol dins del tenant.

Endpoints principals:

``` GET /v1/expedients?estat=&client_id=&q= POST /v1/expedients GET /v1/expedients/{id} PATCH /v1/expedients/{id}

GET /v1/expedients/{id}/terminis POST /v1/expedients/{id}/terminis POST /v1/terminis/{id}/completar

GET /v1/clients/{id}/poders?vigent=true POST /v1/poders POST /v1/poders/{id}/revocar

POST /v1/documents (multipart; retorna storage_key + sha256) GET /v1/documents/{id}/download (URL signada temporal)

GET /v1/audit?entitat=&entitat_id= ```

Integracions:

• BORME/BOE (OpenMercantil o similar). Job periòdic que consulta nomenaments i actes per NIF de client i proposa actualitzacions de poders. La integració és de només lectura i sempre genera una proposta que un usuari ha de confirmar; no s'aplica automàticament. Motiu: les dades registrals són font de veritat però el seu tractament requereix criteri humà (homònims, càrrecs, abast).
• Calendari de festius. Servei intern amb taula de festius per municipi/organisme, actualitzable manualment. Motiu: no hi ha una API pública fiable i homogènia per a tots els àmbits.
• Correu i SMS. Proveïdor transaccional per a alertes de terminis; es configura per tenant.
• Signatura electrònica. Integració via API amb un proveïdor de signatura (p. ex. estàndard eIDAS) per signar documents generats; el resultat es desa com a nou `document` amb `signat_per`.

Ordre de construcció, amb justificació:

1. Nucli de clients, expedients i documents. És el mínim que substitueix la carpeta compartida. Sense això no hi ha producte.
2. Motor de terminis amb calendari de festius. És el diferenciador operatiu immediat: evita pèrdues de termini. Es pot lliurar abans que la representació.
3. Autenticació, multi-tenancy i auditoria. Han d'existir des del primer dia perquè retroactivament és car d'afegir; l'audit_log s'ha d'escriure des del primer escriptura.
4. Mòdul de poders i apoderats, amb càrrega manual. La integració BORME ve després; primer cal el model i la UI.
5. Generació de documents a partir de plantilles. Un cop hi ha expedients i dades, l'automatització de formularis aporta valor.
6. Integració BORME/BOE i alertes. Al final, perquè depèn de tot l'anterior i té més risc extern.

• Volum esperat. Escenari de referència: 200 tenants, 50 usuaris per tenant, 500.000 expedients, 2 milions de documents. PostgreSQL amb particionat per `tenant_id` a `audit_log` i índexs compostos cobreix aquest ordre de magnitud en una sola instància.
• Risc: qualitat de les dades registrals. Els nomenaments poden contenir homònims o càrrecs amb abast ambigu. Mitigació: la integració només proposa canvis i exigeix confirmació; es desa la font (`font_ref`) per poder auditar l'origen.
• Risc: còmput de terminis. Els calendaris de festius varien per administració i any; un error de càlcul té conseqüències legals. Mitigació: tests exhaustius amb casos reals, versió del calendari per any i registre de quina versió s'ha usat per calcular cada `data_limit`.
• Risc: multi-tenancy i fuites de dades. Un filtre `tenant_id` oblidat exposa dades d'un altre client. Mitigació: Row-Level Security a PostgreSQL com a xarxa de seguretat, a més del