Muchos pequeños negocios todavía venden en un lugar, cobran en otro y controlan el inventario de memoria.
Una parte de la operación vive en una libreta. Otra, en WhatsApp. Los pagos llegan por distintos medios. El cierre del día se reconstruye cuando ya nadie recuerda exactamente qué ocurrió.
Y, sin embargo, el mercado no está vacío.
Busca “sistema de facturación” y encontrarás una oferta enorme de software. Hay POS, CRMs, plataformas de inventario, herramientas de cobranza y sistemas para prácticamente cualquier necesidad imaginable.
Entonces aparece una pregunta incómoda:
Si ya existe tanto software, ¿por qué tantos negocios siguen operando con papel, chats y memoria?
Tener software no es lo mismo que poder usarlo
El problema no siempre es el precio. Una aplicación puede ser barata y seguir siendo inaccesible si exige demasiado conocimiento, demasiadas configuraciones o demasiadas decisiones antes de permitir hacer el trabajo.
El dueño de un pequeño negocio normalmente no está buscando administrar una plataforma. Está intentando vender, cobrar, entregar, reponer y cerrar el día.
Cuando una herramienta crece, también puede crecer su distancia con el público original. Aparecen más módulos, más procesos, más configuraciones y más capas de abstracción. El producto se vuelve capaz de atender operaciones mayores, pero menos reconocible para quien solo necesita controlar su negocio sin convertirse en especialista del software.
Esto no ocurre necesariamente por mala intención. Es una consecuencia bastante natural de buscar mercados más grandes y clientes con mayor capacidad de pago.
El comerciante que hace posible llegar al pueblo
Imagina un vendedor de pescado.
El mayorista no suele viajar hasta un pueblo pequeño para vender unos cuantos pescados. El traslado no se paga solo.
Pero un comerciante intermedio puede comprar pescado y transportarlo junto con arroz, azúcar, aceite y otros productos. La distribución cambia de economía.
El pueblo no necesita consumir suficiente pescado para sostener un viaje exclusivo. El viaje se vuelve viable porque varias necesidades comparten el mismo canal.
En software, la pregunta es parecida:
¿Cómo se puede ofrecer una experiencia realmente especializada sin asumir el costo completo de construir y mantener un producto aislado para cada nicho?
La tesis de Avileo
Avileo parte de una idea sencilla: la especialización y la reutilización no son opuestos.
Un negocio puede necesitar reglas propias sin que todo el sistema tenga que construirse desde cero. La experiencia puede cambiar según el vertical mientras las capacidades costosas y transversales se comparten.
En el código, un vertical se representa como un BusinessModePlugin. No es solo
un nombre visible en una tarjeta. Declara metadata, valores por defecto,
configuración, superficies y capacidades del journey.
Actualmente Avileo registra seis modos:
| Vertical | Qué cambia |
|---|---|
| Distribuidora | Peso, unidad o caja; crédito, vendedores, distribución y cierre. |
| Tienda | Catálogo, variantes, inventario, pedidos y venta minorista. |
| Agua | Rutas, visitas, envases, clientes recurrentes y entregas. |
| Cochera | Sesiones, vehículo, placa, permanencia y cobro. |
| Citas | Agenda, profesionales, disponibilidad, servicios y recordatorios. |
| Barbería | Agenda para barberos, vocabulario propio y servicios. |
Una pollería, por ejemplo, puede ser un escenario de distribución. Café Élite puede ser un perfil de tienda. No hace falta crear un modo nuevo por cada negocio que aparezca.
El modo no es un if repartido por toda la aplicación
Una arquitectura vertical frágil podría terminar así:
if (businessMode === 'cochera') {
// mostrar una pantalla distinta
}
El problema de ese enfoque es que el conocimiento queda disperso. Con el tiempo, cada pantalla, endpoint y servicio empieza a tener su propio criterio sobre lo que un modo puede hacer.
Avileo busca que la decisión pase por una cadena común:
businessMode + modeConfigOverrides
→ resolveBusinessModeFlags()
→ deriveBusinessCapabilities()
→ resolveModeSurface()
→ guards + RBAC + businessIdEl negocio persiste un modo y puede tener overrides específicos. El sistema resuelve los defaults más esas diferencias, valida el resultado y deriva capacidades semánticas como:
- gestión de distribución;
- visitas y reparto por ruta;
- comercio y catálogo;
- agenda y recordatorios;
- inventario y reservas;
- sesiones de servicio;
- equipo y compensaciones.
La UI y el backend consumen esa configuración efectiva. El servidor además
mantiene los controles de permisos, ownership y businessId. Activar una
capacidad no equivale a saltarse la autorización.
Una venta puede significar cosas distintas
En un nivel bajo, muchas acciones importantes pueden expresarse como operaciones de negocio conectadas. Una venta no es únicamente una fila con un total. Dependiendo del flujo, puede tener pagos, saldo, inventario, distribución, auditoría, información fiscal y eventos relacionados.
Pero no todo Avileo es literalmente una sola transacción. También existen citas, sesiones, clientes, archivos, conversaciones, jobs y eventos. La transacción es una herramienta para mantener la integridad de muchas mutaciones críticas, no la única abstracción del producto.
Lo importante es que el sistema entienda el contexto:
- una distribuidora puede vender por peso, asignar producto y registrar devoluciones;
- una tienda puede vender una variante y descontar inventario;
- un negocio de agua puede registrar una visita y una entrega;
- una cochera puede abrir y cerrar una sesión de estacionamiento;
- una barbería puede pasar de una cita a un servicio cobrado.
La operación común no elimina las diferencias del negocio. Las organiza.
Tari: compartir lo costoso sin compartir el rubro
Avileo se apoya en Tari, un conjunto de librerías reutilizables para capacidades que no deberían reinventarse en cada producto.
Entre las piezas compartidas aparecen runtime de IA, sesiones, herramientas, eventos, colas, archivos, WhatsApp, autenticación, billing y fiscalidad.
La frontera es importante: Tari no necesita saber qué es una pollería, una cochera o una barbería. Su trabajo es ofrecer mecanismos confiables para contexto, eventos, ejecución, persistencia y comunicación.
Avileo es quien conecta esos mecanismos con los conceptos del negocio.
La infraestructura común debe reducir el costo de construir un vertical, no borrar las diferencias que hacen que ese vertical sea útil.
Atlas: documentación conectada con evidencia
Cuando un sistema tiene muchos modos y muchas capacidades, la documentación no puede ser un archivo que se actualiza una vez y después se olvida.
Avileo tiene un Atlas machine-readable en apps/avileo/docs/business/atlas.json.
El Atlas registra, entre otras cosas:
- modos registrados;
- capacidades por modo;
- estado
live,partialodisabled; - filtros efectivos;
- fuentes de implementación;
- pruebas asociadas;
- limitaciones conocidas.
Hay una precisión importante: Atlas no es por sí solo el runtime de Avileo ni un motor que ejecute las capacidades. Es una capa de documentación y verificación conectada al código.
Su valor está en reducir la improvisación. Antes de modificar un flujo, un agente o una persona puede consultar qué capacidad existe, para qué modo aplica, qué filtro la habilita y qué evidencia la respalda.
La IA trabaja encima de contratos
La inteligencia artificial no resuelve por sí sola el problema de la complejidad. Puede incluso empeorarlo si se le permite inventar reglas o escribir directamente sobre cualquier recurso.
La IA se vuelve más útil cuando trabaja dentro de un sistema que ya conoce:
- el contexto del negocio;
- los permisos del actor;
- las capacidades efectivas;
- las herramientas disponibles;
- los límites del flujo;
- la necesidad de aprobación humana.
Por eso el CLI de catálogo puede separar lectura, preview, propuesta, aprobación y aplicación. El agente puede preparar un cambio, pero una mutación sensible sigue teniendo una frontera explícita.
La idea no es pedirle a una IA:
“Constrúyeme un sistema para una cochera”.
La idea es construir antes una infraestructura donde una cochera ya tenga conceptos, reglas, pruebas y herramientas que la IA pueda consultar y utilizar.
Pensar una vez y automatizar después
La frase “piensa una vez y automatiza después” resume esta forma de construir.
Primero se define el concepto:
- qué significa una venta;
- qué actores participan;
- qué permisos existen;
- qué pasa con el inventario;
- qué estados son válidos;
- qué debe quedar auditado;
- qué cambia según el vertical.
Después se convierten esas decisiones en contratos, componentes, servicios, pruebas y documentación.
Finalmente, la IA puede trabajar sobre un terreno menos ambiguo.
Eso no elimina la necesidad de criterio humano. Cambia el lugar donde ese criterio se utiliza: menos improvisación en cada tarea y más diseño de la infraestructura que hará posibles muchas tareas futuras.
La especialización puede ser económicamente viable
El software de nicho suele tener un problema: un mercado pequeño no siempre puede pagar el costo completo de una plataforma independiente.
Pero “pequeño” no significa “simple”. Una distribuidora puede tener problemas de peso, crédito, rutas, devoluciones y conciliación. Una cochera puede necesitar sesiones, placas, permanencia y pagos. Una barbería puede requerir agenda, profesionales, disponibilidad y seguimiento.
La oportunidad está en compartir lo que no necesita ser reinventado y conservar la profundidad donde realmente importa.
Eso no significa que el problema esté resuelto para siempre. Significa que la arquitectura puede hacer viable intentar resolverlo.
El objetivo no es agregar funcionalidades indefinidamente.
Es que el dueño de una tienda, una distribuidora, un negocio de agua, una cochera o una barbería pueda abrir el sistema y reconocer su operación.
Y cuando llegue el final del día, no tenga que reconstruirla desde una libreta, un chat y varios recuerdos incompletos.
Tu negocio en orden.