Plataforma de Generación de Leads con IA — Caso de Éxito SaaS

Este es el caso de estudio del SaaS de generación de leads con IA que construí y envié a producción como desarrollador full-stack solitario. El producto ayuda a los equipos de ventas a encontrar, filtrar y contactar a los leads correctos sin perder una semana por campaña en investigación manual. Nacido en España, radicado en Paraguay, me hice cargo del desarrollo desde el repositorio vacío hasta el despliegue en producción y la ventana de soporte posterior al lanzamiento.

¿Cuál era el problema?

Los equipos de ventas se ahogaban en listas de leads que eran 90 % ruido. El flujo anterior era: scrapear una lista, filtrar a mano en una hoja de cálculo, escribir el copy de outreach uno por uno, pegarlo en un CRM, hacer seguimiento manual y repetir. Las partes repetitivas se comían el tiempo de los representantes senior, mientras que la venta real — las conversaciones — quedaba apretada en los márgenes del día.

La hipótesis detrás del producto era simple: la mayor parte del filtrado y la primera versión del copy de outreach son tareas de reconocimiento de patrones que un LLM puede ejecutar bien, si se le da el contexto correcto y un contrato estricto de salida estructurada. El equipo no necesitaba otra herramienta de IA genérica; necesitaba un SaaS enfocado que recibiera sus listas existentes, aplicara sus propias reglas de calificación y devolviera borradores de outreach priorizados y listos para enviar — con un dashboard que el personal no técnico pudiera usar realmente.

La restricción era la habitual para un SaaS construido en solitario: enviar algo por lo que los usuarios pagaran, en meses y no en trimestres, sin margen para el tipo de sobre-ingeniería que mata a los productos indie.

¿Cuál fue el enfoque?

Traté el proyecto como una construcción de SaaS MVP con una sola funcionalidad defendible — el pipeline de filtrado y outreach con IA — y todo lo demás deliberadamente aburrido. La secuencia completa que aplico está documentada en crear MVP rápido con IA; este proyecto la siguió de cerca.

El plan por fases:

1. Discovery y spec. Fijar la única funcionalidad que hacía que el producto valiera la pena enviar (el pipeline de scoring + outreach con IA), acordar las tres que podían esperar y congelar el modelo de datos antes de escribir código.
2. Slice vertical primero. Camino feliz de extremo a extremo desde la autenticación hasta la carga de leads, el scoring y un único borrador de outreach — desplegado en staging dentro de la semana uno. Esto forzó a que cada sistema existiera en forma esquelética antes de pulir cualquiera de ellos.
3. Ajustar el loop de IA. Iteración de prompts contra un set de evaluación congelado de leads reales con resultados conocidos buenos/malos. El paso de scoring se ejecutó primero; el paso de generación de copy se conectó una vez que el scoring era confiable.
4. Endurecimiento para producción. Facturación con Stripe, idempotencia de webhooks, aislamiento multi-tenant en Postgres, monitoreo de errores, registro de auditoría y exportación y eliminación de datos conforme al RGPD.
5. Envío y traspaso. Despliegue en producción en la propia cuenta de AWS del cliente, llamada de traspaso de 90 minutos, runbook escrito en el repositorio y ventana de 14 días para corrección de errores posterior al lanzamiento.

No hubo sorpresas en el calendario porque el spec era lo suficientemente específico como para rechazar el scope drift. Las solicitudes nuevas después del cierre del spec iban a una lista v2, no a la iteración v1.

¿Qué incluye el stack?

El stack se mantuvo deliberadamente aburrido porque el valor diferenciador vivía en el pipeline de IA, no en la elección de framework.

