TYPEFORM SL

TYPEFORM SL es una sociedad mercantil española con domicilio en Barcelona, constituida en 2018 según los datos del corpus, con un capital social de 9.993 euros y estado registral activo. De acuerdo con el registro, los administradores que constan son Eric Charles Salzman (consejero), Jay Young Choi (consejero) y J. Donald Sherman (consejero y, desde 2025, presidente).

El corpus la clasifica como "startup" dentro del sector "Otros". Los mismos datos indican que existen otras sociedades del corpus con los mismos fundadores, todas llamadas Typeform y también activas en Barcelona.

La cronología registral del corpus comienza antes de 2018: consta un nombramiento de apoderado el 10 de agosto de 2017 y otro el 22 de septiembre de 2017, con referencias registrales (tomo 45281, folio 94 y 95, sección 8, hoja B 421911). El 13 de marzo de 2018 consta una ampliación de capital de 61,45 euros, con un capital suscrito resultante de 8.928,69 euros, y una modificación estatutaria relativa a la constitución del consejo (artículo 8.4.1). El 16 de julio de 2018 consta el nombramiento de Joaquim Lecha Soler como consejero.

Cabe señalar una discrepancia: el corpus fija el año de constitución en 2018, pero los actos registrales documentados comienzan en 2017. Las fuentes disponibles no permiten resolver esta diferencia, por lo que se hace constar tal como aparece.

Los datos del corpus no describen la actividad económica concreta de TYPEFORM SL más allá de la clasificación sectorial genérica ("Otros") y de su vinculación, por el nombre y por los administradores, al grupo Typeform. No consta en las fuentes facilitadas qué producto o servicio prestaba esta sociedad específica ni a quién se dirigía. Cualquier afirmación sobre herramientas de formularios o encuestas digitales correspondería al grupo y no se puede atribuir a esta sociedad concreta con la documentación disponible.

El corpus no contiene datos financieros (facturación, resultados, plantilla) que permitan describir la evolución económica de la sociedad. Lo que sí consta en el registro es una actividad societaria sostenida: ampliaciones de capital en 2018 (61,45 €), el 31 de marzo de 2022 (976,93 €, hasta 9.793,59 €) y el 16 de junio de 2022 (199,32 €, hasta 9.992,91 €); nombramientos sucesivos de apoderados solidarios entre 2019 y 2026; y la designación de auditores de cuentas (BDO Auditores SLP en 2019 y Ernst & Young SL en 2019 y nuevamente en 2023). Esta secuencia indica una sociedad en funcionamiento y sometida a obligaciones de verificación contable, según el registro.

No consta. TYPEFORM SL figura como activa en la ficha registral consultada (OpenMercantil, a partir del BORME, 2026-08-06), y el último acto documentado en el corpus es un nombramiento de apoderado solidario el 6 de agosto de 2026. Las fuentes disponibles no recogen ninguna disolución, liquidación, concurso ni operación de transformación de esta sociedad. Por tanto, no se puede explicar ningún cierre porque los datos no documentan ninguno.

Dado que la sociedad no consta como cerrada, no se puede hablar de herencia en el sentido de legado de una actividad extinguida. Lo que consta es su continuidad registral y su vinculación a una estructura societaria más amplia: el corpus menciona tres sociedades adicionales con los mismos fundadores, todas llamadas Typeform, activas y con sede en Barcelona. Las fuentes facilitadas no permiten determinar qué función cumple cada una dentro del grupo ni qué relación jerárquica hay entre ellas.

De acuerdo con el registro, J. Donald Sherman consta como presidente desde el 19 de junio de 2025, en sustitución de David Joseph Okuniew, y como consejero desde el 18 de septiembre de 2023. Eric Charles Salzman consta como consejero desde el 10 de marzo de 2025 y Jay Young Choi desde el 10 de septiembre de 2024.

