Manifiesto

Resolver lo elemental.

El software no es el objetivo, es la herramienta. Lo que importa es el producto. Y un producto solo existe si resuelve un problema real.

Los humanos hacemos herramientas. Es, quizá, lo que mejor sabemos hacer. Y en cuanto una herramienta funciona, empezamos a buscar cómo hacerla mejor.

No para trabajar menos. Para resolver el mismo problema de una forma más limpia. Y casi siempre, la forma más limpia resulta ser la más simple. La más elemental.

Piensa en un vaso.

Es uno de los objetos más simples que existen. Solo tiene que contener agua. Pero si algo en su construcción falla, una grieta, una pared demasiado delgada, deja de contener agua y deja de ser un vaso. Eso es lo que casi nadie entiende sobre la simplicidad: no es lo contrario del rigor, es su forma más exigente. Algo simple es algo a lo que ya no le puedes quitar nada sin romperlo.

John Maeda lo resumió en Las leyes de la simplicidad: simplificar es restar lo obvio y sumar lo significativo. Quitar hasta que todo lo que queda tiene una razón para estar ahí.

“La perfección se alcanza no cuando no hay nada más que añadir, sino cuando no hay nada más que quitar.”

Antoine de Saint-Exupéry

El software es la herramienta más flexible que hemos inventado. Con él puedes construir casi cualquier cosa, y por eso también es la más fácil de complicar. La única forma honesta de resolver un problema complejo con software es resolverlo de la manera más simple que funcione. Cada capa de complejidad que no resuelve nada es deuda, y el tiempo la cobra con intereses.

Durante décadas, la industria ha intentado quitarle el riesgo a construir producto. Inventó metodologías, frameworks, procesos, rituales, certificaciones. Casi todo eso consiste en levantar herramientas alrededor del problema, a veces con un fervor casi de secta, en vez de mirar el problema de frente. Nosotros hacemos lo contrario. Empezamos por lo elemental: primero el cliente, después el problema y solo al final el código. En ese orden, sin excepciones.

Hace años, Eric Ries explicó cómo construir bajo incertidumbre y lo llamó MVP, el producto mínimo viable. Fue una gran idea. Pero está incompleta.

El modelo

Un producto mínimo no es hacer menos. Es decidir qué merece existir.

Lo mínimo no es una cuestión técnica. Es una decisión sobre qué problema resolver. Y ese problema vive en una intersección.

123
1

Lo que el mercado ya resuelve

Las capacidades que cualquier producto de tu categoría ya ofrece. El estándar que se da por sentado.

2

Lo que te encantaría tener

La visión, la lista de deseos, tu producto imaginado en su mejor versión.

3

Lo que de verdad te duele hoy

El problema concreto, costoso y medible que tu operación enfrenta en este momento.

Donde se cruzan los tres está lo único que vale la pena construir primero. Ese es el producto mínimo de verdad. No lo que supones que tu cliente querrá en un futuro que todavía no existe, ni una función copiada porque el competidor la tiene. Es el problema que tienes enfrente hoy, el que cuesta dinero. Lo demás es peso muerto, y el peso muerto se paga con tiempo, foco y dinero.

Hemos visto a mucha gente con enorme talento construir software impecable para resolver un problema que no debía existir. Optimizan la respuesta a una pregunta equivocada.

Entregar producto no es lo mismo que entregar valor.

La inteligencia artificial derribó la barrera de construir. Hoy, lanzar algo que funciona toma días, no meses, y cada vez tomará menos. Pero eso vuelve más peligrosa la vieja confusión: creer que enviar producto es crear valor. No lo es. Puedes lanzar diez funciones por semana y no resolver el problema de nadie. Cuando construir deja de ser el cuello de botella, la única ventaja que queda es saber qué construir. Y eso, ninguna herramienta lo decide por ti.

Que sea simple no quiere decir que sea fácil. Lo simple es lo más difícil de construir.

Agregar es fácil. Cualquiera apila funciones, capas y excepciones hasta que ya nadie entiende el sistema. Lo difícil es entender un problema tan bien que puedas resolverlo con lo mínimo. Eso es crear producto: las piezas más elementales que resuelven el dolor real de tus clientes, ensambladas con criterio de ingeniería. Construir poco, medir, aprender, volver a construir. La simplicidad no es un lujo, una preferencia ni una comodidad. Es lo único que no se rompe cuando llega la escala.

Porque un producto bien hecho tiene un destino incómodo: funciona. Y cuando funciona y empieza a crecer, el problema cambia. Deja de ser de producto y pasa a ser de ingeniería: volumen, latencia, integraciones, datos, confiabilidad. Es la misma exigencia de lo elemental, ahora bajo presión.

Por eso nacimos

Bentel nació justo en esa frontera.

Justo donde un producto que ya demostró que importa choca con la ingeniería que necesita para no romperse. Empezamos porque vimos empresas con problemas reales atrapadas entre hojas de cálculo, sistemas que no se hablan y software que envejeció mal. Y porque nos dimos cuenta de algo: un producto claro y una arquitectura clara son la misma disciplina a distinta escala. Primero resolvemos lo elemental. Después acompañamos la complejidad que llega con el crecimiento.

Nuestros valores

01

Enfócate en lo elemental

Quitar es más difícil que agregar. Reducimos hasta que solo queda lo que resuelve el problema. Cada pieza de más es una promesa que alguien tendrá que mantener.

02

La solución siempre es la más simple

Si una solución parece complicada, es que todavía no entendimos el problema. Lo elegante no es un lujo: es la señal de que dimos con la raíz.

03

El cliente de tu cliente es lo más importante

No construimos para impresionar a quien firma el contrato, sino para quien vivirá con lo que entregamos. El valor se mide al final de la cadena.

Bentel