• SvelteKit + TypeScript en el front-end. Menos conceptos que Next.js, bundles más pequeños, SSR por defecto para las páginas de marketing y CSR-tras-hidratación para la aplicación autenticada. La documentación de SvelteKit cubre el modelo de renderizado.
• Node.js + Express + Prisma en el backend. API REST, tipado completo de extremo a extremo a través de tipos generados por Prisma y esquemas Zod compartidos. Los trabajos en segundo plano corrían en un proceso worker separado para que las peticiones HTTP nunca se bloquearan por la latencia de los LLM.
• PostgreSQL en AWS RDS como sistema de registro. Migraciones versionadas en git. Aislamiento de inquilinos a nivel de fila aplicado en la capa de consulta.
• API de OpenAI para los pasos de scoring de leads y generación de copy. Salidas estructuradas (modo JSON) para que el código downstream pudiera parsear los resultados sin gimnasia de regex. Prompts versionados en código; comportamiento reproducible entre despliegues. La documentación de OpenAI cubre los contratos de salida estructurada en los que me apoyé.
• Stripe para todo lo de facturación — Checkout, Customer Portal, estado de suscripción manejado por webhooks, reintentos, dunning, Stripe Tax. Webhooks firmados e idempotentes. La documentación de facturación de Stripe es la referencia que envío a quien conecta su primer producto de suscripción.
• AWS para hospedaje — EC2 para la aplicación y el worker, RDS para Postgres, S3 para las listas de leads subidas por los usuarios, CloudFront para los activos estáticos, IAM para roles de servicio con privilegio mínimo. Desplegado en la propia cuenta de AWS del cliente para que la propiedad y la facturación quedaran de su lado.
• GitHub Actions para CI — chequeo de tipos, lint, pruebas unitarias, validación de migraciones de Prisma y un paso de despliegue con aprobación manual.

Cada pieza está documentada individualmente y es reemplazable. Sin bloqueo propietario. Si el equipo me prescinde algún día, se queda con un stack que su próximo desarrollador ya conoce.

¿Cuál fue el resultado?

La plataforma salió a producción en plazo. Usuarios pagos la adoptaron. El equipo continuó operando y extendiendo el producto después del cierre de mi contrato — que es el resultado que importa de verdad para un SaaS construido en solitario, más que cualquier métrica de vanidad del día de lanzamiento.

Algunas notas cualitativas que vale la pena destacar sin inventar números:

• El paso de scoring con IA redujo el tiempo por barrido de lista de leads de una tarea de jornada completa a una tarea de pausa de café, según el feedback interno del propio equipo.
• El dashboard era usable por personal no técnico sin sesión de capacitación — la UI de dropdowns y filtros cargaba la carga cognitiva que la IA dejaba de cargar.
• El cableado de Stripe no fugaba ingresos. Los pagos fallidos pasaban al flujo de dunning, se recuperaban en su mayoría de forma automática y el resto llegaba a un humano en un día en lugar de pasar inadvertido.
• La plataforma se mantenía en línea sin necesidad de tenerme de guardia. El runbook más el monitoreo de errores hacían que el equipo manejara las operaciones normales por su cuenta.

No incluyo una cifra de ingresos que no pueda verificar de forma independiente; su ausencia no es un fracaso, es una restricción deliberada sobre lo que afirma este caso de estudio.

¿Qué aprendí?

Algunas lecciones aterrizaron más fuerte de lo esperado.

El stack aburrido es el stack correcto cuando el diferenciador está en otro lado. Gastar una semana extra investigando el "mejor" framework no habría aportado nada. SvelteKit + Node + Postgres alcanza para casi cualquier SaaS a la escala de un primer producto, y el tiempo ahorrado se invirtió en el pipeline de IA, donde realmente importaba.

El harness de evaluación antes que la iteración de prompts, no después. Construí el set de evaluación unas semanas más tarde de lo que debería. Una vez que existió, cada cambio de prompt tomaba diez minutos de validación en lugar de una hora de inspección manual. Si lo construyo de nuevo, el set de evaluación es trabajo de la primera semana.

El endurecimiento de los webhooks de Stripe no es opcional. Cada SaaS que vi fugar ingresos los fugó por handlers de webhooks no firmados, no idempotentes o no reproducibles. Hacerlo correctamente la primera vez evitó toda una clase de incidentes. El patrón está bien documentado; no hay excusa para no seguirlo.

Documentar el runbook operativo mientras se construye, no en el traspaso. El runbook del repositorio creció junto con las funcionalidades. Para cuando llegó la llamada de traspaso, el documento ya estaba completo porque cada sistema había quedado por escrito el día en que se cableó.

Para el contexto metodológico sobre cómo secuencio este tipo de trabajos, ver crear MVP rápido con IA y cuánto cuesta un SaaS MVP. Para el razonamiento más amplio sobre stack, ver mejor stack para SaaS con IA en 2026. La página completa del servicio SaaS MVP cubre alcance y precios para una construcción similar, y automatización con IA cubre el lado de la integración con OpenAI como un compromiso independiente.

Escribime a [email protected] con un párrafo describiendo tu idea si querés hablar de algo en esta línea. Estilo de repositorio y cadencia de commits visibles en github.com/ignaxdev.