Nuevo proyecto, seguros para autónomos: Save Autónomos

Intuitiva y visual, así es la nueva página de Save Autónomos

Desde Keliam os queremos presentar nuestro último proyecto de desarrollo que hace muy poco ha salido a la luz: Save Autónomos. Nuestro cliente estrena espacio en internet con un diseño único que busca dar un apoyo al ecosistema de los autónomos.

SaveAutonomos.com ofrece un abanico de soluciones para complementar la base de la cotización de autónomos mediante diferentes seguros que abarcan baja laboral, accidentes, enfermedad a partir de 20€.

En menos de 1 minuto introduciendo tu profesión y la fecha de nacimiento podrás tarificar el paquete de seguros que más les conviene según tu actividad.

Un lenguaje sencillo, claro y preciso

Uno de los compromisos de Save Autónomos es la practicidad. Con esta filosofía en mente, la página web tiene un diseño intuitivo y guía al usuario para que resuelva las preguntas más frecuentes cuando se encuentra en la búsqueda de una compañía con la que contratar seguros para autónomos.

Garantizar la tranquilidad del trabajador autónomo es otro de los objetivos de Save Autónomos. De esta forma, todos los trámites y procesos se han simplificado para dar respuesta a las demandas del profesional liberal, un grupo de profesionales que prioriza ser atendido con precisión y eficacia.

Qué es exactamente un tarificador de seguros online

Visto desde fuera, un comparador de seguros parece un formulario con un botón. Visto desde dentro, es una de las piezas de software más exigentes que se pueden poner en una web pública: tiene que devolver un precio correcto, en pocos segundos, consultando sistemas de terceros que no controlas, y hacerlo sin equivocarse ni una vez, porque el precio que muestras es una oferta con consecuencias contractuales.

La cadena tiene cinco eslabones y cada uno introduce sus propios problemas. El usuario aporta un puñado de datos; un motor de reglas los traduce en un perfil de riesgo; ese perfil se envía a las compañías aseguradoras; las respuestas se normalizan para poder compararlas; y, si el usuario decide contratar, hay que firmar, cobrar y dar de alta la póliza dejando rastro de todo el proceso.

Cómo se construye: arquitectura de un comparador

El motor de tarificación

Es el corazón del sistema y el sitio donde más proyectos se tuercen. La tentación es programar las reglas de negocio directamente en el código: si la profesión es X y la edad está entre A y B, aplicar la prima P. Funciona el primer mes. El problema llega cuando la aseguradora cambia el baremo, o entra una compañía nueva, o hay que aplicar un recargo temporal: cada ajuste se convierte en un despliegue.

La alternativa sensata es separar reglas de código. Las condiciones se almacenan como datos —tablas de coeficientes, rangos, exclusiones— y el motor se limita a evaluarlas. Así, actualizar un baremo es cambiar una fila, no tocar la aplicación. Esta es la misma discusión de fondo que planteamos en desarrollo a medida frente a plataforma estándar: cuánto del negocio queda congelado en el código y cuánto puede cambiar sin llamar al programador.

Integración con las aseguradoras

Aquí no hay estándar universal. Cada compañía expone su tarificación como buenamente puede: unas con API REST moderna, otras con SOAP, alguna con un servicio que solo acepta peticiones desde IPs registradas. Los tiempos de respuesta varían de milisegundos a varios segundos y las caídas puntuales son normales.

De ahí que una integración seria necesite, como mínimo, cuatro defensas: timeouts agresivos —si una compañía tarda ocho segundos, se muestra el resto y se avisa—, peticiones en paralelo en lugar de una detrás de otra, caché de resultados para perfiles repetidos dentro de una ventana razonable, y registro completo de cada petición y respuesta, porque el día que un cliente reclame un precio habrá que poder reconstruir exactamente qué se le mostró y por qué.

El formulario, el punto crítico de conversión

El proyecto de Save Autónomos partía de una premisa muy clara: profesión y fecha de nacimiento, y precio en menos de un minuto. Esa decisión de producto es, en realidad, una decisión técnica con impacto directo en negocio. Cada campo adicional en un formulario de tarificación cuesta conversión, y cada segundo de espera cuesta más. Los mismos principios que aplicamos al optimizar el checkout de un ecommerce valen aquí: pedir lo mínimo imprescindible, validar en el momento, no perder nunca lo que el usuario ya escribió y ofrecer siempre un camino de salida cuando algo falla.

Datos personales y seguridad: la parte no negociable

