Typeform

Typeform es una empresa de software como servicio (SaaS) con sede en Barcelona, constituida en el año 2012. Su razón social es TYPEFORM, S.L. y los cofundadores que constan son David Ok y Vlad Nabhan.

Según el registro, el estado de la empresa es activo. Por tanto, no se trata de una empresa que haya cerrado ni que haya sido objeto de una transformación societaria documentada en el corpus.

De acuerdo con la cronología registral disponible, la empresa se constituyó el 1 de enero de 2012 en Barcelona. El corpus no aporta ningún otro detalle sobre las circunstancias de la fundación, el origen del capital ni el proceso previo a la constitución.

El corpus clasifica Typeform dentro del sector del software y del SaaS. Más allá de esta adscripción sectorial, los datos disponibles no permiten detallar el producto, el modelo de negocio ni el perfil de clientes. Esta información no consta en el corpus suministrado.

No consta. El corpus no incluye datos de ingresos, financiación, número de trabajadores, clientes ni hitos de crecimiento. No se puede afirmar nada sobre la evolución de la empresa más allá de su constitución en 2012 y su estado registral activo.

No aplica: según el registro, la empresa consta activa. El corpus no documenta ningún cierre, concurso, disolución ni transformación societaria.

No consta. El corpus no permite identificar ningún legado documentado de la empresa, ni en forma de productos, spin-offs, patentes u otros efectos sobre el sector.

El corpus solo identifica a David Ok y Vlad Nabhan como cofundadores. No consta ninguna información sobre su trayectoria posterior, sus cargos actuales ni su participación en otros proyectos. Para completar esta información habría que consultar el registro mercantil (BORME y notas registrales) y fuentes públicas de la empresa.

Con los datos disponibles no se puede extraer ninguna lección operativa específica sobre el sector: el corpus no contiene información sobre el producto, el modelo de precios, la captación de clientes, la financiación ni la evolución operativa de Typeform. Cualquier conclusión en este sentido sería una suposición y no se puede sostener con las fuentes suministradas. Para un informe analítico habría que ampliar el corpus con fuentes primarias (cuentas anuales depositadas, notas registrales) y fuentes sectoriales.

La idea original verificable és la de Typeform com a startup de software i SaaS constituïda a Barcelona el 2012 per David Ok i Vlad Nabhan [Wikipedia]. La proposta que es podria reconstruir avui (proposta meva, no fet verificat) és un producte de formularis i enquestes amb interfície conversacional —una pregunta alhora—, enfocat a equips que recullen dades de clients, candidats o usuaris i volen una experiència més humana que un formulari clàssic.

Avui aquesta categoria és madura i molt competida, però també ho és la demanda: gairebé qualsevol equip de màrqueting, RRHH o producte necessita recollir feedback. La diferència respecte del 2012 és que ara caldria competir amb incumbents consolidats i amb eines genèriques (formularis dins de suites, no-code, etc.). La reconstrucció realista no seria "fer un altre Typeform", sinó un nínxol: un vertical concret, un mercat lingüístic (per exemple català/castellà/portuguès ben cuidats), o una capa d'IA que generi i analitzi formularis.

El mercat de programari de formularis i enquestes existeix i és global; és un segment dins del SaaS d'eines de negoci. No disposo de dades verificades de mida de mercat a les fonts proporcionades, així que no n'afirmo cap xifra: qualsevol número seria una estimació a validar.

El que sí que és raonable afirmar com a anàlisi (no com a dada): la demanda ve de tres grans blocs —màrqueting i captació de leads, recerca d'usuaris i feedback de producte, i RRHH i enquestes internes. Un projecte nou no hauria de pretendre cobrir-los tots tres de sortida. La competència és intensa i amb efectes de xarxa i marca consolidats; per tant, el mercat "existeix" però la finestra és de nínxol, no de producte generalista.

Model proposat (proposta meva): SaaS per subscripció amb plans per nombre de respostes i seients, amb un pla gratuït limitat com a motor d'adquisició. És el model natural de la categoria i el que fa previsible l'ingrés recurrent.

Estructura suggerida, a validar:

• Pla gratuït amb límits de respostes/mes (captació i boca-orella).
• Pla de pagament individual o d'equip petit (ingrés principal).
• Pla d'empresa amb SSO, permisos i integracions (marge alt, cicle de venda més llarg).
• Possibles ingressos addicionals per ús d'IA (generació i anàlisi de respostes), facturats per consum.

No tinc dades verificades de preus ni de conversions de Typeform; qualsevol xifra de preu o d'ARPU que es faci servir en un pla financer hauria de marcar-se com a estimació i validar-se amb recerca de competidors i proves de disposició a pagar.

