Valores del software escandinavo: qué significan realmente para los productos

El software hecho en Escandinavia suele sentirse diferente. Linear. Spotify en sus primeros años. Klarna antes del empuje hacia la salida a bolsa. Tobii. La herencia de diseño que atravesó Superhuman. El navegador Arc. Partes de Notion. iA Writer. Hay un hilo común entre todos ellos: se sienten más silenciosos. Parece que alguien pensó bien los valores por defecto. No gritan.

Nada de esto es exclusivamente escandinavo: hay mucho software tranquilo y bien pensado hecho en otros lugares, y mucho software ruidoso hecho aquí. Pero esta combinación de valores tiende a aparecer en los productos nórdicos más que la media, y la etiqueta nos da algo a lo que referirnos cuando explicamos una decisión de compromiso. Así que cuando decimos "valores del software escandinavo", esto es más o menos lo que queremos decir.

Calma por encima del ruido

El SaaS empresarial al estilo estadounidense es ruidoso por defecto. Las notificaciones emergentes saltan con cada acción. Las ventanas modales interrumpen tu flujo de trabajo para anunciar una nueva función. Cada estado vacío es una oportunidad de venta. El producto trata tu atención como algo que le pertenece, no como algo que toma prestado.

El software tranquilo invierte esto. Las notificaciones son un privilegio, no algo por defecto. Las confirmaciones son discretas. La barra lateral no parpadea para recordarte una función que no tiene nada que ver con lo que estás haciendo. Al iniciar sesión, el producto se aparta y te deja hacer aquello para lo que has venido. Si quieres ayuda, está ahí. Si no, no lo está.

Valores por defecto que funcionan

Mucho software empresarial se lanza con un asistente de configuración. Veinte pantallas de configuración antes de poder hacer algo útil. El mensaje implícito es: somos lo bastante flexibles para hacer cualquier cosa, así que el trabajo de decirnos qué quieres es tuyo.

El instinto escandinavo es el contrario. Nada más empezar, el producto debería resolver el ochenta por ciento del caso de uso sin necesidad de configuración. Los valores por defecto no deberían ser aleatorios: deberían reflejar lo que realmente hace la mayoría de los usuarios. Si perteneces al otro veinte por ciento, puedes cambiarlos. Pero el estudio medio debería poder registrarse, crear una clase y recibir una reserva en menos de diez minutos, sin consultar la documentación.

Para nosotros, esto es un ejercicio constante. Cada valor por defecto en Class Booking es una pequeña opinión. Cuando creas una clase nueva, el plazo límite de reserva se fija por defecto en cuatro horas antes de que empiece la clase, porque cuatro horas es lo que realmente usa la mayoría de los estudios. Cuando creas una membresía, el correo de renovación se envía tres días antes del vencimiento, porque ese es el margen en el que los clientes realmente actúan. Ninguna de estas es una decisión radical. Son simplemente decisiones, tomadas en tu nombre, para que tú no tengas que tomarlas.

Lenguaje sencillo

Mucha interfaz de administración parece escrita por el equipo de ingeniería para el equipo de ingeniería. "Configurar políticas RBAC a nivel de entidad para las suborganizaciones del inquilino." La mitad de los botones son sustantivos sacados directamente del esquema de la base de datos.

Una interfaz en lenguaje sencillo suena como un compañero amable. "¿Quién puede ver esta clase?" en lugar de "Alcance de visibilidad." "¿Qué pasa si alguien cancela tarde?" en lugar de "Configuración de la política de cancelación tardía." Las palabras son más cortas, las frases son más cortas, y quien las lee no necesita un glosario.

"Decir que no a una función es más difícil que decir que sí. El buen software es, en parte, lo que decides no añadir."

Precios honestos

Lo que ves es lo que pagas. Nada de "contáctanos para un presupuesto" para el plan que realmente necesitas. Nada de comisión por transacción escondida detrás del precio principal. Nada de contrato de tres años que se renueva automáticamente a menos que avises con noventa días de antelación.

Esto suena obvio hasta que has lidiado con la alternativa. La mayoría de las plataformas de reservas heredadas anuncian una cuota mensual baja y luego se quedan con entre el uno y el dos por ciento de cada transacción, a veces más. En un año, eso puede duplicar silenciosamente el coste real. Nosotros publicamos nuestros precios en euros. El número que ves es el número que pagas. No cobramos por reserva, por miembro ni por clase.

Y en la misma línea: no tenemos una ventana emergente de venta adicional que aparezca cuando alcanzas el límite de tu plan. Te enviamos un correo. El correo explica qué ha cambiado y cuáles son tus opciones. Puedes ignorar el correo. Nada se rompe.

