El desarrollo SaaS con inteligencia artificial usando agentes de código no es una promesa futura: es cómo construimos TheCharterPanel, una plataforma B2B para operadores de charter náutico, llegando a un MVP production-ready en aproximadamente 90 días desde el primer commit. Este es el case study técnico: qué salió bien, qué se rompió y qué nunca delegamos a la IA.
TheCharterPanel centraliza flota, reservas, clientes, tripulación y finanzas en un mismo sistema. Es un ejemplo directo del modelo que describimos en crear software propio y venderlo: un operador náutico que construye para resolver su propia operación, con potencial de venderlo a otros del rubro.
“El 28% de crecimiento de empresas SaaS verticales en Latinoamérica indica que rubros como el náutico tienen ventanas de oportunidad antes de que aparezcan competidores con mayor financiamiento.
Por qué el charter náutico no se parece a un SaaS genérico de reservas
Un yate no es una sala de reuniones. Tiene temporadas, puertos base, ventanas de disponibilidad, tripulación asignada, costos variables y restricciones legales. Desde el inicio definimos cinco áreas funcionales con alcance explícito:
| Módulo | Función principal | Riesgo principal |
|---|---|---|
| Fleet management | Inventario vivo con estados operativos | Disponibilidad inconsistente |
| Reservation system | Flota + cliente + crew + finanzas | Mezcla de estados comerciales y operativos |
| Client portal | Vista publicable sin datos internos | Filtración de información interna |
| Crew management | Asignaciones por viaje, no HRIS completo | Sobregeneralización hacia cualquier empresa |
| Financial tracking | Tracking operativo, no contabilidad | Confusión entre importe, pago y saldo |
Definir ese alcance fue la primera decisión humana importante. En desarrollo SaaS con inteligencia artificial, el riesgo no es solo construir lento — también es construir demasiado.
“El mercado SaaS latinoamericano crece al 28% anual: una oportunidad de USD 66.000 millones para 2033.
“El mercado SaaS latinoamericano crece al 28% anual: una oportunidad de USD 66.000 millones para 2033.
Las decisiones de arquitectura que permitieron trabajar con agentes
El stack fue Next.js, TypeScript estricto, PlanetScale, Vercel y Claude Code agents. No por ser novedoso, sino porque reducía fricción operativa y permitía iterar rápido sin sacrificar estructura.
Modularidad por dominio. Flota, reservas, clientes, crew y finanzas tuvieron sus propios componentes, tipos, validaciones y queries. Una tarea como "agregar filtros por estado en reservas" podía limitarse a un área concreta. Cuando una tarea cruza demasiados dominios, el agente necesita más contexto y aumenta la probabilidad de cambios laterales no deseados.
Tipos antes que prompts largos. En vez de explicar reglas en prompts extensos, capturamos comportamiento esperado en modelos, estados y funciones bien nombradas. Los agentes responden mejor cuando el código ya expresa intención.
Server-first para flujos críticos. Validaciones de disponibilidad, cambios de estado, cálculos financieros y operaciones que afectaban datos compartidos se mantuvieron cerca del servidor.
Cómo el desarrollo SaaS con IA avanzó sprint a sprint
Sprint 1 — base y modelo de dominio
Scaffolding de módulos, formularios iniciales y tablas. El problema fue previsible: demasiados campos querían entrar en el primer formulario. Separamos "perfil operativo" de "datos comerciales".
Sprint 2 — flota y disponibilidad
Los agentes implementaron vistas de listado, detalle, edición, estados y filtros. La dificultad apareció en disponibilidad: un agente puede construir un calendario visual, pero no entiende automáticamente la diferencia entre "bloqueado por mantenimiento", "reservado", "opción comercial" y "no publicado". Tuvimos que explicitar esos estados y sus reglas.
Sprint 3 — reservas como columna vertebral
El más importante. El sistema de reservas conectaba casi todo: flota, clientes, crew y finanzas. Definimos un flujo estricto: solicitud → opción → confirmada → en operación → completada / cancelada. No todos esos estados tienen el mismo significado financiero ni operativo.
Lo que se rompió fue la sincronización entre estado de reserva y disponibilidad de embarcación. La corrección fue centralizar la función que actualizaba disponibilidad derivada de reservas.
Sprint 4 — portal de clientes
Al exponer información hacia el cliente, aparecieron preguntas de privacidad, tono y permisos. La solución fue crear view models específicos para el portal: no se trataba de ocultar campos visualmente, sino de no enviarlos a esa superficie.
Sprint 5 — crew management
La tendencia de los agentes fue sobregeneralizar: algunas propuestas de implementación parecían diseñadas para cualquier empresa con empleados, no para charter náutico. Ajustamos el modelo hacia roles náuticos, asignaciones por viaje y documentación relevante para la industria.
Sprint 6 — financial tracking
El módulo donde más cuidado pusimos. Lo que se rompió en una primera iteración fue la mezcla entre revenue, pagos y saldo. Un importe contratado no es lo mismo que dinero recibido. Un saldo pendiente no es lo mismo que margen. La corrección fue separar conceptos y nombrarlos con precisión.
Sprint 7 — hardening, QA y producción
Revisión de permisos, errores de estado, validaciones, responsive, performance básica y despliegue en Vercel. Los agentes fueron especialmente útiles para tareas repetibles: detectar tipos inconsistentes, agregar pruebas focalizadas, mejorar estados vacíos.
La revisión humana se concentró en flujos completos: crear embarcación → crear cliente → abrir solicitud → confirmar reserva → asignar crew → registrar pago → revisar saldo → ver portal. Ahí aparecen los errores reales, no en funciones aisladas.
Qué hicieron bien los agentes
Los Claude Code agents funcionaron mejor con tareas pequeñas, criterios de aceptación claros y contexto delimitado:
- Crear pantallas CRUD dentro de un módulo existente
- Refactorizar componentes repetidos
- Agregar filtros y estados de carga
- Escribir validaciones de formularios
- Corregir errores de TypeScript
- Proponer pruebas para funciones puras
- Revisar inconsistencias entre nombres, tipos y props
Los agentes redujeron el costo de pasar de decisión a código. El cuello de botella dejó de ser escribir cada línea y pasó a ser decidir correctamente qué debía existir.
Qué decidieron los humanos
Los humanos decidieron el producto. La IA ayudó a construir, pero no definió qué problema valía la pena resolver.
Scope. Decidimos qué entraba en el MVP y qué quedaba fuera: no contabilidad completa, no CRM avanzado, no pricing dinámico complejo.
Reglas de dominio. Los estados de reserva, el significado de disponibilidad, la separación entre información interna y portal de cliente, y la precisión del tracking financiero exigían criterio de industria.
Quality bar. Los humanos definieron cuándo algo estaba listo. Una pantalla puede compilar y aun así no ser usable.
Siete lecciones concretas
1. La IA acelera más cuando el dominio está claro. En charter náutico, palabras como reserva, opción, bloqueo, disponibilidad, saldo y comisión tienen implicaciones concretas. Cuando esas definiciones estaban claras, los agentes avanzaban rápido.
2. Los módulos deben tener límites fuertes. La modularidad no fue preferencia estética — fue condición para trabajar con IA sin perder control.
3. TypeScript es una herramienta de coordinación. En un proyecto con agentes, TypeScript estricto funciona como red de seguridad y contrato compartido.
4. Los prompts no compensan mala arquitectura. Nombres claros, funciones pequeñas, módulos coherentes y estados explícitos valen más que instrucciones largas.
5. Las finanzas necesitan lenguaje preciso. No es lo mismo importe contratado, pago recibido, saldo pendiente, costo, comisión o margen.
6. El portal externo exige otra capa mental. Una vista interna y una vista de cliente no son el mismo producto con distinto CSS.
7. Production-ready no significa terminado. El MVP quedó listo para operar, validar y evolucionar — no para tener todas las features imaginables.
Cómo se relaciona con la arquitectura SaaS
Este proyecto también implicó decisiones de infraestructura. Si estás evaluando dónde alojar un SaaS similar, la comparativa de infraestructura SaaS vertical cubre AWS, Vercel y Railway con criterios concretos para equipos pequeños. Y para medir si el lanzamiento está funcionando, el artículo sobre KPIs en los primeros 90 días da el framework operativo.
Cómo puede ayudarte solu30
En solu30 trabajamos en desarrollo SaaS con inteligencia artificial para convertir procesos complejos en productos operativos. No se trata de pedirle a una IA que "haga una app", sino de diseñar una arquitectura clara, dividir el trabajo en módulos, usar agentes para acelerar implementación y mantener revisión humana donde importa.
Si tu empresa necesita construir un SaaS B2B, modernizar una operación interna o convertir un proceso manual en una plataforma digital, podemos ayudarte a diseñar el producto, implementar el MVP y preparar una base técnica que soporte crecimiento real. El primer paso es una conversación en solu30.io.
Pasos concretos para validar un SaaS vertical antes de desarrollar:
- Identificá 10 potenciales clientes del nicho y pediles 30 minutos
- Mostrales el problema, no la solución: ¿lo reconocen?
- Presentá un mockup o flujo en papel y pedí feedback sobre precio
- Conseguí 3 pre-compromisos antes de escribir una línea de código
- Construí el MVP solo con las 2-3 funciones que los 3 validaron
Preguntas frecuentes
¿Por qué un SaaS para charter náutico necesita un enfoque distinto a un sistema genérico de reservas?
Porque una reserva náutica combina disponibilidad de flota, puerto base, tripulación, costos variables, estados comerciales y restricciones operativas. Si modelás esto como una simple reserva de calendario, terminás mezclando datos críticos y generando errores difíciles de corregir.
¿Qué papel tuvieron los agentes de IA en el desarrollo de TheCharterPanel?
Los agentes ayudaron a acelerar tareas concretas como scaffolding de módulos, formularios, tablas, filtros y componentes por dominio. Pero no deberías delegar decisiones de alcance, arquitectura crítica o reglas del negocio sin supervisión humana.
¿Cómo lograron llegar a un MVP production-ready en aproximadamente 90 días?
El equipo redujo fricción usando Next.js, TypeScript estricto, PlanetScale, Vercel y una arquitectura modular por dominio. La clave fue definir límites claros para flota, reservas, clientes, tripulación y finanzas antes de pedirle trabajo a los agentes.
¿Por qué TypeScript estricto fue importante al trabajar con IA?
TypeScript ayudó a convertir reglas del negocio en tipos, estados y funciones claras, en vez de depender solo de prompts largos. Cuando el código expresa intención, los agentes tienen menos espacio para inventar supuestos incorrectos.
¿Qué partes del sistema no conviene dejar decidir al frontend?
Las validaciones de disponibilidad, los cambios de estado, los cálculos financieros y cualquier operación que afecte datos compartidos deben vivir cerca del servidor. Podés tener una interfaz rica, pero la lógica crítica necesita una fuente confiable y controlada.