Ejemplo de creación / Feedback Dock
Un MVP con estructura de SaaS, no una maqueta de panel
El ejemplo es útil sólo cuando dos equipos pueden utilizarlo sin ver los registros del otro. La prueba es el límite de permiso, no el número de pantallas.
Los registros necesitan un lugar persistente. Adios puede vincular datos persistentes mediante bases de datos gestionadas para tu aplicación.
Cuentas
Un propietario y un miembro pueden iniciar sesión.
Separación de tenants
Cada proyecto pertenece a un equipo.
Flujo de trabajo
Los miembros crean y resuelven los comentarios.
Pruebas
Las pruebas de acceso entre equipos fallan de forma segura.
Antes del prompt
Definir el límite del tenant antes de pedir pantallas
Un prompt de SaaS necesita algo más que colores y funciones. Define quién es propietario de un espacio de trabajo, quién puede unirse y qué registros nunca deben cruzar ese límite.
Una tarea por la que merece la pena pagar
Elige un único resultado que deba completar el cliente. Deja los flujos secundarios para más adelante.
Funciones designadas
Empieza con propietario y miembro salvo que el producto necesite otro rol.
Registros propiedad del tenant
Identifica cada proyecto, comentario, invitación y registro de plan con el equipo propietario.
Límite de facturación
Modela el plan ahora. Conecta la facturación de prueba solo después de que pasen la identidad y el flujo de trabajo principal.
Si este es tu primer proyecto dirigido mediante prompts, empieza con crear tu primera aplicación con IA y vuelve cuando su ciclo de revisión te resulte familiar.
Alcance antes del código fuente
Pide al agente que convierta la idea en un plan de SaaS de alcance limitado
Rellena los cinco campos entre corchetes. El agente debe inspeccionar el espacio de trabajo actual y esperar para que puedas corregir el recorrido del usuario o el modelo de tenants antes de cambiar archivos.
Ayúdame a planificar un pequeño MVP de SaaS en este espacio de trabajo de Adios. No edites ningún archivo todavía.
El producto:
- Nombre: [SAAS NAME]
- Cliente: [ONE TYPE OF CUSTOMER]
- Problema: [ONE COSTLY OR FRUSTRATING PROBLEM]
- Resultado principal: [WHAT THE CUSTOMER CAN FINISH]
- Roles: [OWNER, MEMBER, OR OTHER REQUIRED ROLES]
Para la primera versión, incluye solo:
- inicio de sesión de cuentas;
- un espacio de trabajo o equipo por cliente;
- [THE ONE CORE WORKFLOW];
- una vista de propietario y una de miembro;
- un campo de plan sencillo, sin facturación real; y
- un estado vacío claro y datos de ejemplo para probar.
Deja esto para más adelante:
- [FEATURE 1];
- [FEATURE 2]; y
- cobro de suscripciones reales.
Primero inspecciona el código fuente actual, el framework, las pruebas, la configuración de base de datos y adios.yaml. Después dame:
1. un recorrido del usuario en lenguaje sencillo;
2. el modelo de datos más pequeño;
3. los límites de tenants y permisos;
4. las páginas o rutas de API que cambiarías;
5. las comprobaciones que ejecutarás; y
6. cualquier decisión que necesites de mí.
Espera mi aprobación antes de editar.Lo que una respuesta útil contiene
- Un recorrido principal del cliente
- Un modelo de datos que distingue tenants
- Permisos explícitos de propietario y miembro
- Una lista de características aplazadas deliberadamente
Crear la parte aprobada
Generar el flujo de trabajo y demostrar el límite del equipo
Pega esto solo cuando el plan coincida con el producto que quieres. Mantiene la facturación real fuera de la primera implementación y pide una prueba de acceso entre equipos.
Implementa el MVP de SaaS a partir del plan que he aprobado.
Requisitos:
- Conserva el framework actual, el gestor de paquetes, la ruta de salud y la configuración de despliegue de Adios.
- Conserva adios.yaml y explica cualquier cambio necesario antes de hacerlo.
- Usa el enfoque de autenticación establecido del proyecto. No inventes almacenamiento de contraseñas ni criptografía.
- Aplica el límite del equipo en el acceso a datos del servidor, no solo ocultando controles de la interfaz.
- Almacena los registros persistentes en la base de datos configurada y añade migraciones reversibles cuando el proyecto use migraciones.
- Da a las cuentas nuevas un estado vacío útil y proporciona datos iniciales de desarrollo claramente identificados.
- Trata el campo de plan solo como estado del producto. No conectes pagos reales en este incremento.
- Mantén los valores secretos fuera del código fuente. Referencia los valores necesarios por el nombre de la variable de entorno.
- No inventes testimonios, logotipos de clientes, cifras de uso, ingresos ni certificaciones de seguridad.
- Añade o actualiza las pruebas del flujo de trabajo principal y de un usuario que intente acceder a los datos de otro equipo.
- Ejecuta los comandos existentes del formateador, lint, pruebas y compilación.
Al terminar, muéstrame:
1. los archivos modificados;
2. el modelo de datos y permisos;
3. los resultados de las pruebas;
4. las variables de entorno que debo configurar en Adios; y
5. una lista de verificación manual de la vista previa.
No despliegues en producción.Lo que una respuesta útil contiene
- Registros persistentes reales en lugar de tarjetas estáticas
- Aplicación de permisos en el servidor
- Recorridos de vista previa con datos de ejemplo para ambos roles
- Comprobaciones automatizadas más una lista de prueba manual
Añadir facturación por separado
Planificar suscripciones en modo de prueba sin ocultar las obligaciones
La facturación es un incremento independiente. Este prompt pide un diseño específico del proveedor, webhooks firmados, idempotencia y las decisiones de negocio que el código no puede tomar por ti.
Planifica un incremento separado de facturación en modo de prueba para este SaaS. No edites ni despliegues todavía.
Usa el proveedor de pagos que confirme: [PROVIDER]. Usa su SDK oficial actual y el pago alojado o portal de facturación cuando corresponda. Nunca recojas ni almacenes datos de tarjeta sin procesar en esta aplicación.
El plan debe cubrir:
- los identificadores de productos y precios almacenados como configuración;
- el pago en modo de prueba;
- la verificación de webhooks firmados;
- la gestión idempotente de eventos;
- las transiciones de estado de suscripciones y los pagos fallidos;
- qué funciones, si las hay, están limitadas por autorización en el servidor;
- el comportamiento de cancelación y del portal de facturación;
- los nombres de secretos que se deben configurar en Adios; y
- los casos de prueba automatizados y manuales.
Enumera las decisiones sobre impuestos, reembolsos, privacidad, soporte y precios que siguen siendo mi responsabilidad. Espera mi aprobación antes de cambiar archivos.Lo que una respuesta útil contiene
- El modo de prueba permanece separado de las credenciales reales
- Verificación de Webhook y comportamiento de repetición
- Decisiones sobre derechos de acceso en el servidor
- Una lista de obligaciones comerciales no resueltas
Revisión antes de publicar
Solicitar pruebas, riesgos restantes y una parada antes de desplegarse
Ejecuta esto cuando funcione la vista previa. Convierte las comprobaciones importantes de permisos y configuración en una decisión de publicación que sigues controlando.
Realiza una revisión final de la versión de este MVP de SaaS. Corrige solo problemas confirmados y no despliegues.
Verifica:
- que un cliente nuevo pueda crear una cuenta y completar el flujo de trabajo principal;
- que otro equipo no pueda leer ni modificar los datos del equipo;
- que las acciones exclusivas del propietario se apliquen en el servidor;
- que los estados vacíos, de carga, validación, acceso prohibido y error sean comprensibles;
- que las migraciones de base de datos y la carga de datos iniciales sean seguras para el entorno de destino;
- que no se incluya en un commit ningún token, contraseña, clave privada ni cadena de conexión;
- que la ruta de salud y la configuración existente de despliegue de Adios sigan funcionando;
- que pasen el formateador, lint, las pruebas y la compilación de producción existentes; y
- que la facturación real esté desactivada salvo que yo la haya aprobado y configurado por separado.
Devuelve las pruebas, los riesgos pendientes, los secretos necesarios en Adios y una lista de verificación manual de producción. Detente antes del despliegue para obtener mi aprobación.Lo que una respuesta útil contiene
- Pruebas de aislamiento entre tenants
- Comprobaciones del repositorio correctas
- Secretos nombrados sin sus valores
- Una decisión de despliegue controlada por el ser humano
Prueba el resultado
Una compilación correcta es el comienzo de la revisión
Abre la vista previa y realiza tú mismo los recorridos importantes. Pide pruebas al agente, pero no confundas su resumen con tu aprobación.
Acceso del tenant
- Un miembro del Equipo A no puede leer, adivinar, actualizar o borrar los registros del Equipo B.
- Sólo un propietario puede invitar a miembros o cambiar el campo del plan del equipo.
- Un miembro eliminado pierde el acceso en la siguiente solicitud protegida.
Recorrido del producto
- Un nuevo equipo ve un estado vacío útil y puede crear su primer proyecto.
- Un miembro puede agregar, actualizar y resolver los comentarios en el orden previsto.
- La validación y las solicitudes fallidas dejan al usuario con un paso siguiente claro.
Pruebas de la versión
- Las migraciones se aplican a una base de datos de prueba limpia.
- Pasan las comprobaciones del formateador, lint, pruebas, compilación y salud.
- Los registros explican fallos sin grabar secretos o contenido privado.
Punto de aprobación humana
Despliega el MVP solo cuando se respete el límite
Una página de precios pulida no puede salvar un modelo de tenants roto. Revisa las pruebas del agente, repite tú mismo la prueba con dos equipos, configura los secretos por nombre en Adios y aprueba solo la versión que viste en la vista previa.
alojar y desplegar el SaaS terminado creado con IA- 01Previsualiza la versión candidata exacta con dos cuentas de equipos distintos.
- 02Confirma que pasan las migraciones, las comprobaciones de salud y todas las del repositorio.
- 03Configura los valores necesarios mediante los secretos de Adios, nunca en archivos incluidos en commits.
- 04Mantén desactivada la facturación de prueba salvo que su incremento separado haya pasado las pruebas.
- 05Aprueba la versión y verifica después el inicio de sesión y el flujo de trabajo principal en la URL pública.
Preguntas antes de comenzar
Lo que promete esta guía y lo que no
¿Puede una persona sin experiencia en desarrollo crear un MVP de SaaS con IA?
Una persona sin experiencia en desarrollo puede dirigir un MVP de alcance limitado, pero debe definir al cliente, probar los permisos y los recorridos de fallo, y asumir las decisiones de facturación, privacidad, soporte y lanzamiento. Los prompts de esta guía hacen explícitos esos puntos de revisión.
¿Por qué la guía retrasa la facturación real?
La identidad, el aislamiento entre tenants y el flujo de trabajo principal deben funcionar antes de que el estado de pago añada más modos de fallo. La facturación se planifica y prueba como un incremento separado con pago alojado por el proveedor, webhooks firmados y aprobación humana.
¿Cómo deben separarse los datos de los tenants?
Cada registro de un tenant debe identificar al equipo o espacio de trabajo propietario, y cada operación protegida del servidor debe hacer cumplir ese límite. Ocultar los registros de otro equipo en la interfaz no basta.
¿Puedo seguir cambiando el SaaS después del lanzamiento?
Sí. Continúa en el espacio de trabajo respaldado por código fuente, haz un cambio de alcance limitado, pruébalo en la vista previa, revisa el diff y las comprobaciones y aprueba después una nueva versión sin sustituir primero la versión pública actual.