Contención con las funciones

Decir que sí a una función es fácil. Hay un cliente que la quiere, un ingeniero al que le encantaría construirla y un comercial que podría cerrar un trato con ella. Decir que no es más difícil, y es esa dificultad la que hace bueno al software.

Cada función añadida es una función que hay que mantener, documentar, traducir y explicar a los nuevos usuarios durante el resto de la vida del producto. Es una decisión que el siguiente usuario tendrá que entender en la pantalla de ajustes. El coste no es puntual, se acumula. Por eso decimos que no muchas veces. A integraciones con las que no queremos comprometernos. A interruptores de configuración para cosas que pidieron tres clientes. A la complejidad que nos consigue un trato pero castiga a los siguientes cien usuarios.

Es un trabajo poco vistoso, difícil de poner en una página de funciones. Pero a lo largo de cinco años, marca la diferencia entre un software que se mantiene afilado y un software que va enterrando sus partes útiles bajo una década de añadidos bien intencionados.

Pensamiento a largo plazo

Autofinanciación antes que la rapidez del capital riesgo. Postgres antes que la novedad reluciente. HTML renderizado en el servidor antes que el framework de moda este trimestre. La opción aburrida, en términos de infraestructura, casi siempre es la correcta, porque la opción aburrida lleva el tiempo suficiente en circulación para que sus modos de fallo estén documentados, y porque quienes mantengan tu producto en 2030 te lo agradecerán.

Elegimos Postgres. Elegimos Next.js porque se ha vuelto aburrido de la manera correcta: bien mantenido, predecible, fácil de encontrar talento para trabajarlo. No perseguimos el framework que está en la portada de Hacker News este mes. La opción aburrida es lo que nos permite concentrar nuestra energía en las partes del producto que de verdad importan al usuario, el flujo de reservas, la lógica de membresías, el calendario, en lugar de en una migración trimestral a lo que sea que lo haya sustituido.

RGPD de verdad

El RGPD es ley desde 2018. Mucho SaaS construido en Estados Unidos todavía lo trata como una casilla que marcar. Añadieron un aviso de cookies, escribieron una política de privacidad de una página, y dan el problema por resuelto. Luego llegó la sentencia Schrems II, y tuvieron que añadir a posteriori la residencia de datos para clientes europeos, algo que es muy difícil de hacer una vez el sistema ya existe.

Construir en la UE desde el primer día significa que el RGPD está en la arquitectura, no en el pie de página. Los datos viven en servidores de la UE. El acuerdo de tratamiento de datos es un documento real, no una hoja suelta. Nosotros somos el encargado del tratamiento; el estudio es el responsable del tratamiento; esa distinción está integrada en cómo el sistema piensa sobre los datos de los usuarios. Nada de esto es heroico, simplemente es más fácil hacerlo bien cuando empiezas de cero en Copenhague que cuando lo añades a un sistema que se diseñó pensando en Iowa.

Un pequeño ejemplo concreto

Tenemos un asistente de IA para administradores. Responde preguntas sobre tu estudio: "cuántas reservas tuvimos la semana pasada", "qué clase se está vendiendo mal", ese tipo de cosas. No sugiere, a media respuesta, que subas a un plan superior. No genera textos de marketing que no has pedido. Responde a la pregunta y se detiene.

Puede parecer poca cosa, pero es una decisión. Una filosofía de diseño distinta diría "tenemos tu atención, vamos a monetizarla." Esta dice "has hecho una pregunta, aquí tienes la respuesta, estaremos aquí cuando tengas otra."

Honestos sobre el planteamiento

Una última cosa. "Valores del software escandinavo" es, en parte, un marco de marketing. Lo sabemos. No hay nada mágico en un código postal de Copenhague, y hay mucho software malo hecho en los países nórdicos y mucho software maravillosamente pensado hecho en San Francisco. La etiqueta es una estilización, y la usamos sabiéndolo.

Pero nos gusta el marco porque nos impone una restricción. Cuando le has dicho al mundo que defiendes valores por defecto tranquilos y precios honestos, resulta más difícil añadir una ventana emergente de venta adicional al panel de control, incluso cuando los ingresos van lentos. La etiqueta es un compromiso público, y los compromisos públicos facilitan decir que no a la siguiente mala idea. Esa es la parte que queremos.

Queremos ser tranquilos. Queremos tener buenos valores por defecto. Queremos cobrar de forma justa. Decirlo en voz alta, y ponerle una bandera, es una de las formas en que nos exigimos cumplirlo.