Otras personas que han ocupado cargos según el corpus: Joaquim Lecha Soler (consejero y apoderado, 2018-2019), Robert Muñoz Ruperez y Pietro Bezza (consejeros revocados en 2023), Benjamin Jonathan Sabatier (consejero, 2022), Albert Pradell de Montagut (secretario no consejero, 2021) y diversos apoderados solidarios (entre otros, Huw Llewelyn Lloyd Slater, Keysa Yearim Yanez Leon, Jenny Buch, Daniela Paulina Sikora, Luis Guillermo de Rojas Dierssen, Maria Guasch Nogues, Benoit Pierre Antoine Aguila y Osvaldo Jose Fuentes Atton).

No consta en las fuentes facilitadas ninguna información sobre la trayectoria actual de estas personas fuera de los cargos registrales mencionados. Para completarlo se podrían consultar las fichas registrales actualizadas de cada sociedad del grupo en el BORME y las memorias anuales depositadas en el Registro Mercantil de Barcelona.

• Distinguir la sociedad del grupo. En estructuras como esta, el nombre comercial coincide con varias sociedades mercantiles. Antes de describir "qué hace" una SL hay que verificar qué entidad concreta tiene la actividad, porque el registro puede mostrar solo el vehículo societario.
• Leer la cronología registral como indicador de actividad. La sucesión de ampliaciones de capital, nombramientos de apoderados y designaciones de auditores es la señal más fiable de vitalidad de una SL cuando no hay datos financieros públicos.
• No confundir "activa" con "exitosa". El estado registral solo indica que la sociedad no ha sido disuelta; no dice nada sobre rentabilidad ni dimensión.
• Verificar las fechas de constitución. La discrepancia entre el año del corpus (2018) y los primeros actos registrales (2017) recuerda que hay que contrastar siempre la fecha de constitución con la primera inscripción.
• Consultar el depósito de cuentas. Para cualquier análisis económico de una SL activa, la fuente operativa es el depósito anual de cuentas en el Registro Mercantil, que el corpus no incluye.

Avís previ: les dades facilitades descriuen TYPEFORM SL com a activa (estat registral: activa) i no inclouen cap acte de dissolució, liquidació o concurs. Per tant, no hi ha "empresa que va tancar" sobre la qual reconstruir: el que es pot fer és dissenyar una proposta nova inspirada en el nínxol que el registre insinua (societat tecnològica a Barcelona, capital petit, consell amb perfils internacionals, auditoria Big Four, ampliacions de capital successives el 2022).

La proposta, marcada com a hipòtesi de treball, seria una eina de formularis conversacionals i captura de dades per a equips de màrqueting, producte i recerca, amb èmfasi en:

• formularis d'una sola pregunta per pantalla (patró "conversational UI"),
• integracions natives amb CRM i eines d'automatització,
• compliment RGPD des del primer dia (hostatjament UE, DPA clars).

No es pot afirmar que aquest fos el producte exacte de TYPEFORM SL a partir de les dades registrals: el registre no descriu l'activitat comercial. La proposta és, per tant, una lectura de nínxol, no una còpia verificada.

El mercat de programari de formularis i enquestes és gran i madur, amb competidors consolidats (Google Forms, Microsoft Forms, SurveyMonkey, Jotform, Typeform mateix). La diferenciació realista avui no és "fer formularis", sinó:

• experiència d'usuari (formularis que es responen com una conversa),
• integracions amb l'stack modern (HubSpot, Notion, Slack, Zapier, Make),
• compliment normatiu (RGPD, residència de dades a la UE),
• nínxos verticals (recerca acadèmica, RRHH, atenció al client).

Estimació (a validar): el segment de "formularis conversacionals" pot representar un nínxol de desenes de milions d'euros anuals a nivell global, però la pressió competitiva és alta i el cost d'adquisició de clients (CAC) en SaaS B2B sol ser significatiu. No hi ha dades públiques verificades al registre sobre facturació, clients o quota de mercat de TYPEFORM SL, i per tant no s'aporten xifres de mercat atribuïdes a l'empresa.

