Desarrollo SaaS a medida para cuando el software forma parte de lo que vendes.

Depende de una cosa por encima de todas: cuánto hay que resolver para que el producto funcione igual de bien con el cliente número dos que con el número uno. Ahí es donde se va el presupuesto de un SaaS, y no en la cantidad de pantallas. Por eso la conversación útil no empieza por una lista de funcionalidades sino por qué tiene que poder hacer un cliente desde que entra hasta que obtiene algo de valor. Con eso se puede acotar un primer alcance de verdad y decir qué entra ahora y qué es mejor dejar para la segunda fase.

Menos de lo que se suele suponer si se empieza por el núcleo, y mucho más si se empieza por el catálogo completo. Trabajamos por fases con un objetivo claro para la primera: que un cliente real pueda usar el producto y que vosotros podáis mirar qué hace con él. Todo lo que no haga falta para eso —integraciones, informes, automatizaciones— tiene su sitio, y ese sitio es después.

Sí, y en la mayoría de casos es lo que recomendamos. Un MVP bien planteado no es una versión recortada: es el núcleo del producto funcionando de verdad para un cliente, con lo de alrededor todavía hecho a mano. El cobro, por ejemplo, puede esperar perfectamente a la segunda fase; cuando llega, integramos la pasarela y la lógica de suscripción, planes y límites. Lo que sí conviene decidir desde el principio es cómo se separan los datos de cada cliente, porque eso es lo único que no se puede añadir después sin tocarlo todo.

Primero la miramos y os decimos cuál de las dos cosas sale mejor, con argumentos. Es una situación muy habitual: un MVP que valida la idea y luego no aguanta la entrada de clientes, casi siempre porque los datos de todos viven mezclados o porque cada cliente nuevo obliga a tocar el código. A veces se puede reescribir sólo esa parte y conservar el resto; a veces sale más barato y más rápido rehacer el núcleo y traerse los datos. Lo que no hacemos es decidirlo antes de haberlo mirado.

Tuyo. El código, la base de datos, los dominios y las cuentas de los servicios que se usen quedan a tu nombre, y se entregan documentados en un repositorio al que tienes acceso desde el primer día. Es una condición razonable en cualquier desarrollo y en un SaaS lo es más todavía: el producto es el activo del negocio, así que no puede depender de que sigamos trabajando juntos.

El alojamiento se decide según lo que pida el producto y queda en infraestructura tuya. El mantenimiento de un SaaS es distinto al de una web: no es sólo que siga en pie, es corregir incidencias, vigilar rendimiento y seguridad, actualizar y seguir construyendo. Solemos plantearlo como una relación continua con un alcance escrito, no como una bolsa de horas. Sobre el crecimiento: preparar el producto para escalar es una decisión de arquitectura que se toma al principio —cómo se separan los datos, cómo se consulta y qué se puede repartir— y después es cuestión de medir y de ir ampliando lo que lo pida. Lo que no se puede es prometer que aguantará lo que sea sin haber visto el producto.

Entonces úsala. Es la respuesta honesta y la damos a menudo. Construir un producto sólo tiene sentido si lo que vais a vender es distinto de lo que ya se puede comprar, o si lo que existe obliga a vuestros clientes a trabajar de una forma que no es la suya. Si la diferencia está en el precio o en un par de detalles, sale mucho más a cuenta pagar la licencia. Lo miramos antes de proponer nada, y si la conclusión es ésa, lo decimos.