De la idea a los primeros usuarios de pago: cómo lanzamos un SaaS B2B

Llegó con una hoja de cálculo, una corazonada y un plazo que el congreso de su sector le había impuesto sin preguntarle. En cuatro meses estaría en un pequeño escenario ante unas doscientas personas que dirigían exactamente el tipo de empresa al que su idea pretendía servir. Quería poder mostrarles algo real: ni diapositivas ni un mockup, sino un producto en el que un desconocido pudiera entrar y pagar. Con esa conversación empieza este caso, y lo más útil de él es lo corriente que era el punto de partida.

Hemos cambiado los detalles identificativos a propósito. La fundadora es real, el producto está en marcha y las cifras se acercan a la verdad, pero están redondeadas y suavizadas para que nadie pueda deducir de quién se trata. Lo que importa no es el nicho concreto, sino la forma del recorrido, porque esa forma se repite casi siempre que un fundador no técnico intenta convertir una buena idea en software que funcione. Si usted está más o menos al principio de ese camino, así es como pueden ser los próximos meses cuando sale bien.

La versión corta: un sector que conocía a fondo, un proceso manual penoso que todos en él toleraban, una hoja de cálculo con la que lo hacía discretamente mejor que sus colegas y cero formación técnica. Once semanas de trabajo concentrado después, llegaron los primeros usuarios de pago. Aquí está cómo y, con más honestidad, aquí está dónde tropezamos.

La situación: una hoja de cálculo haciendo un trabajo real

La fundadora dirigía una pequeña consultoría en un campo regulado y cargado de documentación. Sus clientes eran otras pequeñas empresas, y todas ellas lidiaban con la misma tarea recurrente: reunir un montón de formularios, comprobar que estuvieran completos, perseguir lo que faltaba y elaborar un resumen limpio antes de un plazo. La mayoría de sus competidores lo hacían con correos, llamadas y una carpeta de plantillas de Word. Ella lo hacía con una hoja de cálculo que había construido y refinado durante cuatro años, y sus clientes la adoraban en silencio por ello.

Esa hoja de cálculo era toda la clave. No era un plan de negocio ni un análisis de mercado: era una prueba. La gente ya dependía de su herramienta, le pedían que la usara para empresas que ni siquiera asesoraba, se ofrecían a pagar solo por el acceso. Cuando los clientes intentan comprar algo antes de que lo haya construido, puede dejar de adivinar si hay demanda. La pregunta nunca fue si valía la pena hacerlo. La pregunta era si esto podía convertirse en software que otra persona pudiera usar sin que ella estuviera sentada a su lado.

Sus restricciones eran igual de reales. Un presupuesto fijo que salía de sus propios ahorros, no de un fondo. El plazo del congreso. Y una regla firme que acordamos pronto: esto no podía convertirse en un proyecto que exigiera su atención cada día, porque seguía teniendo una consultoría que dirigir. Lo que construyéramos tenía que ser terminable, asequible y aburrido de operar. Esas tres palabras moldearon cada decisión que siguió.

El primer trabajo fue decidir qué NO construir

Cuando los fundadores describen su producto soñado, la lista de funciones siempre es enorme, porque llevan años imaginándolo. La suya llenaba dos páginas: paneles, permisos de equipo, un registro de auditoría, recordatorios automáticos, un portal para clientes, facturación, analíticas, integraciones con tres herramientas que usaban sus clientes y, por supuesto, «algo de IA por ahí dentro». Cada punto era razonable. Construirlos todos antes del lanzamiento habría sido un desastre.

Así que hicimos el ejercicio que hacemos con todos: para cada función nos planteamos una única pregunta tajante. Si esto faltara el día del lanzamiento, ¿se negaría un cliente a pagar? No «sería más bonito con ello», sino si la venta moriría de verdad. La mayoría de las funciones suspenden esa prueba, y de eso se trata. Las que sobreviven son su producto real. Todo lo demás es una hoja de ruta, algo encantador de tener, pero no lo que se construye primero.

