De técnico a founder: cómo vendimos un “SaaS” que en realidad era un PDF
Vendimos nuestro producto SaaS sin tener nada montado. Así, como lo oyes.
Queríamos crear un producto de reporting financiero pero:
- No había infraestructura
- No había repos
- No había base de datos
La realidad es que, por no haber, no había “stack” elegido. Y aun así, conseguimos nuestros primeros clientes.
Sin nada montado, ya teníamos una promesa hecha al mercado y una fecha de entrega: en mes y medio nuestros primeros usuarios tenían que recibir valor.
¿El “producto” en ese momento? Un PDF hecho a mano, mensual, con insights financieros.
Habíamos prometido un software. Una plataforma. Y nuestro problema principal, el que lo empujaba todo, era cambiar ese PDF por una app antes de que el tren nos pasara por encima.
Esta es la historia de mi primer tango como fundador técnico: pasar de liderar equipos y tomar decisiones de ingeniería a montar un producto desde cero mientras tomas decisiones empresariales con dos recursos que se te escapan de las manos: tiempo y dinero.
En nuestras etapas previas, trabajando cerca de consultoras y agencias, empezamos a ver un patrón repetido: se centraban mucho en la entrega, pero tenían poca visibilidad financiera. Y eso, en negocios donde el margen es muy justo y trabajas por proyectos, es fundamental para no perder dinero.
En empresas de tamaño “medio” (las típicas que ya facturan bien, pero no lo suficiente como para justificar un departamento de finanzas), tener un perfil financiero dedicado no salía a cuenta. Y aun así, la necesidad estaba ahí: entender el margen real de cada proyecto, prever caja, decidir cuándo contratar, cuándo frenar, cuánto invertir, O encontrar qué clientes te están drenando energía y rentabilidad.
Ahí fue cuando empezamos a preguntarnos si tenía sentido crear un sistema que cubriera justo ese hueco: una especie de dirección financiera accesible, conectada a tus herramientas, que te traduzca los números al idioma del negocio y te ayude a decidir sin tener que convertirte en experto.
Ahí es cuando creamos Sherpa.
Sherpa Platform pretendía:
- 💰 Automatizar el procesamiento de datos: consolidar extractos bancarios, integrar información contable y generar reportes sin depender de hojas de Excel.
- 📈 Generar informes dinámicos y personalizados: entregar a cada cliente reportes claros y adaptados a sus necesidades sin consumir horas de trabajo manual.
- 🔢 Gestionar proyecciones y KPIs de manera confiable: analizar datos en tiempo real, minimizar errores y ofrecer decisiones financieras basadas en información sólida.
Sobre el papel, todo pintaba genial.
Moviendo los primeros pasos con el Mago de Oz
Yo llevaba ya unos años sin “picar código”.
Mi carrera profesional me había llevado hacia la gestión de equipos de ingeniería, por lo cual mis capacidades de desarrollo estaban, cuanto menos, oxidadas.
En mis últimas etapas como desarrollador había tocado mucho Javascript, sobre todo Node en plataformas de microservicios y algo de React para frontend, con Azure como infraestructura.
Ahora tenía que montar una plataforma financiera y no tenía nada más que un lienzo en blanco.
La manera en la que arrancamos es la que todo framework de lean startup recomienda: validar antes de construir y seguir validando mientras se construye.
Nuestra validación ocurrió gracias a un PDF. Entregamos un PDF a nuestro primer cliente y cumplió todas las expectativas.
No podíamos tener un producto desarrollado que cubriera todas las necesidades de los usuarios de manera automática, pero sí podíamos generar manualmente un PDF entregable de manera mensual a nuestros clientes.
La técnica del Mago de Oz va exactamente de eso: validar una idea de producto o servicio simulando manualmente su funcionamiento detrás de escena (como un "mago" oculto) para aprender rápido del cliente sin construir toda la tecnología.
Claro, pero un mínimo de tecnología había que construir sí o sí, por lo menos para acceder a la información bancaria y contable de nuestros clientes. Y, sobre todo, había que construirla muy rápido.
Y aquí llegó el primer gran tradeoff: escogimos nuestro stack; elegimos velocidad por encima de todo, aun sabiendo que lo pagaríamos después.
- 🏗️ Vercel para desplegar en minutos y movernos rápido
- spoiler: serverless no se lleva bien con procesos pesados de ingesta.
- 🧑💻 NextJS porque encajaba como un guante con Vercel y nos permitía avanzar sin montar APIs al principio
- spoiler: la portabilidad de un monolito en Next hacia algo distribuido es prácticamente nula si no marcas una línea clara frontend/backend.
- 🗃️ Supabase como Postgres gestionado, evitando dependencia fuerte del proveedor (auth con JWT en vez de “out-of-the-box”).
- spoiler: esta vez sí acertamos.
- 📜 Cursor como IDE con IA: para alguien con conceptos claros a alto nivel pero algo oxidado, era una herramienta que nos ahorraba fricción.
Y así empezó nuestro tango. En menos de un mes y medio llegamos a montar una aplicación web que no tenía nada más que una landing, un login y una ventana para integraciones.
Durante el proceso de onboarding el apartado de integraciones permitía al usuario:
- Introducir una API key de Holded para que pudiéramos recoger su información contable.
- Introducir sus credenciales bancarias para que tuviésemos acceso a los datos bancarios a través de la API de un servicio que teníamos contratado (en este caso GoCardless).
Una vez terminado el onboarding el usuario ya no podía interactuar más con la aplicación, pero nosotros teníamos en nuestra DB toda la información necesaria para poder montar de manera manual los informes en PDF.
Empezamos a notarnos un pelín “Tangled up”
A medida que la base de clientes aumentaba nos dimos cuenta de que no solo era necesario ir reemplazando de manera paulatina el PDF por funcionalidades de la aplicación, sino que también empezaban a aparecer algunas necesidades más de integración y escalado.
Aprendí en aquel entonces que el rol del fundador requiere, entre otras cosas, de la capacidad de saber gestionar los recursos más preciados de cada startup: tiempo y dinero.
Decidimos invertir dinero para traer a un par de magos que nos ahorrarán tiempo, esta vez no venían de Oz sino de nuestra red.
Fue entonces que empezamos a lidiar con dos grandes frentes a la vez:
- Por un lado, ir añadiendo funcionalidades a la aplicación para poder enterrar el PDF
- Por otro lado, ir mejorando el sistema y su escalabilidad para poder hacer frente a más clientes, más integraciones, más datos.
Éramos como Buster Keaton en la famosa escena en la que tiene que despejar las vías del tren a medida de que el tren avanza sin parar.
“Just tango on” con un par de magos del software
Aquí es cuando el tango se hizo intenso e interesante. ¿Os acordáis de los spoilers de arriba? Vamos a darle un repaso y a ver cómo hemos lidiado con ellos.
⏱️ Serverless + ingesta pesada = mala combinación.
Si tienes que procesar muchos datos en background en un entorno serverless lo tienes difícil. Las funciones de Vercel tienen un timeout concreto que varía según el plan, pero siguen siendo funciones con su “cold start” que se levantan para ejecutar un trabajo y mueren tras haberlo hecho.
Imaginad ejecutar una ingesta de datos que proviene de un ERP (Holded en este caso) y tener que lidiar con un timeout de 5 minutos. Por muy eficiente que sea el código, si procesas datos de 10 usuarios distintos a una media de 30 segundos cada uno, saltas el timeout.
Para solucionarlo, decidimos usar un servicio de workflows llamado Inngest. Eso nos permitía ejecutar la ingesta de cada ERP de manera aislada como un “step” dentro de un flujo.
⚒️ Nuevos proveedores = tu modelo no era tan agnóstico como creías.
Empezamos a experimentar limitaciones en el proveedor que usábamos (GoCardless) para conectarnos a la información bancaria de nuestros clientes. Así que decidimos ofrecer uno más: WealthReader.
Y además algunos clientes nos pedían integrarnos con otro ERP aparte de Holded: FacturaDirecta.
Fue entonces cuando nos dimos cuenta de que nuestro modelo de datos no era tan agnóstico como pensábamos. Las entidades como Facturas, Cuentas Bancarias, Transacciones, etc. estaban muy acopladas con el modelo de datos de Holded y GoCardless y no estábamos listos como para hacer un simple “plug-and-play” con WealthReader y FacturaDirecta.
Nos embarcamos en un buen refactor de todo el modelo de datos y de las funciones de integración con las fuentes externas.
🔮 Mientras tanto, el tren no paraba.
La frase que más repetimos en aquel entonces era: “esto no escala”.
Estábamos mentalizándonos a la idea de tener que migrar todo en un momento dado a un buen proveedor cloud: despedirnos de Vercel y serverless, de Supabase, de Inngest y, sobre todo, de NextJS.
Así que empezamos a preparar el terreno (otra vez, con el PDF como enemigo común):
- De allí en adelante, solo usaríamos endpoints para poder tener una línea clara de demarcación entre frontend y backend.
- Definimos una mejor arquitectura para distribuir responsabilidad entre distintos servicios de backend con adapters para integrar con terceros (Holded, FacturaDirecta, GoCardless, WealthReader).
- Construimos cada componente del frontend con la idea clara de poder aislarlo en un servicio solo frontend, en React.
Lo que la pista me ha enseñado
Te lanzas a la piscina del emprendimiento como founder técnico y no hay paracaídas. No queda otra que hacer que las cosas salgan una y otra vez. No hay espacio para ni siquiera plantear la solución perfecta porque vives en un proceso continuo de búsqueda y refinamiento del problema a solucionar.
Lo único que importa es la velocidad de reacción y la capacidad de enfrentarte al siguiente reto, pero es importante intentar adivinar dónde estará el siguiente cuello de botella porque por lo menos se pueden tomar acciones que mitiguen el impacto que conllevará.
Al final se trata de buscar continuamente el equilibrio entre la deuda técnica actual y la que podría materializarse en un futuro porque pensar que se pueda montar algo evitándola es un poco ingenuo.
El concepto de “tradeoff” para deuda técnica aplica en mayor medida a los dos recursos más valiosos de cualquier startup, tiempo y dinero. Puedes abarcar todas las tareas técnicas como founder a costa del tiempo que conlleva o puedes delegar parte de ellas a personas con más capacidades que tú a costa de dinero.
Y finalmente, el recurso más valioso que puedes tener siempre es y siempre será la red. Levantar el teléfono para contar con cualquiera de los dos magos que mencionaba arriba tiene un valor imposible de cuantificar.
¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇
Llevo años construyendo productos y sistemas (mucho backend, microservicios y cloud). He pasado por consultoría, he liderado equipos y proyectos internacionales, y también me tocó vivir el ritmo de una startup desde dentro como cofundador técnico en Sherpa hasta el exit. Ahora en Orbitant ayudo a empresas a crecer con buena ingeniería, innovación y sentido práctico.