Proposta de full de ruta (no fets de l'empresa original):

1. Fase 0 — Validació (4-8 setmanes, estimació): triar un nínxol concret i parlar amb 15-25 usuaris potencials d'aquell nínxol. Objectiu: confirmar que pagarien per una experiència conversacional millor que la que fan servir.
2. Fase 1 — MVP (2-4 mesos, estimació): constructor de formularis one-at-a-time, publicació per enllaç, recollida de respostes i exportació. Res d'integracions complexes al principi.
3. Fase 2 — Primers clients de pagament (2-3 mesos, estimació): llançament amb pla gratuït i un pla de pagament simple; objectiu d'un nombre petit de clients de pagament, a validar segons el nínxol.
4. Fase 3 — Retenció i integracions: les integracions que demanin els clients reals (CRM, fulls de càlcul, eines de RRHH), no les que semblin atractives en abstracte.
5. Fase 4 — Decisió d'escalat: si la retenció i el creixement orgànic funcionen, invertir en màrqueting i equip; si no, pivotar el nínxol abans de cremar caixa.

Totes les xifres següents són estimacions pròpies, en rang, a validar amb pressupostos reals:

• Equip mínim viable: 1-2 persones fundadores tècniques i, si és possible, algú de producte/creixement. Cost de persones: dependrà de si funden a sou reduït o a mercat; un rang orientatiu de cost anual per persona a Barcelona seria d'uns 35.000-60.000 € (estimació, a validar segons perfil).
• Desenvolupament del MVP: si el fan els fundadors, el cost és sobretot temps (3-6 mesos-persona, estimació). Si es subcontracta, un rang plausible seria de 25.000-60.000 € (estimació àmplia, a validar).
• Infraestructura i eines: allotjament, base de dades, correu transaccional, analítica i pagaments; un rang de 100-500 €/mes en fase inicial (estimació).
• Màrqueting i vendes inicials: 0-1.500 €/mes en contingut i proves de pagament (estimació).
• Legal i administratiu (constitució, termes, privacitat, RGPD): 2.000-6.000 € (estimació).

Rang total orientatiu per arribar a un MVP amb primers clients de pagament: des d'uns 15.000-25.000 € si els fundadors ho fan tot amb cost mínim, fins a uns 80.000-120.000 € si es contracta desenvolupament i es manté un any de runway (estimació molt àmplia, a validar).

• Risc de mercat saturat: la categoria té incumbents forts i efectes de xarxa; un producte generalista nou ho tindria molt difícil. Mitigació: nínxol i diferenciació clara.
• Risc de commoditització: els formularis són una funcionalitat dins de moltes suites; cal un motiu específic per pagar per una eina dedicada.
• Risc d'adquisició: el creixement orgànic del pla gratuït no és automàtic; el cost d'adquisició pot menjar el marge si no hi ha boca-orella.
• Risc de retenció: els formularis són d'ús esporàdic per a molts usuaris; caldria un cas d'ús recurrent (enquestes periòdiques, feedback continu) per sostenir la subscripció.
• Risc de compliment i privacitat: recollir dades personals implica RGPD i, segons el nínxol, requisits addicionals.
• Risc d'equip i caixa: un projecte així necessita runway suficient per iterar; infrafinançar-lo és un risc habitual.

Nota important: com que Typeform consta com a activa, aquests riscos descriuen el repte de construir un competidor o un producte similar avui, no el motiu d'un tancament.

Lliçons que es poden extreure de l'informe original (i del fet verificat que Typeform es va constituir a Barcelona el 2012 i segueix activa):

• Un producte SaaS global es pot construir des de Barcelona; la ubicació no és l'limitant principal.
• L'essència a replicar no és la funcionalitat sinó l'enfocament: una experiència d'usuari diferencial en una categoria on tothom feia el mateix.
• Cal un equip fundador que combini producte i enginyeria, i que accepti començar en un nínxol abans de generalitzar.
• La longevitat (seguir activa més d'una dècada) suggereix que la retenció i l'adaptació contínua al mercat pesen més que el llançament inicial.
• Qui ho hauria de fer: un equip petit, tècnic i amb criteri de producte, disposat a validar amb usuaris reals abans d'invertir, i amb runway per a 12-18 mesos (estimació). No és un projecte per a qui busqui resultats ràpids ni per a qui vulgui competir de front amb els incumbents sense un angle propi.

Typeform va popularitzar un format d'enquesta on es mostra una pregunta alhora, amb transicions suaus i un to conversacional, que augmenta la taxa de compleció respecte als formularis llargs tradicionals. El problema tècnic central no és només "fer formularis": és (a) renderitzar de manera fiable un flux de preguntes amb lògica condicional al client, (b) capturar respostes parcials sense perdre dades si l'usuari abandona, i (c) oferir analítica d'embut (funnel) per pregunta.

El producte que especifico aquí és una versió implementable i autoallotjable d'aquest nucli, pensada per a equips que volen controlar les dades de resposta. No replica la marca ni el codi de Typeform; n'agafa el patró d'interacció com a referència de disseny.

Tres plans separats, comunicats per HTTP/JSON i cues:

```text [Client: renderer] --(GET /f/{slug} JSON schema)--> [API pública] | | |--(POST /f/{slug}/events, /responses)--> | v [Constructor web] --(REST /api/v1/forms)--> [Servei de formularis] --(SQL)--> [Postgres] | (outbox) --> [Cua] --> [Worker analítica] --> [ClickHouse] ```

• Renderer al client: rep un "form schema" versionat (JSON) i executa el motor de lògica en local perquè el flux sigui instantani i funcioni amb mala connectivitat. Motiu: la latència per pregunta mataria l'experiència conversacional.
• Servei de formularis (API): CRUD de formularis, versionat i publicació immutable per slug. Motiu: separar edició de publicació evita que un canvi en curs trenqui formularis ja enviats.
• Servei de respostes: idempotent per `response_id` generat al client, per tolerar reintents.
• Analítica: esdeveniments (`view`, `question_shown`, `question_answered`, `submit`) enviats a una cua i agregats a ClickHouse. Motiu: no bloquejar l'escriptura de respostes amb càlculs analítics.

Postgres per a l'estat transaccional; ClickHouse per a esdeveniments.

```sql -- Postgres forms(id uuid pk, workspace_id uuid, title text, status text, -- draft|published|archived current_version int, created_at timestamptz) form_versions(id uuid pk, form_id uuid fk, version int, schema jsonb, published_at timestamptz, unique(form_id, version)) responses(id uuid pk, form_id uuid fk, form_version int, submitted_at timestamptz, completed boolean, metadata jsonb) -- metadata: ua, referrer, locale answers(id bigserial pk, response_id uuid fk, question_id text, value jsonb) -- ClickHouse events(form_id uuid, version int, session_id uuid, type LowCardinality(String), question_id Nullable(String), ts DateTime64(3)) ```

El `schema jsonb` conté la llista ordenada de blocs (`question`, `statement`, `logic`) i les regles de salt. Motiu de guardar el schema sencer per versió: el renderer ha de poder reconstruir exactament el formulari que l'usuari va veure, encara que l'autor l'hagi editat després.

• `POST /api/v1/forms` — crea esborrany.
• `PUT /api/v1/forms/{id}/draft` — desa schema (validat contra JSON Schema).
• `POST /api/v1/forms/{id}/publish` — crea `form_version` immutable i retorna `slug`.
• `GET /f/{slug}` — retorna el schema públic de la versió publicada (cachejable, ETag).
• `POST /f/{slug}/responses` — cos amb `response_id` (idempotència), `answers[]`, `completed`.
• `POST /f/{slug}/events` — batch d'esdeveniments per a analítica.
• `GET /api/v1/forms/{id}/responses?format=csv|json` — exportació.
• Webhook `response.created` signat amb HMAC-SHA256 per a integracions externes (CRM, fulls de càlcul).

Integracions de fase 2: exportació a Google Sheets i un connector genèric de webhook. Motiu de començar per webhook: cobreix la majoria de casos sense construir connectors a mida.

1. Motor de schema + validador (JSON Schema) i renderer d'un sol bloc amb navegació endavant/endarrere.
2. Publicació versionada i endpoint `GET /f/{slug}` amb ETag.
3. Captura de respostes idempotent i exportació CSV.
4. Lògica condicional bàsica (salt per resposta) al renderer.
5. Esdeveniments mínims (`view`, `submit`) i un embut simple per pregunta.

Deixem per a després: pagaments, plantilles, col·laboració multiusuari i integracions natives.

• Mida MVP: ~3-4 mesos per a 2 enginyers backend + 1 frontend; ~15-20k línies efectives.
• Risc: divergència de lògica entre renderer i servidor. Mitigació: una sola llibreria de lògica compartida (TypeScript) i tests de propietat sobre el schema.
• Risc: esquemes grans (100+ blocs) que fan pesat el JSON inicial. Mitigació: compressió i càrrega per blocs si supera un llindar.
• Risc: abús/spam a l'endpoint públic de respostes. Mitigació: rate limiting per IP/slug i captcha opcional per formulari.
• Risc: privacitat de dades de resposta. Mitigació: xifrat en repòs, retenció configurable i esborrat per `response_id`.

• Tests de contracte del schema: qualsevol `form_version` publicada ha de passar el validador i renderitzar-se sense errors.
• Tests de propietat de la lògica: per a qualsevol combinació de respostes, el camí calculat al client i al servidor coincideix.
• Test d'idempotència: enviar la mateixa `response_id` N vegades produeix una sola fila.
• Mètrica d'acceptació: taxa de compleció i temps mitjà per pregunta mesurats a l'embut; objectiu inicial de referència, no de negoci.
• Càrrega: 500 respostes/s sostingudes amb p95 d'escriptura < 150 ms en entorn de proves.

Fonts: fitxa registral de TYPEFORM SL a OpenMercantil/BORME (https://openmercantil.es/empresa/typeform-sl) i acte BORME d'ampliació de capital de 2022 (https://www.boe.es/borme/dias/2022/06/16/pdfs/BORME-A-2022-114-08.pdf); context del producte a Wikipedia (https://es.wikipedia.org/wiki/Typeform).