Proposta (no verificada):

• SaaS per subscripció amb plans per seient o per volum de respostes.
• Freemium amb límits de respostes/mes per captar usuaris i convertir a plans de pagament.
• Plans d'equip/empresa amb SSO, auditories i DPA.
• Add-on de compliment (residència de dades UE, retenció configurable).

Estimació de preus (rang, a validar): 0 € (free), ~15–25 €/mes per usuari en pla individual, ~40–80 €/mes per usuari en pla d'equip. Aquests imports són hipòtesis de mercat, no dades de TYPEFORM SL.

Proposta en 4 fases (calendari estimat, a validar):

1. Fase 0 — Validació (0–2 mesos). Entrevistes amb 20–30 equips de màrqueting/producte/RRHH. Objectiu: confirmar el nínxol i el preu disposat a pagar.
2. Fase 1 — MVP (2–5 mesos). Constructor de formularis d'una pregunta per pantalla, 5 integracions clau, exportació de dades, compliment RGPD bàsic. Llançament en beta tancada.
3. Fase 2 — Go-to-market (5–9 mesos). Llançament públic, freemium, contingut SEO, primeres 100–500 comptes de pagament (objectiu estimat, a validar).
4. Fase 3 — Escalat (9–18 mesos). Pla d'equip, SSO, partnership amb agències i eines no-code.

Totes les xifres són estimacions de mercat, no dades de TYPEFORM SL.

• Constitució de societat SL a Barcelona: ~600–1.200 € (notaria, registre, gestoria). El capital social mínim legal és 1 €; TYPEFORM SL té 9.993 € segons el registre, però per a una nova societat no cal replicar-ho.
• Equip mínim viable (2–3 persones, 6 mesos): ~120.000–200.000 € (sous + seguretat social, rang estimat).
• Infraestructura cloud i eines (any 1): ~6.000–15.000 € (estimació).
• Legal, RGPD, DPA, termes: ~3.000–8.000 € (estimació).
• Màrqueting i adquisició inicial: ~20.000–50.000 € (estimació).
• Total orientatiu any 1: ~150.000–270.000 € (rang estimat, a validar amb un pla financer detallat).

• Competència consolidada (Google, Microsoft, SurveyMonkey, Typeform mateix): difícil diferenciar-se només per UX.
• CAC alt en SaaS B2B i cicle de vendes llarg en plans d'equip.
• Compliment normatiu (RGPD, transferències internacionals de dades): cost i complexitat creixents.
• Dependència de plataformes (integracions amb tercers que poden canviar API o preus).
• Risc de confondre el nínxol: les dades registrals de TYPEFORM SL no descriuen el producte; qualsevol proposta de producte és una hipòtesi i cal validar-la amb el mercat abans d'invertir.

Lliçons que es poden extreure de l'expedient registral de TYPEFORM SL (no és un currículum, sinó un resum de senyals):

1. Consell amb perfils internacionals i experimentats (Salzman, Choi, Sherman) des de fases primerenques: senyal que el govern corporatiu es va professionalitzar aviat.
2. Auditoria Big Four (BDO el 2019, Ernst & Young des del 2019 i de nou el 2023): indica voluntat de transparència i preparació per a inversors o escrutini extern.
3. Ampliacions de capital successives el 2022 (març i juny): senyal d'injecció de fons o ajust de l'accionariat en fase de creixement.
4. Rotació freqüent d'apoderats i consellers: normal en startups amb inversors, però implica necessitat de governança clara i documentació ordenada.
5. Conclusió per a un nou projecte: qui vulgui construir avui en aquest nínxol hauria de combinar producte enfocat, governança professional des del dia 1 i compliment normatiu com a avantatge competitiu, no com a cost afegit.

Nota final: aquest informe no pot afirmar que TYPEFORM SL hagi tancat; el registre la mostra activa a 2026-08-06. Qualsevol lectura de "reconstrucció" és, per tant, una proposta de nínxol, no una recuperació d'una empresa desapareguda.

