En Kodexa venimos construyendo sitios y sistemas para otros negocios. Nexo nació de una pregunta distinta: ¿qué pasa si construimos nuestro propio producto, de punta a punta, en vez de solo lo que un cliente nos pide?
Nexo es un asistente con inteligencia artificial que aprende cómo funciona un negocio y ayuda a atender clientes, responder consultas, gestionar reservas y centralizar su información en un solo lugar. Podés conocer el caso de estudio completo de Nexo en nuestro portfolio.
Una aclaración honesta antes de seguir: Nexo todavía está en desarrollo. No tiene lanzamiento público todavía, y este texto no es la historia de un éxito ya resuelto. Es un registro de las decisiones que fuimos tomando mientras lo construíamos, y de lo que aprendimos en el camino.
1. La idea no es el producto
"Un asistente con IA para negocios" es una idea. No es un producto. Las herramientas de agenda tradicionales resuelven una parte muy chica del problema: guardan turnos. No entienden de qué trata el negocio, no pueden responder una consulta y dejan la información repartida entre WhatsApp, planillas y la memoria de alguien del equipo. Ahí vimos un espacio real: un asistente que además de agendar, entienda el negocio y actúe sobre esa información.
Convertir esa idea en decisiones concretas —qué construir primero, qué dejar afuera, cómo se configura, quién lo va a usar todos los días— fue la parte que realmente nos llevó tiempo.
2. Validar antes de construir todo
No tuvimos una validación de mercado clásica con métricas de adquisición — todavía no lanzamos públicamente. Pero sí decidimos, desde el principio, no asumir qué necesitaba cada negocio. Por eso construimos una herramienta simple de autoevaluación: quien está interesado cuenta cómo funciona su negocio y qué quiere mejorar, y a partir de esa respuesta entendemos si Nexo tiene sentido para su caso y qué plan se ajusta mejor.
Es una validación chica, pero real: en vez de suponer, preguntamos.
3. Diseñar la experiencia antes que el código
La decisión de producto más importante que tomamos con Nexo no fue técnica: fue de experiencia. La mayoría de los productos con IA agregan un chat en una esquina y le piden al usuario que configure todo por formularios aparte. Nosotros dimos vuelta esa lógica: hablar con Nexo es configurar Nexo. El dueño del negocio le cuenta a Nexo qué hace, qué servicios ofrece, sus precios, horarios y políticas — y esa conversación se convierte directamente en la configuración real del negocio.
Esa decisión cambió todo lo que vino después: la arquitectura, el onboarding, incluso qué le pedíamos al modelo de IA que hiciera.
4. Elegir una arquitectura que pueda crecer
Un SaaS no es una sola aplicación. Es, como mínimo, dos: el producto que usa el cliente final, y el sistema interno que el propio negocio necesita para operarlo. Nexo está construido sobre Next.js y PostgreSQL, con autenticación propia y una arquitectura pensada para sostener múltiples negocios, cada uno con su propia configuración y sus propios planes.
Además del producto en sí, tuvimos que construir un panel de administración interno para gestionar planes, leads y códigos promocionales. Ese tipo de paneles son, en el fondo, software a medida — nadie los ve desde afuera, pero sin ellos el producto no se puede operar como negocio.
5. Construir el MVP sin sobreingeniería
Fue tentador diseñar un sistema de permisos genérico y flexible "para cualquier caso futuro". No lo hicimos. Definimos planes concretos —con funcionalidades específicas activadas o no según el plan— en vez de construir una capa abstracta de configuración que todavía no necesitábamos. El sitio, las reservas y el asistente de IA están disponibles desde el plan más simple; funcionalidades como WhatsApp con IA, galería de fotos o carta digital se suman en planes superiores.
Construir menos, pero que ese "menos" funcione de punta a punta, es la diferencia entre un MVP real y una demo.
6. Integrar IA cuando realmente aporta valor
Meter inteligencia artificial en un producto no es agregar un chat. Es decidir en qué parte del producto la IA reemplaza una fricción real. En Nexo, la IA no es una funcionalidad más: es la forma en que el negocio se configura y la forma en que sus clientes reciben respuestas. Eso significa entrenarla con información real del negocio —servicios, precios, horarios, preguntas frecuentes, políticas— y no con respuestas genéricas.
Aprendimos que la parte difícil de la IA no es "que responda", sino que responda con la información correcta del negocio correcto, sin inventar nada.
7. Los pagos son parte del producto, no un detalle al final
Suscripciones, planes y pagos recurrentes no son un extra que se agrega al final: definen la estructura del producto desde el principio. Tuvimos que integrar un sistema de pagos que soportara suscripciones recurrentes, códigos promocionales y cambios de plan, y pensar el producto en función de qué funcionalidad corresponde a qué plan — no al revés.
Si estás pensando en un producto SaaS propio, esta es una de las primeras cosas que conviene definir, no una de las últimas.
8. Lo que cambia cuando te acercás a producción
Aunque Nexo todavía no tiene lanzamiento público, ya sentimos la diferencia entre "que funcione" y "que esté listo para operar un negocio real". Pagos que no pueden fallar, un panel de soporte para resolver problemas de un cliente sin tocar la base de datos a mano, códigos promocionales, seguimiento de leads. Ninguna de esas cosas es la funcionalidad principal del producto, pero todas son necesarias para que exista como negocio y no solo como demo.
9. Lo que ajustamos sobre la marcha
Si hay algo que revisamos en el camino fue la forma de comunicar el producto. La primera versión de la landing de Nexo no explicaba bien cuál era el verdadero diferencial, y tuvimos que rediseñarla para que quedara claro desde los primeros segundos que hablar con Nexo es configurar Nexo. A veces lo que hay que iterar no es el código: es cómo explicás lo que construiste.
10. Qué significa construir un SaaS, en la práctica
Construir un SaaS no es programar una funcionalidad y ponerla online. Es tomar decisiones de producto, diseñar una experiencia antes de escribir código, elegir una arquitectura preparada para varios usuarios y roles, usar IA donde realmente resuelve algo, y tratar los pagos y la operación como parte del producto desde el día uno. Es, en el fondo, la misma lógica que aplicamos cuando construimos productos para otros negocios: entender el problema antes que escribir código.
Construir Nexo nos enseñó algo simple: una buena idea necesita mucho más que código para convertirse en producto. Si tenés una idea, un proceso que querés digitalizar o un producto que querés llevar a producción, podemos ayudarte a construirlo.