Consejos a la hora de crear una primera versión de un SaaS

Analizando qué partes del proceso del ciclo de vida del software había tratado y cuáles no en la newsletter, me he dado cuenta de que no he dedicado ni un solo número a cómo construir un SaaS. Algo sorprendente para un perfil técnico como yo que, además, disfruto mucho más en la etapa de la creación que en ningúna otra. Así que aquí van algunos consejos que pueden ayudarte a la hora de crear una primera versión de tu SaaS.

MVP: la m es de mínimo no de mierda

Un MVP es un producto mínimo viable, pero no tiene por qué ser una cutrez. No vas a tener el mejor diseño ni la mejor implementación, pero que el producto funcione y medianamente fácil de usar está incluido en la palabra mínimo.

El diseño de Stripe era una basura cuando lanzaron su primera versión. Pero fue en 2011. Tener una apariencia mínimamente decente entra dentro de la M de MVP. No hablamos de invertir una tonelada de pasta en diseño en la primera versión, pero sí de que la web se lea y de que la interfaz sea mínimamente usable.

Es cierto que la rapidez promueve el uso de patrones de diseño conocidos y eso está haciendo que cada vez se innove menos en el diseño. Mi consejo, en una primera versión la reutilización de cosas que funcionen es tu amiga. Y si eres un diseñador de la hostia y quieres innovar hazlo en la parte que es realmente core de tu negocio. Si quieres reinventar algo, que sea lo que da valor al producto. Los formularios de registro no están en esa categoría.

Céntrate en una única cosa y hazla bien

Tu producto tiene que hacer una cosa bien. Ni siquiera hace falta que haga excepcionalmente bien en la primera versión. Lo suficiente como para que no te dé demasiada vergüenza ponerle precio y venderla. La mejor validación es intercambiar tu servicio por dinero. Aunque esto haga que muchas menos personas lo utilicen, vale muchísimo más el feedback de diez personas que estén dispuestos a pagar que el de mil personas que no. Un producto que no permite a los clientes pagar por él no es un negocio, es un hobby.

Es difícil decidir qué incluir y qué no en una primera versión pero no tienes que machacarte con eso. Mi consejo es que elijas un solo problema específico y, en cuanto tu producto lo resuelva con algo de solvencia, lo saques a producción. No te obsesiones con tener una versión con muchísimas funcionalidades. Vas a vivir en una versión beta durante años, por lo que cuanto antes lo aceptes y empieces a desplegar cosas, mejor.

Seguramente una parte muy pequeña de tu producto será la que proporcione el valor al usuario. Pero vas a tener que construir mucho alrededor. Intenta invertir la mayor parte del tiempo donde vas a dar el valor. Externaliza o utiliza soluciones ya cocinadas para el resto. Hay herramientas para casi todo lo accesorio y la mayoría te van a hacer un descuentazo durante años si les dices que eres una startup.

El feedback como herramienta, no como imposición

Salvo en procesos críticos, los usuarios son tolerantes con los fallos. Mejor lanzar rápido y que se rompan cosas que no sacar nada para sacar un producto perfecto.

El cliente no siempre tiene la razón. Sobre todo al principio, cuando eres pequeño, vas a estar tentado de construir muchas cosas a medida para que los clientes adopten tu solución. Mi consejo: construye solamente cosas que vayan a proporcionar valor a un buen número de clientes. No hagas adaptaciones individuales salvo que quieras financiarte vendiendo desarrollos a medida. Muchas empresas acaban secuestradas por algún cliente muy grande. Piensa que cualquier cliente puede abandonarte y que si la supervivencia de tu empresa depende de un único canal de ingresos estás en una relación asimétrica en la que tienes mucho que perder.

Esto no significa que no escuches al cliente. No construir soluciones a medida no significa que no tratar de entender por qué son necesarias para los clientes. En las fases iniciales el objetivo de producto es entender un problema, no solucionarlo. Tú vas a proponer una solución y tus clientes te van a ayudar a mejorarla o a cambiarla. Por eso es muy importante abrir canales de comunicación con ellos.

Los datos no te van a ayudar en estas fases iniciales. Vas a tener que confiar en tu instinto y en el feedback cualitativo porque cualquier estadística cuantitativa que puedas conseguir va a ser totalmente irrelevante. Esto no significa que no midas. Medir es útil para modelar un mapa mental del producto y para instaurar una cultura de los datos que te será útil en el futuro. Pero la información que vas a obtener, salvo milagros o catástrofes, te va a servir de poco.

La sobre optimización: la parálisis por análisis del desarrollo

A no ser que el objetivo que tiene tu software es optimizar, no optimices. Por lo general vas a optimizar partes que no lo requieran y va a ser muy difícil que preveas dónde van a estar tus verdaderos cuellos de botella.

¿Vas a necesitar que tu software escale? Ojalá. Pero lo más normal es que tengas que darle muchas vueltas al producto hasta que llegue este problema. Sharding, escalabilidad horizontal, microservicios y demás pueden esperar. De verdad.

Sobre la infraestructura: vas a necesitar muchísima menos de la que crees. De verdad que un servidor podrido va a poder con lo que necesite tu SaaS durante una buena temporada. Preocuparse de esto también es sobreoptimizar.

Un stack tecnológico trendy, ¿problema o solución?

No te hace falta el último stack tecnológico para crear un SaaS. Mi consejo es que vayas hacia tecnologías libres y, sobre todo, que tengan un montón de comunidad. Busca algo que ya lleve unos años, las primeras versiones de los frameworks tienden a cambiar muy rápido y a romper compatibilidades hacia atrás. Pero, lo más importante: elige algo que ya domines. Vas a tener muchos problemas, intenta que pelearte con tu stack tecnológico no sea uno más.

Mucha gente me dirá que los buenos desarrolladores quieren programar en las últimas tecnologías. Es posible, pero no debemos olvidar que hay que diferenciar entre buenos desarrolladores y los desarrolladores famosos. En las cárnicas hay buenísimos desarrolladores programando en lenguajes de los de toda la vida y con condiciones mucho peores que las que hay en las startups. No todo el mundo tiene que fichar a desarrolladores que hayan currado en Google.

Todos hemos caído en utilizar algunas de las últimas tendencias que trae el mercado. Cuando nosotros lanzamos eran las bases de datos NoSQL. Ahora será la IA o vete tú a saber. No retuerzas el producto o la tecnología para utilizar algo trendy. Seguramente acabes quitándolo en unos años.

Las buenas prácticas se llaman así por algo

Pieter Levels tiene todo su código en un único fichero php y le ha ido de la hostia. Pero seguramente le haya ido de la hostia a pesar de tener todo su código en un solo fichero, no por ello. La gente que ha tenido éxito con prácticas de mierda son un ejemplo del sesgo del superviviente. Muchísima gente ha palmado por las prácticas de mierda. Hacer las cosas medio bien cuesta lo mismo que hacerlas mal.

Otro problema es la sobrecontratación, sobre todo en empresas con financiación. Para hacer una versión inicial es mejor mantener un equipo pequeño. Vas a cambiar de idea y vas a darle muchas vueltas radicales al producto al principio. Mantener un equipo grande alineado y motivado en todos esos giros de timón es complicado.

"Es una primera versión, luego lo reescribiremos entero" es una gran mentira. Si el asunto coge tracción no vas a tener tiempo de reescribir nada porque estarás en otras cosas mucho más importantes. Si no la coge tampoco lo vas a hacer porque utilizarás otra idea. Intenta hacer que todo sea mínimamente decente desde el principio. Es imposible que sea perfecto, pero haz las cosas como si no fueran a ser provisionales, porque no lo serán.