¿Conviene tener tu propio sistema o seguir pagando cinco plataformas?

Hasta hace poco la respuesta era casi siempre pagar el SaaS, porque desarrollar a medida costaba demasiado. Eso cambió y la ecuación se movió. Hoy la decisión depende de tres cosas concretas, cuán específico es tu proceso, cuánto estás pagando en licencias, y quién va a mantener lo que construyas.

Primero, hacé la cuenta

Antes de discutir nada, sumá lo que pagás. Abrí las suscripciones activas, tomá el costo mensual de cada una, multiplicalo por doce y por la cantidad de usuarios donde el precio sea por asiento.

La mayoría de las empresas nunca hizo ese número junto, porque las licencias se aprueban de a una y en momentos distintos. Verlo sumado es, para muchos, el momento incómodo del ejercicio — y es el punto de partida honesto de esta decisión.

Anotá también, al lado de cada herramienta, qué porcentaje de sus funciones usás realmente.

¿Cuál es el costo que no está en la factura?

Es el que decide la comparación, y no aparece en ninguna línea contable:

  • Procesos adaptados a la herramienta en vez de al revés. Cada vez que tu equipo hace un paso extra “porque el sistema lo pide así”, eso es costo.
  • Datos partidos en cinco lugares. El síntoma es cualquier pregunta de negocio que requiere abrir tres pestañas y una planilla para responderse.
  • Integraciones frágiles. Los conectores y automatizaciones que unen todo se rompen con cada actualización, y alguien los arregla.
  • Tiempo del equipo en tareas puente. Exportar de acá, pegar allá, verificar que coincida.
  • La pregunta que nadie puede responder porque el dato vive en tres sistemas y ninguno tiene la versión completa.

¿Qué cambió?

El desarrollo a medida dejó de ser un proyecto de seis meses y capital importante. El costo de construir bajó lo suficiente como para que la comparación deje de ser “barato contra carísimo” y pase a ser una cuenta que se puede hacer de verdad.

Eso no significa que construir sea siempre mejor. Significa que ahora hay que pensarlo, cuando antes la respuesta venía dada.

¿Cuándo SÍ conviene lo propio?

  • Procesos que son tu diferencial competitivo. Si tu forma de operar es parte de por qué te eligen, meterla en una herramienta genérica la aplana.
  • Flujos que ningún producto contempla. Cuando ya probaste tres y en las tres terminaste con un campo “observaciones” haciendo de comodín.
  • Necesidad real de datos centralizados. Si las preguntas importantes cruzan varios sistemas, ninguna herramienta suelta te la va a resolver.
  • Licencias que escalaron con el equipo. El costo por asiento crece lineal con la nómina; un sistema propio no.

¿Cuándo NO conviene?

Esta sección es la que hace que el artículo no sea un folleto.

  • Funciones commodity y reguladas. Contabilidad, sueldos, facturación electrónica, pagos. No solo hay que construirlas: hay que mantenerlas al día con la normativa, para siempre. Comprá.
  • Cuando un SaaS resuelve el 90%. Ese 10% restante casi nunca justifica construir y mantener el 100%.
  • Cuando no hay nadie que pueda mantenerlo. Un sistema propio sin dueño interno ni contrato de soporte es un pasivo con fecha de vencimiento.
  • Cuando el proceso todavía cambia todas las semanas. Si no se estabilizó, cualquier cosa que construyas nace desactualizada. Primero se estabiliza.

El punto medio, que suele ser la mejor respuesta

Casi nunca es todo o nada. La configuración que más recomendamos: mantener el SaaS donde es commodity y construir a medida solo la capa donde está tu diferencial, con los datos centralizados en una base propia que consolide lo que hoy está partido.

Así seguís comprando contabilidad y sueldos, pero la operación que te distingue corre en algo tuyo, y las preguntas de negocio se responden contra una sola fuente.

¿Qué pasa con el mantenimiento y la dependencia del proveedor?

Hay que responderlo de frente porque es la objeción número uno, y evitarla se nota.

Un sistema propio necesita mantenimiento: cambios de normativa, nuevas necesidades, actualizaciones. Eso es un costo real que hay que presupuestar desde el día uno, no una sorpresa.

Sobre la dependencia: la protección no es la confianza, son cuatro condiciones concretas. El código en un repositorio al que accedés vos. Los datos en infraestructura que controlás vos. Documentación que existe. Y un stack estándar, no propietario, para que otro equipo pueda tomarlo. Si se cumplen las cuatro, cambiar de proveedor es incómodo pero posible. Si no se cumple alguna, la dependencia es real — y esa es una razón válida para no avanzar.

Marco de decisión en cinco preguntas

Respondé estas cinco y vas a tener la respuesta sin necesidad de que nadie te la venda:

  1. ¿Este proceso es parte de por qué te eligen tus clientes? Si sí, suma para construir.
  2. ¿Cuánto pagás por año en licencias para resolverlo, entre todas las herramientas?
  3. ¿Cuántas horas por semana se van en tareas puente entre sistemas? Multiplicá por costo horario y por 52.
  4. ¿Hay alguien —interno o contratado— que pueda mantener lo que se construya? Si la respuesta es no, la decisión ya está tomada: comprá.
  5. ¿El proceso está estable hace al menos seis meses? Si cambia todo el tiempo, todavía no.

Si las respuestas son sí, un número alto, un número alto, sí y sí, construir probablemente convenga. Si alguna de la 4 o la 5 da que no, no importa cómo hayan dado las otras.

Preguntas frecuentes

¿Cuánto cuesta desarrollar un sistema a medida hoy?

Depende del alcance, pero el cambio relevante es que dejó de ser un proyecto de seis meses y capital importante. Hoy la forma sensata de cotizarlo es por etapas, donde la primera ya funciona sola. Desconfiá de cualquier número que te den antes de haber mirado tu operación: cotizar a ciegas es cómo se generan los proyectos que terminan al doble.

¿Qué pasa si el proveedor que lo construyó desaparece?

Es la objeción número uno y hay que responderla de frente. La protección real es contractual y técnica, no de confianza, el código y los datos son tuyos, están en un repositorio al que accedés, la documentación existe, y el stack es estándar y no propietario. Si un proveedor se resiste a alguna de esas cuatro, ese es el problema.

¿Puedo tener las dos cosas?

Es lo que recomendamos en la mayoría de los casos. Mantené el SaaS donde es commodity y construí a medida solo la capa donde está tu diferencial, con los datos centralizados en tu propia base. No es todo o nada, y plantearlo como si lo fuera suele ser una señal de que alguien te quiere vender algo.

¿Cómo sé si mi proceso es lo bastante específico?

Una prueba práctica, si al implementar una herramienta nueva tuviste que cambiar tu forma de trabajar para que entrara, y eso te costó eficiencia, ese proceso es candidato. Si en cambio te adaptaste sin fricción, probablemente sea commodity y convenga seguir comprándolo.

Aplicalo a tu empresa

Podemos ver juntos si esto tiene sentido en tu operación, y si no lo tiene, te lo decimos.