Lo que sobrevivió era casi vergonzosamente pequeño. Un usuario podía crear una cuenta, configurar un expediente, invitar a su cliente a subir los documentos requeridos y recibir el mismo resumen limpio y comprobado que producía su hoja de cálculo, salvo que de forma automática y sin ella de por medio. Eso era todo. Sin paneles. Sin roles de equipo. Sin IA, todavía. Cuatro funciones, un trabajo claro, hecho como es debido.

Lo que construimos realmente en once semanas

Trabajamos en ciclos cortos y visibles, en lugar de desaparecer tres meses y volver con una sorpresa. Más o menos cada semana, la fundadora recibía un enlace a algo que podía clicar, aunque fuera feo y estuviera a medio conectar. Ese ritmo importa más de lo que parece: mantenía sus decisiones pequeñas y frecuentes, en vez de dejar que se amontonaran en una única revisión aterradora al final.

Semanas 1–3: la columna vertebral

Primero construimos el núcleo poco glamuroso: cuentas, una forma segura de almacenar documentos y el modelo de datos bajo el flujo de los expedientes. Nada de esto es visible para un cliente, y todo ello es la parte cara de arreglar más tarde si se hace con prisas. Como el producto manejaba la documentación sensible de otras empresas, tratamos el control de acceso y la separación de datos como un requisito de lanzamiento, no como una mejora posterior. Es uno de los pocos puntos donde nos negamos a recortar.

Semanas 4–7: el trabajo de verdad

Luego la parte que hacía que valiera la pena pagar: convertir la lógica de su hoja de cálculo en el motor que comprueba que los documentos estén completos y produce el resumen. Este era el corazón del producto y le dimos el mayor tiempo. Nos sentamos con ella y desmontamos por qué existía cada regla de su hoja de cálculo, y varias resultaron ser hábitos más que requisitos, lo que nos permitió simplificar. Al final de la semana siete, se podía ejecutar un expediente real de principio a fin.

Semanas 8–11: hacerlo seguro para cobrar

La última recta fue la diferencia entre una demo y un producto. El pago, para que la gente pudiera suscribirse de verdad. Un registro limpio que no necesitara un manual. La docena de pequeños estados de error que deciden si un desconocido confía en su software o se marcha. Y las pruebas (aburridas, repetitivas) con la fundadora y dos clientes amables que aceptaron romperlo a propósito antes de que lo hicieran los desconocidos. Ese último grupo se ganó su descuento de acceso anticipado con creces.

La pregunta de «mételo algo de IA», respondida con honestidad

Su lista de deseos tenía IA, como la tienen ahora casi todas. Le replicamos, y vale la pena explicar por qué, porque es el mismo consejo que damos a casi todo el mundo. El trabajo que la versión uno necesitaba hacer (comprobar un conjunto conocido de documentos contra un conjunto conocido de reglas) es un trabajo que las reglas hacen mejor que la IA. Es predecible, es auditable, y cuando un cliente regulado pregunta «¿por qué el sistema marcó esto?», usted quiere una respuesta clara, no un encogimiento de hombros.

Eso no significa que la IA no tuviera lugar. Había un problema genuinamente caótico, de naturaleza lingüística, escondido en el flujo: los clientes a menudo subían documentos casi correctos pero mal etiquetados, o pegaban información como texto libre en lugar de rellenar el formulario. Leer ese desorden y ordenarlo es exactamente en lo que la IA moderna es buena. Así que lo anotamos con cuidado y luego lo dejamos para la versión dos. Añadirlo antes del lanzamiento habría retrasado el plazo para pulir una función que nadie había pedido aún pagar.

Conseguir los primeros usuarios de pago

Aquí está la parte que más preocupa a los fundadores y para la que menos se preparan. Un producto que nadie puede encontrar no es un negocio, es un pasatiempo. Pero esta fundadora tenía una ventaja que valía más que cualquier presupuesto de marketing: ya tenía una audiencia que confiaba en ella, y algunos le habían pedido pagar antes de que el software existiera. El plan de lanzamiento se apoyó por completo en eso, y el suyo también debería si lo tiene.

En lugar de un lanzamiento público aparatoso, hicimos lo contrario: uno silencioso y deliberado. Dos semanas antes del congreso, escribió a la puñada de clientes que ya habían preguntado, les ofreció precio de miembro fundador y los incorporó a mano, observando por videollamada cómo lo usaban. Cada confusión se convirtió en una corrección. Cuando se subió a aquel escenario, no estaba vendiendo una idea; estaba describiendo software por el que sus colegas ya pagaban, y podía decirlo con honestidad.