Un comparador de seguros trabaja con datos que no son inocuos: fecha de nacimiento, profesión, situación laboral y, según el ramo, información de salud. Eso convierte al proyecto en un tratamiento de datos personales con obligaciones concretas —minimización, base legítima, plazos de conservación, contratos de encargado de tratamiento con cada compañía— y en un objetivo atractivo para cualquiera que busque una base de datos con valor de reventa.

El suelo mínimo de cualquier plataforma de este tipo es el que describimos en seguridad informática para pymes desde cero: cifrado en tránsito y en reposo, doble factor en todos los accesos administrativos, actualizaciones al día, copias de seguridad verificadas y permisos revisados con regularidad. Sobre esa base, y antes de abrir al público, una auditoría de seguridad y pentesting es dinero bien gastado: es mucho más barato encontrar un fallo de control de acceso en pruebas que en producción.

Para startups que aspiran a cerrar acuerdos con aseguradoras grandes, hay un tercer nivel: la certificación. Las compañías del sector envían cuestionarios de seguridad a sus partners tecnológicos, y llegado cierto tamaño la conversación deriva hacia la ISO 27001 y su coste real para una pyme. A esto se suma un marco normativo que se ha endurecido: conviene revisar si el proyecto entra en el alcance de NIS2 y sus obligaciones para empresas tecnológicas, muchas veces por vía indirecta, como proveedor de una entidad ya obligada.

El sector insurtech español, cinco años después

Cuando lanzamos este proyecto, en enero de 2021, el seguro digital español era todavía un nicho reducido. El panorama ha cambiado bastante. Según el mapa del ecosistema insurtech español, al cierre de 2025 había 107 compañías insurtech activas, que daban empleo a unas 2.357 personas y facturaban en conjunto 171 millones de euros. El número de empresas creció un 64,6 % respecto al ejercicio anterior.

La concentración geográfica sigue el patrón esperable: Madrid encabeza con 42 compañías, seguida de Barcelona con 17. Y dentro del sector, el segmento de distribución —agregadores y comparadores, exactamente la categoría de Save Autónomos— es el más maduro de todos, con la inversión concentrada en cloud, aplicaciones móviles y plataformas de agregación, por delante de big data, inteligencia artificial, IoT o blockchain.

La tendencia que más recorrido tiene por delante es el embedded insurance: integrar la contratación del seguro dentro del propio proceso de compra de otro producto o servicio, en lugar de obligar al usuario a ir a un comparador. Técnicamente, eso desplaza el foco del formulario propio a la API bien documentada, porque el tarificador deja de ser una web y pasa a ser un servicio que consumen terceros.

Qué aprendimos de este proyecto

Con la perspectiva de los años, hay cuatro conclusiones que seguimos aplicando en proyectos parecidos:

• La simplicidad del formulario es una ventaja competitiva, no una limitación. Pedir dos datos en lugar de doce fue la mejor decisión de producto del proyecto, y obligó a resolver por dentro lo que se le ahorraba al usuario por fuera.
• La infraestructura importa tanto como el código. Un tarificador que responde en tres segundos y otro que responde en doce son el mismo software con distinta arquitectura de servidores, caché y red. Buena parte del trabajo estuvo ahí.
• Las integraciones con terceros envejecen. Las APIs de las aseguradoras cambian, se deprecan y se caen. Cualquier proyecto que dependa de sistemas externos necesita un plan de mantenimiento continuado, no una entrega y adiós. Es la razón por la que ofrecemos mantenimiento de software como servicio continuo.
• Un MVP bien construido no es un prototipo desechable. Se puede salir rápido al mercado sin hipotecar la arquitectura, si se decide desde el principio qué partes son provisionales y cuáles no. Lo desarrollamos en servicios IT para startups: del MVP a un producto escalable.

Y una quinta, menos técnica: no todos los proyectos digitales sobreviven, y eso forma parte del oficio. Que una plataforma deje de operar años después no invalida el trabajo de ingeniería que la sostuvo mientras estuvo en marcha, ni las decisiones que resultaron acertadas. Contar también estos casos nos parece más honesto que retirar el artículo del blog.

Errores frecuentes en proyectos de comparadores

Después de varios proyectos con esta forma —comparadores, configuradores de producto, calculadoras de presupuesto—, los tropiezos se repiten con una regularidad casi cómica. Estos son los cinco más caros:

