Cuando un ganadero me describió cómo llevaba el control de su hato, esperaba encontrar algo primitivo. Lo que encontré fue más sofisticado de lo que imaginaba: un cuaderno con una lógica propia, columnas inventadas, abreviaciones que solo él entendía, pero que funcionaban. Había construido su propio sistema de información con lo que tenía.
El problema no era que careciera de método. El problema era que ese método no escalaba, no le avisaba cuando una vaca empezaba a producir menos, no le decía en qué mes del año tendría más terneros disponibles. La información existía. Simplemente no estaba en la forma correcta.
Eso me enseñó algo fundamental sobre el software: el usuario ya resolvió el problema de alguna forma. Tu trabajo como constructor no es reemplazarlo con algo más complejo: es encontrar la forma más simple de darle exactamente lo que le falta.
El problema de la complejidad innecesaria
Existe una tendencia persistente en la industria del software a confundir complejidad con valor. Los sistemas más grandes, con más módulos, con más configuraciones, parecen más profesionales. Los decks de ventas los muestran como prueba de robustez.
La realidad es diferente. La mayoría del software de gestión empresarial tiene una tasa de adopción de características de entre el 20% y el 30%. El usuario aprende lo que necesita para hacer su trabajo y el resto desaparece. El otro 70% o 80% de features no solo es dinero desperdiciado: es ruido activo que hace más lento al usuario y más caro el mantenimiento.
El software más valioso es el que alguien abre todos los días, el que no requiere manual, el que hace exactamente lo que promete y nada más.
Esa frase no es una aspiración filosófica. Es una métrica. Si el usuario no lo abre todos los días, no es que no lo necesite: es que el software no lo resolvió suficientemente bien.
Lo que significa construir lo mínimo que funciona
Hay una diferencia importante entre "mínimo" en el sentido de incompleto y "mínimo" en el sentido de preciso. El mínimo que funciona no es un prototipo. Es una solución que hace una cosa extremadamente bien, sin que el usuario tenga que pensar en el software mientras la hace.
Cuando construimos Hato iA, la primera versión tenía tres funciones: registrar ordeño, registrar un evento reproductivo y ver el historial de una vaca. Eso era todo. No había módulos de inventario de medicamentos, ni proyecciones financieras, ni integración con básculas. Tampoco las necesitábamos todavía.
Lo que sí tenía era que funcionaba desde el celular con señal de 2G, en 30 segundos por vaca, por un operario que nunca había usado un software en su vida. Esa restricción, que no fuera el dueño sino el operario quien lo usara, determinó cada decisión de diseño.
- Sin texto donde alcanzara un número.
- Sin confirmaciones innecesarias.
- Sin pantallas de configuración que el usuario nunca iba a tocar.
- Sin onboarding de cinco pasos.
El resultado fue un sistema que el operario aprendió a usar en 10 minutos. No porque los operarios sean menos capaces, sino porque ese es el estándar real de usabilidad. Si requiere más de 10 minutos, el diseño falló.
La trampa del cliente que pide más features
Hay un momento en el ciclo de vida de todo producto donde el cliente empieza a pedir cosas. "¿Pueden agregar un módulo de nómina?" "¿Y si pudiéramos exportar a Excel?" "¿Qué tal una app para el veterinario?"
Esas peticiones son señales, no órdenes. A veces revelan un problema real. Más seguido revelan que el usuario encontró una forma de usar el producto que no anticipamos, y que hay algo más profundo que resolver.
El trabajo del constructor es distinguir entre las dos cosas. Agregar la feature que el cliente pide es fácil. Entender por qué la está pidiendo. Construir la solución correcta para ese problema subyacente es lo que separa el software que funciona del software que se abandona.
En Labnormally tenemos una regla: antes de construir una feature nueva, tenemos que poder explicar cuántas veces por semana la va a usar el cliente principal. Si la respuesta es "una vez al mes" o "cuando se acuerde", probablemente no es lo que más necesita hoy.
Por qué esto importa para los negocios pequeños
Las empresas grandes tienen la capacidad de absorber software complejo. Tienen equipos de IT, tiempo de capacitación, presupuestos de implementación. El software genérico está diseñado para ese mercado.
El ganadero, el médico en consultorio privado, el dueño del estudio de yoga: no tienen nada de eso. Tienen 20 minutos en la mañana y un celular. Si el software no funciona en ese contexto, no funciona.
Esa restricción es lo que me apasiona de construir para ese mercado. No es una limitación: es una disciplina de diseño. Cada decisión que tomas tiene consecuencias inmediatas y verificables. El software o lo usa todos los días o no lo usa. No hay término medio.
El software más simple suele ser el más valioso no porque la simplicidad sea un fin en sí misma. Sino porque la simplicidad es evidencia de que alguien entendió el problema de verdad.
Entender el problema de verdad requiere tiempo. Requiere observar cómo el usuario resuelve el problema hoy. Requiere construir, entregar, medir y corregir. No se puede hacer desde lejos.
Eso es lo que intentamos hacer en Labnormally. No siempre lo logramos a la primera. Pero es el estándar al que apuntamos.