Els formularis tradicionals (graella de camps) tenen taxes d'abandonament altes perquè exposen tota la feina de cop i no s'adapten al context de qui respon. Un producte com el que va fer TYPEFORM SL resol això presentant una pregunta per pantalla, amb lògica de salt que fa que cada persona només vegi el que li pertoca, i amb una API que permet incrustar el formulari a qualsevol web o app.

El problema tècnic concret que cal resoldre no és "fer formularis bonics", sinó: com executar lògica de branching arbitrària de forma determinista, versionada i auditable, amb latència baixa al client i consistència al servidor. Aquesta és la part que diferencia el producte i la que especifico aquí.

Quatre components desplegables per separat:

``` [Client web/app] | (HTTPS, JSON) v [API Gateway / BFF] ---> [Servei de formularis] ---> [Postgres] | | (definicions + respostes) | v | [Motor de lògica] (llibreria, s'executa al client i al servidor) | v [Ingesta d'esdeveniments] ---> [Kafka] ---> [Consumer d'analítica] ---> [ClickHouse] ```

Decisions i motius:

• Motor de lògica com a llibreria compartida (TypeScript), no com a servei. El branching s'ha d'avaluar a cada tecla al client per donar resposta immediata; fer-ho per xarxa afegiria 50-150 ms per pas. Per garantir que el servidor no accepti respostes que el client no hauria permès, la mateixa llibreria s'executa al servidor en validar l'enviament. Una sola implementació, dos llocs d'execució.
• Postgres amb JSONB per a la definició del formulari. La definició és un document jeràrquic (preguntes, blocs, condicions) que canvia sovint i no té consultes relacionals complexes. JSONB permet desar-lo sencer i versionar-lo sense migracions d'esquema per cada tipus de pregunta nou. Les respostes, en canvi, van a taules relacionals perquè sí que es consulten i s'agreguen.
• Kafka per a esdeveniments de resposta. Cada visualització de pregunta i cada resposta és un esdeveniment. Escriure'ls directament a la BD de respostes faria el camí crític més lent i barrejaria escriptura transaccional amb analítica. Kafka desacobla: l'API respon quan la resposta és a Postgres, i l'analítica es materialitza a ClickHouse de forma asíncrona.
• Versionat immutable de formularis. Cada publicació crea una versió nova; les respostes guarden `form_version_id`. Això fa que una resposta antiga es pugui reproduir exactament amb la lògica que la va generar, cosa imprescindible per a auditories i per no trencar informes històrics.

Esquema principal (Postgres):

```sql -- Formulari lògic CREATE TABLE forms ( id uuid PRIMARY KEY, workspace_id uuid NOT NULL, slug text NOT NULL UNIQUE, created_at timestamptz NOT NULL DEFAULT now() );

-- Versió publicada (immutable) CREATE TABLE form_versions ( id uuid PRIMARY KEY, form_id uuid NOT NULL REFERENCES forms(id), version_no int NOT NULL, definition jsonb NOT NULL, -- preguntes, blocs, lògica published_at timestamptz NOT NULL DEFAULT now(), UNIQUE (form_id, version_no) );

-- Resposta enviada CREATE TABLE responses ( id uuid PRIMARY KEY, form_version_id uuid NOT NULL REFERENCES form_versions(id), submitted_at timestamptz NOT NULL DEFAULT now(), metadata jsonb NOT NULL, -- user agent, referrer, locale answers jsonb NOT NULL -- {question_id: valor} );

-- Índex per consultes per formulari i data CREATE INDEX ON responses (form_version_id, submitted_at); ```

L'estructura de `definition` (contracte estable):

```json { "questions": [ {"id": "q1", "type": "choice", "options": ["a","b"]}, {"id": "q2", "type": "text", "required": true} ], "logic": [ {"if": {"q1": "a"}, "goto": "q2"}, {"if": {"q1": "b"}, "goto": "end"} ] } ```

