SolutionsCode Pedir presupuesto

07 Servicio

Sitio, sistema y aplicación hablando entre sí, con un solo responsable.

El conjunto de lo anterior trabajando junto: una sola base de datos, un solo interlocutor y un dato que se carga una vez. No se construye todo de golpe.

El problema no es la tecnología, son los tres proveedores

La historia se repite con una fidelidad casi aburrida. El sitio lo hizo una agencia de marketing hace tres años. El sistema de gestión lo hizo un programador que entendía el negocio mejor que nadie y que ya no está —y dejó el código en una computadora a la que nadie tiene la contraseña—. La aplicación de reparto la hizo un tercero que apareció después, cuando ya había un sistema, y que resolvió el problema como pudo: exportando una planilla todas las mañanas.

Ninguno de los tres se habla. No por mala fe: porque no tienen por qué. Cada uno cumplió con lo que le pidieron. El que termina uniendo las puntas sos vos.

Lo que eso cuesta de verdad

El costo no aparece en ninguna factura, que es exactamente por qué nadie lo mide:

  • El mismo dato se carga tres veces. El cliente que se dio de alta en el sitio hay que cargarlo a mano en el sistema, y el pedido que se cargó en el sistema hay que pasarlo a la app del repartidor.
  • Cuando algo falla, ninguno se hace cargo. La agencia dice que el problema es del sistema, el del sistema dice que es de la app, y vos hacés de traductor entre tres personas que no quieren hablarse.
  • Cada cambio se pide tres veces, se cotiza tres veces y se coordina tres veces. Un campo nuevo en el formulario de alta es un proyecto de tres semanas.
  • Los números no cierran nunca, porque hay tres versiones del mismo dato y ninguna está mal del todo.
  • Si alguno de los tres desaparece, esa pieza se convierte en una caja negra que nadie puede tocar y que hay que rehacer entera.

Sumado, se paga tres veces por el mismo dato. Una vez en cada proveedor.

Qué significa acá "entorno completo"

Nada más que esto: una sola base de datos y un solo responsable. El sitio web, el sistema de gestión y la aplicación móvil —Android o iOS— escriben y leen del mismo lugar. El cliente que se da de alta en el sitio ya está en el sistema. El pedido que entra al sistema ya está en el teléfono del repartidor. El stock que se descuenta en el depósito ya se ve en el catálogo. Nadie exporta nada.

Y cuando algo se rompe, hay un solo número al que llamar. No es un detalle menor: es probablemente la mitad del valor.

Lo que suele incluir

  • Un sitio que además de mostrar la empresa lee datos reales: catálogo con stock, turnos disponibles, estado de un pedido.
  • Un sistema de gestión interno donde vive la operación: stock, pedidos, clientes, reportes.
  • Una aplicación —Android o iOS— para quien trabaja fuera de la oficina: reparto, visitas, relevamientos, carga en la calle.
  • Las automatizaciones que unen las puntas: avisos, remitos que se generan solos, informes que llegan sin pedirlos, y las integraciones con lo que ya usás —el facturador, el banco, la plataforma de venta— para que esos datos también entren solos.

Podés ver dos piezas del conjunto funcionando en la sección de ejemplos de la portada: un panel de operaciones para una distribuidora y la aplicación de reparto que trabaja sobre el mismo negocio. Los datos son ficticios, pero el código es real y se navega. Es el mejor argumento que tenemos, porque no hay forma de explicar con palabras qué se siente que un pedido aparezca en el teléfono sin que nadie lo haya copiado.

No se construye todo de una

Esto es lo que hace que el entorno completo sea alcanzable y no un proyecto de película. Nunca arrancamos construyendo las tres piezas en paralelo. Se elige una —la que más duele hoy— y las otras se suman encima.

1. La pieza que más duele

Casi siempre es el sistema de gestión, porque ahí es donde están las planillas y las tres personas que se acuerdan de todo. Se define un alcance chico, se construye, se pone a producir. A partir de ahí la empresa ya funciona mejor, aunque todavía no exista ni el sitio nuevo ni la app.

2. Los cimientos quedan abiertos

La diferencia con un desarrollo suelto está acá y no se ve el primer día: esa primera pieza se construye sabiendo que van a venir otras. La base de datos se piensa para que la consulten varios programas, y la lógica queda detrás de una API en vez de enterrada en una pantalla. No cuesta más hacerlo así. Cuesta muchísimo más arreglarlo después.

3. Las otras piezas, encima de algo que ya anda

La app de reparto no arranca de cero: se conecta a datos que ya existen y que ya están bien. El sitio no inventa un catálogo: muestra el stock que el depósito ya carga. Cada pieza nueva es más rápida y más barata que la anterior, porque la parte difícil —entender el negocio y ordenar los datos— ya está hecha.

Primera pieza en producción: seis a diez semanas. Cada pieza siguiente se suma en etapas de cuatro a ocho semanas, y cada una se presupuesta y se aprueba por separado, cuando le toca. No hay que firmar el entorno entero para empezar, y podés frenar después de cualquier etapa con algo funcionando y en tu poder.

Cuándo NO conviene

Vale la pena decirlo, porque es la página más cara del sitio y sería fácil no decirlo.

