Killer SaaS: el método para clonar cualquier SaaS en un día
Mike Codeur
📺 Este artículo se basa en el vídeo completo. Míralo aquí: https://mkc.sh/killer-saas
Hace unas semanas grabé un vídeo en el que anunciaba el final de los SaaS de una sola funcionalidad. Esos pequeños productos que un desarrollador sacaba en un par de fines de semana para generar ingresos extra. Hoy cualquiera con un agente de código puede reproducirlos, así que ese modelo se acabó.
Dábamos por hecho que los SaaS algo más avanzados sí estaban a salvo. No lo están. Con el método adecuado se puede reproducir prácticamente cualquier tipo de SaaS. Es lo que muestro en este vídeo.
El detonante: 1.800 dólares al año para nada
Tengo una plataforma que aloja mis formaciones, las que conocéis: Next Mastery, React Mastery y las demás. Me cuesta más de 1.800 dólares al año.
El problema es que os regalé esas formaciones. Ya no me generan ningún ingreso, pero siguen costándome 1.800 dólares cada año.
Es exactamente el tipo de situación en el que reconstruir la herramienta internamente sale rentable.
El objetivo no es competir con Podia
Seamos claros con la intención. El objetivo no es construir un SaaS para enfrentarse a Podia o Teachable en su mercado.
El objetivo es tener herramientas internas que ahorren dinero. La diferencia importa: una herramienta interna no necesita soporte al cliente, ni marketing, ni facturación multidivisa, ni cumplimiento normativo a gran escala. Solo tiene que hacer el trabajo que tú necesitas, para ti.
Por qué creé un método propio
He probado muchos métodos agénticos. Super Power, Every Single Code, Matob, GStack, Spec Kit, los sistemas tipo agencia. Hablo de ellos a menudo en el canal.
Son muy buenos métodos y permiten hacer ingeniería de verdad. Pero son generalistas. Ninguno está pensado para un objetivo concreto: reproducir un SaaS existente, rápido y con calidad de producción.
Por eso desarrollé Killer SaaS, un método que reproduce casi cualquier tipo de SaaS en aproximadamente un día.
El flujo de trabajo, paso a paso
El método funciona por historia de usuario. Para cada una, el agente encadena las mismas fases:
- Research: busca lo que necesita la historia. Rutas, componentes, detalle exacto de los campos, estructura de datos.
- Diseño: produce las pantallas correspondientes.
- Planificación detallada: desglosa la implementación.
- Ejecución: escribe el código.
- Revisión: revisa su propio trabajo.
- Ship: crea la pull request, la fusiona, y el cambio pasa a producción.
En cualquier momento del flujo, un comando indica en qué punto estamos:
ks statusks de Killer SaaS. Ves de inmediato el avance de cada historia.
El desglose en historias de usuario
El primer paso pasa por un skill dedicado, agentic-stories, que convierte la necesidad en historias de usuario utilizables. Cada historia se redacta en el formato clásico, «como formador, quiero…», con sus criterios de aceptación.
Comandos, no prompts
Trabajo mucho mediante comandos. El método se basa en Claude, pero está adaptado a Codex: cada comando existe con un destino distinto. Por defecto es Claude, y tienes las variantes para Codex, por proyecto o globales.
El boilerplate, lo que realmente hace ganar el día
La velocidad no viene solo del agente. Viene sobre todo de que la base técnica ya está montada. Lo que incluye el boilerplate:
- Pagos: el SDK de Stripe
- Autorización: CASL
- Validación: Zod
- Multiidioma: i18n con next-intl
- Formularios: React Hook Form
- Almacenamiento de imágenes: Supabase
- Jobs: Inngest
- Tests unitarios y tests end-to-end
Los tests end-to-end, el punto que subestimaba
Antes hacía los tests end-to-end por tranquilidad de conciencia. Me decía que estaba bien tenerlos, y poco más.
Lo que ha cambiado: una vez los tests end-to-end están en su sitio, Claude sabe usarlos perfectamente. Es capaz de conectarse, crear datos, ejecutar un recorrido completo. Se convierten en una herramienta de verificación para el propio agente, no solo en una casilla que marcar.
La estructura por capas
El repositorio sigue una división clásica pero estricta, bajo src/app:
- la capa de servicios, dividida por autenticación, autorización, fachadas, validaciones y validadores;
- la capa DB, con los modelos y los repositorios.
Cuando el agente implementa una historia, sí pasa por la capa de servicio y la fachada, tal y como especifica el boilerplate. No es él quien decide la arquitectura: la arquitectura ya está definida.
El paralelismo
Este es el punto que cambia la relación con el tiempo. Las fases de research y diseño no se ejecutan historia tras historia: todas las historias de usuario se lanzan en paralelo.
Mientras el agente trabaja en una historia, también trabaja en las demás. Es lo que permite aguantar en un día en lugar de una semana.
El resultado
Al final del ciclo, más de 20 pull requests fueron fusionadas, generadas automáticamente por Claude.
La aplicación funciona: tema claro y oscuro, catálogo de formaciones, página de perfil y compra de una formación directamente a través de Stripe. Con la tarjeta de prueba de Stripe, el pago funciona de principio a fin.
Lo que no es perfecto
Prefiero decirlo. El resultado no está terminado en el sentido de producto.
Queda trabajo visual: las imágenes no están puestas, los datos mostrados siguen siendo de prueba y algunas pantallas merecerían otra pasada de diseño. La fase de design system debería ir más lejos en las maquetas.
Un punto de método que haría distinto: es mejor separar el design system y cada pantalla en lugar de lanzarlo todo de golpe. Sin la fase de research previa, el agente no conoce el detalle exacto de los campos y produce maquetas aproximadas.
Lo que hay que retener
Reproducir un SaaS avanzado ya no es cuestión de meses de desarrollo. Es cuestión de método, de una base técnica preparada y de un agente al que se deja trabajar en paralelo sobre historias bien desglosadas.
El cálculo real no es «puedo ganarle a Podia». Es «¿sigue mereciendo la pena esta suscripción anual frente al día de trabajo que me costaría sustituirla?».
En mi caso, a 1.800 dólares al año por un servicio del que solo uso una fracción, la respuesta era no.
Para profundizar
📺 El vídeo completo: https://mkc.sh/killer-saas