• Tratar la tarificación como un cálculo y no como un contrato. El número que se muestra en pantalla tiene efectos comerciales. Si no queda registrado qué versión de las reglas lo generó, cualquier reclamación posterior se convierte en la palabra de uno contra la del otro. La trazabilidad no es un extra de auditoría: es parte del producto.
• Consultar las aseguradoras en serie. Es el patrón natural al programar y el peor posible para el usuario: cinco compañías a un segundo y medio cada una son siete segundos y medio de espera. En paralelo, son dos. La diferencia entre ambos escenarios es medible directamente en conversión.
• No prever el modo degradado. Antes o después, una compañía dejará de responder. Si el sistema no sabe seguir sin ella —mostrando el resto de resultados y avisando de que falta una—, un fallo ajeno tumba el producto entero.
• Guardar más datos de los necesarios «por si acaso». Cada campo que se almacena y no se usa es riesgo puro: amplía la superficie de exposición, complica el cumplimiento y no aporta nada. La minimización de datos, además de ser una obligación legal, simplifica el sistema.
• Dejar el SEO para el final. Un comparador vive del tráfico orgánico de búsquedas muy concretas. Si toda la comparativa se renderiza en el navegador después de una llamada asíncrona y no queda nada indexable en el HTML, el producto es invisible para Google. Esto se decide en la arquitectura, no en una revisión posterior.

Ninguno de los cinco es un problema de programación complicado. Todos son decisiones que hay que tomar al principio, cuando cambiarlas cuesta una conversación en lugar de una refactorización.

Preguntas frecuentes

¿Cuánto se tarda en construir un tarificador online?

Depende casi por completo de las integraciones. La parte visible —formulario, comparativa, contratación— es previsible. Lo que dilata los plazos es negociar accesos con cada aseguradora, entender su documentación y adaptarse a su formato. En proyectos reales, esa parte suele consumir más de la mitad del calendario.

¿Es mejor un desarrollo a medida o una plataforma existente?

Si las reglas de negocio son estándar, una plataforma ahorra tiempo. Si el valor del producto está precisamente en cómo se calcula o se presenta el precio, esa lógica acaba siendo el producto y conviene controlarla. Es el mismo criterio que aplicamos en cualquier proyecto: externalizar lo que es infraestructura, controlar lo que es diferencial.

¿Qué pasa si una aseguradora cambia su API?

Pasa, y con más frecuencia de la que nadie espera. Por eso la integración se aísla detrás de una capa propia: cuando la compañía cambia, se adapta ese conector y el resto del sistema no se entera. Sin esa separación, cualquier cambio externo se propaga por todo el código.

¿Hace falta una auditoría de seguridad antes de lanzar?

En cualquier plataforma que maneje datos personales sensibles y dinero, sí. El coste de una revisión previa es una fracción del coste de un incidente, y en el sector asegurador el daño reputacional pesa más que el técnico.

¿Podéis haceros cargo de una plataforma que ya existe?

Es una parte importante de nuestro trabajo. El primer paso siempre es una auditoría técnica para saber en qué estado están el código, las integraciones y la infraestructura, y a partir de ahí decidir qué se mantiene, qué se rehace y en qué orden.

Actualización — Agosto de 2026

Save Autónomos ya no opera: su dominio no resuelve y la plataforma no está accesible. Hemos retirado del artículo los enlaces que apuntaban al sitio para evitar que los lectores acaben en una página inexistente, y mantenemos el resto del contenido original tal como se publicó.

Este proyecto sigue siendo un buen ejemplo del tipo de desarrollo a medida que hacemos en Keliam: plataformas web que resuelven una necesidad concreta de un nicho de mercado, con una experiencia de usuario cuidada, integraciones con sistemas de terceros y un stack técnico mantenible a largo plazo. Si estás construyendo algo parecido —un comparador, un configurador, un tarificador o cualquier producto que dependa de reglas de negocio complejas y APIs externas—, es exactamente el terreno en el que trabajamos.

Conclusión

Un comparador de seguros es un buen recordatorio de que la parte visible de un producto digital —un formulario de dos campos y un precio— suele ser la punta de un trabajo de ingeniería considerable: reglas de negocio separadas del código, integraciones defensivas con sistemas que no controlas, rendimiento medido en segundos y un tratamiento de datos personales que no admite atajos.

Si estás valorando un proyecto de este tipo, o tienes una plataforma en marcha que necesita mantenimiento, integraciones o una revisión técnica seria, cuéntanoslo y vemos en qué podemos ayudarte.