Conviene desarrollar un sistema a medida cuando un proceso central y rentable del negocio no puede resolverse correctamente con herramientas existentes, configuraciones o integraciones. La señal no es que el software estándar resulte incómodo: es que obliga a duplicar trabajo, genera errores, frena el crecimiento o impide sostener una forma de operar que aporta valor. Antes de programar, hay que observar el negocio, ordenar sus reglas y calcular el costo real del problema. Si se avanza, la primera versión debe resolver una sola necesidad prioritaria y empezar a usarse cuanto antes.
Que un sistema estándar resulte incómodo no significa que necesites uno propio
Las herramientas estándar existen porque muchos negocios comparten necesidades: facturar, controlar stock, cobrar, registrar clientes, administrar turnos o preparar pedidos. En gran parte de los casos, un sistema existente bien configurado es más económico, rápido y seguro que empezar desde cero.
El problema aparece cuando la operación real no entra en esas reglas. El equipo empieza a copiar información entre pantallas, mantener planillas paralelas o inventar pasos manuales para compensar lo que la herramienta no contempla.
La pregunta es cuánto trabajo adicional, cuántos errores y cuánta capacidad perdida genera la diferencia entre la herramienta y la forma real de operar.
Un desarrollo a medida comienza a tener sentido cuando esa diferencia afecta un proceso central del negocio y aparece todos los días. No cuando falta una función agradable o una pantalla más linda.
La aplicación propia que parecía una gran idea
El desarrollador que hizo la pregunta correcta
En un momento me empeciné con desarrollar una aplicación para que nuestros clientes compraran desde el celular y recibieran notificaciones. Sonaba moderno y parecía una evolución natural de la tienda online.
El desarrollador no empezó hablando de tecnología. Me preguntó cuánta gente realmente iba a descargarla y usarla. Esa conversación frenó un gasto que todavía no tenía justificación comercial.
“Si no se van a descargar la app al menos 10.000 personas, estás gastando plata para que los de la web tengan un ícono en el celular.”
Las 10.000 descargas no son una regla universal. Lo importante fue el criterio detrás de la pregunta: ¿la cantidad de usuarios, la frecuencia de uso y el problema resuelto justificaban construir y mantener otra plataforma?
Una web adaptada al celular ya podía resolver la compra. La aplicación agregaba desarrollo, actualizaciones, soporte y el desafío de convencer a cada cliente de instalarla. El proyecto era técnicamente posible, pero comercialmente prematuro.
Antes de presupuestar: sentarse, escuchar, anotar y mirar
La primera etapa de un desarrollo no debería ser elegir una tecnología. Debería ser observar la operación real.
“Antes de hablar de algo a medida y de valores, hay que sentarse, escuchar, anotar y mirar cómo funciona la operación del negocio. Quizá tiene la solución al alcance y todavía no se dio cuenta.”
Esto implica mirar qué hace el equipo cuando entra un pedido, dónde busca información, quién autoriza una excepción, qué datos vuelve a cargar y qué ocurre cuando algo sale mal.
Cuatro alternativas antes de programar desde cero
El desarrollo propio es una posibilidad, no la respuesta automática.
Eliminar duplicaciones, decisiones ambiguas y pasos que no aportan control ni valor.
Revisar permisos, automatizaciones, campos, plantillas y funciones que el equipo no está utilizando.
Conectar facturación, stock, tienda, WhatsApp o reportes para evitar la transferencia manual de datos.
Construir una solución propia cuando las alternativas anteriores no resuelven el núcleo del problema.
Muchas veces no hace falta reemplazar todo. Una integración bien diseñada puede conservar herramientas confiables y eliminar el punto donde el equipo pierde tiempo.
Señales de que un sistema a medida sí puede estar justificado
La información se carga varias veces
El mismo pedido, cliente o movimiento debe copiarse entre sistemas todos los días.
La limitación afecta lo que genera ingresos
El problema frena ventas, despacho, atención, cobranza o una capacidad necesaria para crecer.
Lo especial no es una excepción
Las reglas propias del negocio ocurren con frecuencia y forman parte de su propuesta de valor.
El problema ya tiene un precio
Puede medirse en horas, errores, ventas perdidas, demoras, reclamos o herramientas superpuestas.
Una quinta señal: el sistema genérico obliga a abandonar una ventaja real
No todos los negocios deben operar de la misma forma. Una política comercial, un modelo de vendedores, una lógica de preparación o una forma particular de atender pueden constituir una ventaja.
Cuando el software obliga a eliminar esa diferencia rentable para adaptarse a su estructura, un desarrollo especial puede tener sentido. Pero primero hay que demostrar que esa particularidad aporta valor y no es solamente una costumbre del dueño.
Cuándo todavía no conviene desarrollar
- Cuando nadie puede explicar de principio a fin cómo debería funcionar el proceso.
- Cuando el problema ocurre pocas veces y su costo es menor que mantener una solución propia.
- Cuando una configuración, plantilla o integración puede resolverlo.
- Cuando el negocio quiere imitar una función de otra empresa sin saber qué resultado espera.
- Cuando no existe una persona responsable de probar, decidir y capacitar al equipo.
- Cuando se pretende incluir todas las ideas antes de poner en uso la primera versión.
- Cuando no se contemplan mantenimiento, seguridad, copias de respaldo y futuras actualizaciones.
No termina cuando se entrega. Necesita mantenimiento, seguimiento de errores, decisiones de producto y adaptación a cambios de la operación.
Comerciantes y programadores: dos mundos que necesitan traducción
Una empresa de desarrollo puede programar correctamente lo que se le pide y aun así entregar una herramienta que no funcione en el mostrador. El problema no siempre es técnico. Muchas veces es de interpretación.
“Como dueño del negocio no podés pretender que alguien que se dedica a programar tecnología entienda cómo funciona tu mostrador. Los comerciantes somos bichos difíciles de llevar, no cualquiera entiende nuestro idioma.”
Esta frase no busca descalificar a ninguno de los dos lados. Describe un choque real: el programador necesita reglas claras y el comerciante suele explicar su operación mediante ejemplos, excepciones, urgencias y conocimientos que nunca escribió.
La función del puente
Alguien tiene que convertir situaciones como “este cliente siempre compra así”, “cuando llega mercadería hacemos esto” o “si falta una variante se reemplaza de esta manera” en reglas que puedan diseñarse, probarse y auditarse.
El dueño no debería desaparecer después de aprobar el presupuesto. Debe participar en decisiones breves y frecuentes, mostrar casos reales y aceptar que algunas costumbres tendrán que simplificarse para que el sistema sea sostenible.
El cementerio de las funciones inútiles
Los desarrollos se vuelven eternos cuando cada conversación agrega una función nueva. Muchas aparecen por casos improbables, miedo a dejar algo afuera o por la fantasía de que la herramienta elimine cualquier necesidad de decisión.
“Las funciones inútiles surgen de la idea de: ‘quiero que haga todo por mí y no tener que trabajar más’. Eso es una utopía hermosa que no se cumple nunca y solo extiende el desarrollo sin sentido.”
Un buen sistema reduce tareas mecánicas, organiza información y facilita decisiones. No reemplaza el liderazgo, la negociación ni la responsabilidad de revisar lo que ocurre.
Cómo detectar una función que todavía no debe construirse
- No existe un usuario concreto que la necesite.
- No se puede describir qué problema resuelve.
- Depende de datos que el negocio todavía no registra.
- Solo sería útil en una situación excepcional.
- No modifica ninguna métrica ni decisión.
- Puede resolverse temporalmente con un procedimiento simple.
La primera versión debe ser útil, no impresionante
El enfoque de producto mínimo viable propone construir una versión capaz de resolver el problema principal, ponerla en uso y aprender de la operación real antes de ampliar.
En un comercio, esa primera versión debería incluir lo necesario para que una tarea central pueda completarse de principio a fin, con responsables, permisos, controles y un resultado verificable.
Qué debería entrar primero
La trinchera decide las mejoras posteriores. No una lista interminable de deseos.
Definir qué pérdida, demora o restricción debe reducir la primera versión.
Permitir iniciar, procesar y cerrar la tarea sin volver al método anterior.
Registrar lo indispensable y limitar qué puede hacer cada tipo de usuario.
Poder identificar quién hizo qué, cuándo y con qué resultado.
Medir tiempo, errores, capacidad o costo antes y después.
La primera versión no debería convivir indefinidamente con planillas paralelas. Puede existir una transición controlada, pero debe definirse cuándo el nuevo flujo se convierte en la fuente principal.
La prueba del médico: calcular el retorno desde el problema
“Normalmente no vas al médico cuando te sentís bien. Si buscás un sistema es porque tenés un problema que te hace perder plata o tiempo. El tiempo es lo único que no se puede recuperar; si algo me hace ganar eso, ya me parece barato.”
La comparación sirve porque obliga a empezar por el síntoma. No tiene sentido calcular el retorno mirando únicamente el precio del desarrollo. Primero hay que calcular cuánto cuesta seguir igual.
El costo mensual actual
- Horas del equipo dedicadas a tareas manuales o duplicadas.
- Correcciones, devoluciones, reclamos y errores.
- Ventas que no pueden atenderse por falta de capacidad.
- Demoras de cobro, preparación o entrega.
- Suscripciones que se superponen.
- Tiempo del dueño utilizado para destrabar la operación.
Una cuenta sencilla
Beneficio mensual neto estimado = costo mensual actual del problema − costo operativo posterior − mantenimiento mensual.
Plazo estimado de recuperación = inversión inicial ÷ beneficio mensual neto.
Las horas liberadas deben convertirse en más atención, mejores compras, nuevas ventas, control o calidad de vida. De lo contrario, el retorno existe en la planilla pero no en el negocio.
Qué debe aportar el negocio durante el proyecto
Contratar un desarrollo no significa entregar el problema y esperar seis meses. El cliente también tiene responsabilidades.
- Designar una persona con autoridad para tomar decisiones.
- Mostrar la operación real, incluidos errores y atajos.
- Entregar datos de prueba representativos.
- Responder dudas en tiempos acordados.
- Probar cada etapa con usuarios reales.
- Priorizar y aceptar que algunas funciones quedarán afuera.
- Preparar capacitación, migración y momento de salida.
- Definir quién administrará el sistema después.
Cuando estas tareas no tienen dueño, el proyecto se frena y el equipo de desarrollo empieza a completar los vacíos mediante supuestos. Esos supuestos suelen ser técnicamente razonables, pero pueden ser comercialmente equivocados.
Un plan de diez días para decidir sin apurarse
Antes de pedir un presupuesto
El objetivo es llegar a la conversación técnica con un problema definido y números reales.
No empieces por “necesito un sistema”. Escribí qué está fallando y qué consecuencia produce.
Registrá durante varios días qué hace el equipo, dónde espera y qué vuelve a cargar.
Medí horas, errores, pérdidas, demoras y herramientas superpuestas.
Evaluá configuración, integraciones y cambios de proceso.
Separá lo indispensable de lo deseable y de lo que puede esperar.
Elegí quién tomará decisiones, probará y organizará la implementación.
Establecé qué cambio demostrará que el desarrollo funcionó.
La conclusión: un sistema a medida no debería hacer todo, debería resolver lo correcto
El software estándar es suficiente para muchos negocios. Un desarrollo propio se justifica cuando una limitación recurrente afecta un proceso central, tiene un costo demostrable y no puede resolverse razonablemente con una herramienta o integración existente.
Antes de programar hay que mirar el negocio, traducir sus reglas y eliminar caprichos. Después hay que construir una primera versión pequeña, usarla y medirla. El dueño debe participar, porque nadie externo puede adivinar todos los códigos del mostrador.
La decisión final no depende de cuán moderna parezca la solución. Depende de cuánto tiempo, dinero, control o capacidad puede recuperar. Un sistema a medida bien elegido no transforma la empresa por tener más funciones. La transforma porque deja de existir un problema que la estaba frenando.
Preguntas frecuentes
Empezá por verificar si una herramienta existente puede resolver el proceso mediante configuración o integración. Un desarrollo a medida se justifica cuando una operación central y rentable del negocio obliga a duplicar cargas, usar planillas paralelas o modificar una forma de trabajo que constituye parte de su ventaja comercial.
Solo las funciones indispensables para resolver el problema principal, registrar la operación y medir el resultado. Usuarios, permisos, datos básicos, flujo central, controles y reportes mínimos suelen tener prioridad. Las funciones deseables pero no necesarias deben quedar para versiones posteriores.
Porque el alcance cambia, se agregan funciones antes de probar las anteriores, aparecen excepciones no documentadas y el negocio se desentiende de las decisiones. Un alcance acotado, revisiones frecuentes y un responsable del lado del cliente reducen ese riesgo.
Sumá el costo mensual actual del problema: horas manuales, errores, ventas perdidas, tareas duplicadas y herramientas superpuestas. Restale el costo operativo futuro y el mantenimiento. Compará el beneficio mensual neto con la inversión inicial para estimar el plazo de recuperación.
No necesariamente. Primero hay que evaluar cuántos clientes la descargarían, con qué frecuencia la usarían y qué problema resolvería mejor que una web adaptable al celular. La cifra de 10.000 descargas incluida en este artículo pertenece a una conversación real y no funciona como regla universal.
Fuentes y marcos consultados
- Eric Ries, The Lean Startup. Utilizado como marco para construir una primera versión acotada, probarla y aprender del uso real.
- Eliyahu M. Goldratt, The Goal. Utilizado como referencia para concentrar el desarrollo en la restricción que limita la capacidad del negocio.
- Experiencias, criterios y frases de Cristian Markoski reunidos durante el proceso editorial de la Biblioteca de MARK-TREND.
La cifra de 10.000 descargas corresponde a una conversación concreta y no es un umbral universal. Los cálculos de retorno deben adaptarse a costos, volumen, riesgos y capacidad de cada negocio. Última revisión: 25 de julio de 2026.