Si ya tenés sistemas que funcionan bien, rehacerlos es tirar plata. Que tu sistema sea viejo o feo no es motivo suficiente. Si hace lo que tiene que hacer y la gente lo sabe usar, lo sensato casi siempre es dejarlo donde está y conectarlo: una integración que lo haga conversar con lo demás cuesta una fracción de reemplazarlo, y no te obliga a reentrenar a nadie, y es parte de lo que hacemos en software a medida. Hay casos donde el reemplazo se justifica —cuando la plataforma no da acceso a los datos, o cuando el proveedor original desapareció—, pero son menos de los que parece.

Si la empresa es muy chica, está sobredimensionado. Con tres o cuatro personas y una operación que entra en la cabeza de todos, un entorno completo es infraestructura para un problema que todavía no tenés. Probablemente te alcance con un sitio decente y un par de automatizaciones, por una décima parte del costo. El entorno completo empieza a tener sentido cuando el problema ya no es hacer el trabajo sino coordinar a quienes lo hacen.

Y si lo que querés construir no es una herramienta para tu empresa sino el negocio en sí —algo que le vas a vender a otros—, eso es otra conversación y tiene su propia página: producto digital.

Qué queda en tu poder

Todo. El código en tu repositorio, documentado. La base de datos en un formato estándar, sin candados. Las credenciales de servidores, dominios y servicios a tu nombre. Un documento que explica cómo está armado el conjunto, escrito para que lo entienda otro equipo y no para que lo entendamos nosotros.

Es la única manera honesta de vender un entorno completo. Si el argumento es "así no dependés de tres proveedores", el argumento se cae solo si el resultado es depender de uno.

Preguntas frecuentes

¿Cuánto cuesta un desarrollo integral de sitio, sistema y aplicación?

No hay un precio de lista, y quien te tire un número sin haber visto tu operación te está vendiendo humo. Lo que sí se puede decir es cómo se arma el costo: un entorno completo se cotiza por pieza y por integración, no como un paquete cerrado. El sitio, el sistema de gestión y la aplicación se presupuestan por separado, y aparte se presupuesta lo que las une —la base de datos común y la sincronización entre ellas—, que suele ser la parte que nadie contempla y la que termina explicando la diferencia entre un proyecto que cierra y uno que se estira. Hacemos primero una reunión de una hora y entregamos un documento con el alcance y el presupuesto cerrado, sin costo. Y como casi nunca se construye todo junto, el número que importa no es el total del entorno sino el de la primera pieza.

¿Se puede hacer por partes o hay que construir todo junto?

Por partes, y es la forma en que lo hacemos casi siempre. Construir sitio, sistema y aplicación en simultáneo es caro, lento y se equivoca en grande: se toman decisiones sobre tres piezas a la vez cuando todavía no hay ninguna funcionando que te diga si esas decisiones eran buenas. El orden habitual es arrancar por la pieza que más duele hoy —normalmente el sistema de gestión, porque es donde están las planillas—, ponerla a producir, y recién entonces sumar las otras encima de una base de datos que ya existe y ya está probada por la gente que la usa todos los días. Cada etapa se paga cuando se hace, no por adelantado.

¿Qué pasa si ya tengo un sitio hecho?

Se evalúa si conviene conservarlo, y muchas veces conviene. Si tu sitio anda, carga rápido y lo podés editar, no hay razón para rehacerlo: se lo conecta a la base de datos del sistema para que los datos viajen solos —un formulario de contacto que entra directo al CRM, un catálogo que lee el stock real— y listo. Rehacer algo que funciona es tirar plata. Ahora, si el sitio está hecho sobre una plataforma cerrada que no permite acceso a los datos, o si tarda ocho segundos en cargar, ahí la conversación cambia: no porque sea viejo, sino porque no se puede integrar. Eso se ve en una tarde mirando cómo está armado, y te lo decimos antes de cotizar nada.

¿Puedo empezar por una sola pieza y sumar las otras después?

Sí, y es lo recomendable. El entorno completo no es una compra de una sola vez: es una decisión sobre cómo se van a construir las piezas para que después encajen. Si arrancás por el sistema de gestión sabiendo que en un año va a haber una aplicación, el sistema se construye con la puerta abierta para esa aplicación —una API, una base pensada para que la consulten dos programas y no uno— y sumarla después cuesta una fracción de lo que costaría si hubiera que rehacer los cimientos. La diferencia entre empezar por una pieza y empezar por una pieza pensando en el conjunto no se ve el primer día. Se ve el segundo año.

¿Qué pasa si quiero cambiar de proveedor después?

Podés, y el entorno completo no te ata más que un desarrollo suelto. El código se entrega en tu repositorio, la base de datos es estándar y está documentada, las credenciales de servidores y servicios quedan a tu nombre, y no usamos formatos cerrados ni licencias propias. Si mañana querés seguir con otro equipo, ese equipo abre el repositorio y entiende qué hay. Esto no es generosidad: es la única forma de que nos elijas por el trabajo y no porque no te queda otra. Y en un entorno completo importa el doble, porque es exactamente el escenario donde un proveedor mal intencionado puede dejarte encerrado.

¿Esto es lo que necesitás?

El primer paso es una reunión de una hora y un documento: qué duele, qué se puede automatizar y qué conviene no construir. Sin costo y sin compromiso.