Motiu de separar `answers` en JSONB: el nombre i tipus de preguntes varia per formulari; normalitzar-ho en una taula `answers(question_id, value)` multiplicaria files i faria l'escriptura més lenta. Les consultes analítiques es fan a ClickHouse, on sí que es desnormalitza.

API REST versionada (`/v1`), autenticada amb clau d'API per workspace.

• `POST /v1/forms/{slug}/responses` — envia una resposta. Cos: `{form_version_id, answers}`. El servidor re-executa el motor de lògica sobre `answers` i rebutja (422) si la resposta no és assolible amb aquella versió. Motiu: el client no és de confiança.
• `GET /v1/forms/{slug}` — retorna la definició de la versió publicada actual (o `?version=`). Cachejable amb `ETag`.
• `POST /v1/forms/{slug}/events` — ingesta d'esdeveniments de visualització (batch, màxim 100 per crida). Escriu a Kafka; resposta 202.
• `GET /v1/forms/{slug}/stats?from=&to=` — agregats llegits de ClickHouse.

Integracions previstes, per ordre de valor:

1. Webhooks per resposta nova (HMAC-SHA256 a la capçalera, reintents amb backoff exponencial, 5 intents).
2. Incrustació via iframe amb `postMessage` per a l'alçada dinàmica.
3. Exportació CSV/JSON per lots asíncrona (job + URL signada).

Ordre estricte, perquè cada peça desbloqueja la següent:

1. Motor de lògica com a llibreria amb tests de propietat (property-based testing): donada una definició i un camí de respostes, ha de produir sempre la mateixa seqüència de preguntes. És el nucli i el risc principal.
2. Model de dades i API de respostes amb validació server-side reutilitzant el motor.
3. Renderitzador web (React) que consumeix la definició i el motor.
4. Versionat i publicació de formularis.
5. Pipeline d'esdeveniments i analítica (Kafka + ClickHouse). Es pot ajornar perquè el producte funciona sense analítica; no funciona sense el motor.

• Mida de la definició: un formulari gran pot arribar a 200 preguntes i 500 regles. El JSONB resultant és de l'ordre de 100-300 KB. Cal servir-lo comprimit (gzip/brotli) i cachejat a CDN; si creix més, caldrà carregar blocs per demanda.
• Risc: divergència client/servidor. Si les versions de la llibreria divergeixen, el servidor rebutjarà respostes vàlides. Mitigació: la versió del motor viatja a la capçalera i el servidor accepta qualsevol versió publicada en els darrers 90 dies.
• Risc: esclat d'esdeveniments. Un formulari viral pot generar milers d'esdeveniments per segon. Kafka ho absorbeix, però el consumer de ClickHouse ha de ser idempotent (clau `event_id`) per tolerar reintents.
• Cost: ClickHouse i Kafka són el gruix del cost d'infraestructura; per a un producte inicial es pot començar amb Postgres + una taula d'esdeveniments particionada i migrar quan el volum ho justifiqui.

• Tests de propietat del motor: per a definicions generades aleatòriament, cap camí de respostes no pot portar a una pregunta inexistent ni a un bucle infinit (límit de passos). Cobertura objectiu del 100% de les branques del motor.
• Tests de contracte client/servidor: el mateix conjunt de casos (definició + respostes) s'executa contra la llibreria al navegador i al servidor; els resultats han de coincidir bit a bit.
• Test d'integració de la ingesta: enviar 10.000 esdeveniments amb duplicats i verificar que ClickHouse en té exactament els únics.
• Càrrega: `POST /responses` amb p95 < 200 ms a 500 req/s; la definició servida des de CDN amb p95 < 50 ms.
• Reproduïbilitat històrica: donada una resposta antiga, re-executar el motor amb la seva `form_version_id` ha de reproduir el camí exacte; es comprova en un test de regressió amb formularis reals congelats.