La pregunta "¿construyo o compro?" es una de las más recurrentes en cualquier empresa que crece. Y casi siempre se responde mal, en un sentido u otro. Hay empresas que construyen software a medida cuando un SaaS estándar les funcionaría perfectamente. Y hay empresas que llevan años adaptando sus procesos a una herramienta genérica que no encaja, pagando en productividad perdida lo que ahorraron en desarrollo.
Lo que no funciona es construir por construir. Ni tampoco adaptarse por adaptarse.
La lógica del build vs buy
El software de terceros — SaaS, plataformas, herramientas cloud — tiene una ventaja real: alguien ya ha resuelto el problema, lo mantiene, lo actualiza y distribuye el coste entre miles de clientes. Eso lo hace barato. Para procesos estándar — facturación, gestión de proyectos genérica, email marketing — tiene mucho sentido.
El problema aparece cuando tu proceso no es estándar. Cuando la herramienta genérica te obliga a cambiar cómo trabajas para encajar en sus flujos. Cuando pagas por el 80% de funcionalidades que nunca usarás. Cuando necesitas que tres herramientas distintas hablen entre sí y el único pegamento que existe son Zaps y webhooks frágiles que se rompen cada mes.
Señales de que necesitas software propio
La primera señal es cuando tu equipo tiene una hoja de Excel paralela al CRM. Eso significa que el CRM no resuelve algo que importa, y que alguien ya encontró la solución, solo que en el lugar equivocado.
La segunda es cuando tus procesos más importantes no caben en ninguna herramienta estándar. No porque sean complicados — sino porque son específicos de tu sector o de tu modelo de negocio. Las agencias inmobiliarias, por ejemplo, tienen flujos de captación y venta que ningún CRM genérico gestiona bien. Por eso construimos vivvia.es.
La tercera señal es cuando el coste total de las herramientas que usas — sumando licencias, integraciones, horas de mantenimiento y adaptación — supera lo que costaría construir algo propio que lo haga todo bien.
Los riesgos reales de construir
Construir software propio tiene riesgos que hay que nombrar sin romantizarlos. El primero es el scope creep: la lista de funcionalidades que empieza pequeña y crece hasta que el proyecto nunca termina. El segundo es la dependencia del equipo técnico: si la persona que construyó el software se va, alguien tiene que poder mantenerlo. El tercero es construir para hoy y no para dentro de dos años, generando deuda técnica que hace cada cambio posterior más caro.
Estos riesgos son reales, pero son mitigables. Con una definición clara de qué se construye en la primera versión y qué no. Con código limpio y documentado desde el primer día. Con una arquitectura pensada para crecer, no solo para funcionar ahora.
El criterio que usamos
Cuando un cliente nos pregunta si tiene sentido construir su propio software, la pregunta que hacemos primero es: ¿cuántas horas a la semana pierde tu equipo adaptándose a herramientas que no encajan? Si la respuesta es más de diez, y el proceso que genera esa fricción es central para el negocio, casi siempre tiene sentido construir.
Si la fricción es periférica — una funcionalidad que afecta a una persona una vez al mes — no tiene sentido. Hay que aguantar la incomodidad o buscar otra herramienta estándar.
No es una decisión binaria
La mayoría de empresas no necesitan construir todo desde cero ni usar solo herramientas estándar. El punto óptimo suele estar en el medio: usar SaaS para lo que funciona bien y construir solo lo que es diferencial. Tener un núcleo de software propio para los procesos core, y conectar herramientas estándar para el resto.
Lo que no funciona es construir por construir. Ni tampoco adaptarse por adaptarse. La decisión debe partir siempre del problema real, no de la preferencia técnica del equipo ni del miedo a la inversión.