Ignacio Arriaga · 02/06/2023

No se programar y quiero montar un SaaS

No se programar y quiero montar un SaaS

Índice

Lo primera decisión importante que debes tomar es la de hasta donde quieras llegar con tu software. Y en esto hay que ser realistas y sinceros. Es fácil decirte a ti mismo que quieres hacer una empresa que facture millones cuando lo que realmente quieres es pillar 30.000€ para pagar la entrada de la hipoteca el año que viene.

Si lo que buscas es montar un empresón que pueda crecer, tener un equipo y hacer millones de facturación al año, al final sí o sí, vas a tener que pillar un equipo técnico. Si lo que quieres es hacer un joseo internetero y sacarte unos miles con un microsaas, hay varias cosas que puedes probar.

Quiero montar una empresaca

Cada vez veo más personas que intentan montar un SaaS sin tener un cofundador técnico o sin ser técnicos (breve recordatorio sobre que los técnicos podemos ser CEOs y gestionar la parte business de una empresa tan bien como cualquiera). Creo que es un error si lo que pretendemos es crear una empresa grande.

En muchos casos la tecnología es una commodity, pero en el SaaS no lo es tanto. Hay muchos elementos diferenciales –por ejemplo el diseño– que hacen que las bases que sentemos al principio puedan marcar el devenir de nuestra empresa.

En este caso externalizar –sea en forma de consultoría o de no-code– la tecnología crear una deuda técnica que luego puede ser difícil de superar. Lógicamente hay gente que sale de ello, pero a largo plazo, cuando se quiera retomar el mando, puede ser complejo de solucionar.

¿Cómo puedo luchar contra la deuda técnica?

La deuda técnica es el famoso dicho de "lo barato sale caro" llevado al desarrollo software. Cuanto más rápido y de forma más barata se desarrolla algo, más probabilidades hay de que sea una bastilla inmantenible. Y el mantenimiento, en un producto sobre el que va a iterar todo el modelo de negocio de una empresa, es bastante importante.

Hay estrategias para evitar la deuda técnica al subcontratar pero suponen estar muy encima del desarrollo y, para eso, te hace falta un técnico. Hay una teoría preciosa que es la de únicamente subcontratar el MVP para luego, cuando vaya bien la cosa, meter a un equipo técnico a reescribirlo por completo. Es muy improbable que un producto se reescriba y más improbable aún que esa nueva versión llegue nunca a producción.

Un buen consejo es que, si al final te decides por subcontratar, desarrolles únicamente lo imprescindible para conseguir facturar y, posteriormente, trates de recuperar el desarrollo con un equipo interno. Este consejo es bonito, pero decidir qué es lo imprescindible no es, para nada, un problema de fácil resolución.

No hablo de que tengamos que utilizar DDD o arquitecturas hexagonales o la que sea la moda de ahora. Nosotros llevamos diez años aquí y no hemos usado nada de eso. Pero sí que tener a alguien técnico dentro del equipo te va a ayudar a tomar buenas decisiones o, al menos, a saber cómo de malas son las que estás eligiendo para correr más.

Me apetece probar e intentar sacarme unos eurillos

La realidad es que hay varias formas de conseguir algo de cash rápido con un SaaS. Seguramente la más sencilla es publicarlo en Appsumo y otros marketplaces similares. Ya he conocido varias personas que fantasean con hacer un producto pequeñito y probar en appsumo a ver si consiguen sacar algo de pasta.

Para esas personas, se me ocurren estas opciones, de más cara a más barata:

  • Subcontratar el desarrollo: hay empresas, que facturan millones, que subcontratan todas las labores tecnológicas. Yo conozco varias y, aunque a mí me costaría hacerlo, ellos están muy contentos con el resultado. Hay gente que, para abaratar más, subcontrata a otros países: India es un clásico en todo esto. Mi amigo Víctor Correal subcontrata toda la tecnología de todos sus proyectos y, el más tocho que es GuideDoc, no es precisamente un autoempleo. Mi estimación es que para un prototipo de un SaaS sencillo, te puedes gastar tranquilamente unos diez mil euros.
  • No-code: las herramientas no-code te permiten crear productos sin necesidad de programar. Esto hace que puedas, teóricamente, desarrollar un SaaS sin involucrar perfiles técnicos. Mi opinión sobre utilizar este tipo de herramientas es que pueden ser útiles para realizar un pequeño experimento. El problema es que tienen menos flexibilidad que algo hecho a medida y, a no ser que seas un genio, vas a tener que realizar muchas modificaciones sobre tu MVP. Además, si tu SaaS tiene un relativo éxito, el coste de mantener estas herramientas puede ser elevado. Por no hablar del riesgo que corres haciendo que tu herramienta dependa de un tercero que puede cerrar y dejarte sin negocio. Cuesta unos cientos de euros al mes.
  • Utilizar un producto ya hecho: puedes intentar vender un software que sea open source o comprar un clon de algún software famoso e implantarlo para venderlo. La parte buena es que la mayoría de los softwares son commodities, por lo que si eres capaz de generar un buena distribución teóricamente podrás tener bastante éxito. Las partes malas son que, si algo existe en un modelo open source o disponible a la venta, seguramente será un mercado bastante saturado. Por otro lado, vas a necesitar un técnico para ponerlo en producción, sea Open Source o no. Comprar un clon de un producto puede costarte unos cientos de euros.
  • Revender un producto existente: hay muchos productos que tienen un programa para revender y ofrecen márgenes de más del 50%. Lógicamente se reduce mucho el margen, pero también la complejidad. Conozco a resellers de Active Campaign, que están generando unos cientos de miles de euros al año. La oferta alrededor de este tipo de negocio suele ser un soporte más premium o una distribución diferente. Lo bueno es que no tienen un gasto inicial. Lo malo es que se pierde totalmente el control sobre lo que se está vendiendo.
  • Comenzar utilizando un boilerplate de SaaS: un boilerplate es un precocinado que ya tiene desarrolladas muchas cosas que teóricamente son iguales en todos los SaaS. Lo habitual es que ya incluya un sistema para gestionar usuarios, equipos, suscripciones, etc. Puede permitir acelerar el desarrollo. Pero igualmente se necesita un técnico que desarrolle el resto de las funcionalidades.

En resumen

Si quieres desarrollar un SaaS, no eres técnico y quieres jugar a largo plazo, la mejor opción es que busques a alguien que sí lo sea y se una a tu equipo desde el principio. Te ahorrarás bastantes problemas y cualquiera de las formas rápidas de creación de un MVP estarán más controladas con un técnico al cargo.

En el caso de que quieras seguir por tu cuenta sí o sí, puedes probar el no code, el outsourcing e incluso intentar vender productos open source o que permitan su reventa. Si lo haces debes tener en cuenta que el comienzo será más sencillo, pero que la flexibilidad que tengas va a ser mucho menor y el riesgo de depender de un tercero o de un desarrollo que no controlas será alto.

Si sabes lo que significa el número 83333, esta newsletter es para ti *

* Si no lo sabes pero te interesa el mundo del software: debes suscribirte y lo descubrirás inmediatamente.