1. 1
   Empiece por quienes ya están preguntando

   Su primer contacto fue solo a clientes que antes se habían ofrecido a pagar. La demanda cálida convierte antes de que la fría siquiera responda.
2. 2
   Incorpore a mano a los primeros

   Sin heroicidades de autoservicio al principio. Acompañó en directo a cada usuario inicial, convirtiendo cada punto de confusión en una corrección concreta.
3. 3
   Precio para fundadores, no para siempre

   Los primeros usuarios tuvieron una tarifa de fundador claramente limitada en el tiempo. Premiaba su riesgo y daba a los clientes posteriores una razón de por qué subían los precios.
4. 4
   Use el plazo como lanzamiento

   El congreso no fue un truco de marketing añadido después: fue la función forzadora que mantuvo el alcance honesto todo el camino.

El resultado, y lo que de verdad significa

Al final del mes de lanzamiento, el producto tenía sus primeros suscriptores de pago: un número pequeño, del tipo que aún se cuenta con dos manos, cada uno una empresa real pagando una cuota mensual real. Suena modesto, y lo es. También es el hito más difícil de toda la vida de un producto de software. Pasar de cero clientes de pago a unos pocos es mucho más difícil que pasar de unos pocos a muchos, porque es el momento en que la idea deja de ser suya y se convierte en la del mercado.

Las cifras de abajo son ilustrativas y redondeadas, pero son fieles a la forma de lo que ocurrió. Lo que queremos que extraiga de ellas no son los números, sino las proporciones. Una primera versión bien acotada, un presupuesto pequeño y enfocado, un plazo corto y un lanzamiento apuntado a la demanda cálida en vez de a todo internet.

En qué nos equivocamos

Un caso de estudio que solo enumera triunfos es un anuncio, así que aquí está la parte honesta. Cometimos dos errores que vale la pena nombrar, porque usted sentirá la tentación de los mismos.

Primero, subestimamos la incorporación. Habíamos acotado el producto con cuidado, pero tratamos los primeros cinco minutos de la experiencia de un usuario nuevo como algo secundario, algo que ordenar al final. Resultó ser el momento decisivo, y pasamos una semana no planificada reconstruyendo el registro y la primera pantalla vacía para que un desconocido pudiera entender qué hacer sin que se lo dijeran. La próxima vez, la experiencia de primer uso es una función desde el día uno, no desde la semana diez.

Segundo, dejamos que una regla «pequeña» del motor de comprobación se desbordara. La fundadora mencionó un caso límite casi de pasada, acordamos que era fácil, y consumió en silencio tres días porque los datos del mundo real eran más caóticos de lo que su hoja de cálculo limpia jamás reveló. La lección no fue «evite los casos límite», sino que su hoja de cálculo había estado haciendo en silencio una limpieza manual que ella había olvidado que hacía. El software tiene que hacer visible ese trabajo invisible, y eso siempre cuesta más de lo que nadie espera.

Si usted está donde estaba ella

Lo que hizo que esto funcionara no fue una arquitectura ingeniosa ni una herramienta de moda. Fue disciplina con el alcance y honestidad sobre la demanda. Ella tenía la prueba de que la gente lo quería antes de que escribiéramos una línea de código, y fuimos implacables construyendo la versión más pequeña por la que alguien aún pagaría. Ninguna de esas cosas requiere formación técnica. Ambas son cosas que usted puede empezar esta misma semana, por su cuenta.

Si tiene una hoja de cálculo que la gente le pide ejecutar una y otra vez, o un proceso manual por el que sus clientes le dan las gracias, quizá esté más cerca de un producto de lo que cree. La jugada peligrosa es imaginar la versión acabada y completa de funciones y paralizarse por lo grande que parece. No lo haga. Encuentre el único trabajo que debe hacer sí o sí, construya solo eso y póngalo delante de quienes ya están preguntando. La hoja de ruta puede esperar. El primer usuario de pago no.

Preguntas frecuentes