Exemplo de projeto / Feedback Dock
Um MVP que funciona como SaaS, além de uma maquete de painel
O exemplo é útil apenas quando duas equipes podem usá-lo sem ver os registros uma da outra. A prova é o limite de permissão, não o número de telas.
Os registros precisam de armazenamento durável. Adios pode conectar dados persistentes por meio de bancos de dados gerenciados para sua aplicação.
Contas
Um proprietário e um membro podem entrar.
Separação entre clientes
Cada projeto pertence a uma equipe.
Workflow
Os membros criam e resolvem feedback.
Evidências
Tentativas de acesso entre equipes são bloqueadas com segurança nos testes.
Antes de enviar o prompt
Defina o isolamento entre clientes antes de pedir telas
Um prompt SaaS precisa de mais do que cores e funcionalidades. Defina quem é dono de um espaço de trabalho, quem pode entrar nele e quais registros nunca podem cruzar esse limite.
Uma tarefa pela qual vale a pena pagar
Escolha o único resultado que o cliente deve concluir. Deixe os workflows secundários para depois.
Papéis definidos
Comece com proprietário e membro, salvo se o produto realmente precisar de outro papel.
Registros pertencentes a cada cliente
Identifique a equipe proprietária em cada projeto, item de feedback, convite e registro de plano.
Limites da cobrança
Modele o plano agora. Conecte a cobrança de teste somente depois que identidade e workflow principal passarem nas verificações.
Se este é seu primeiro projeto orientado por prompts, comece com criar sua primeira aplicação com IA e volte quando estiver familiarizado com o ciclo de revisão.
Escopo antes do código-fonte
Peça ao agente para transformar a ideia em um plano SaaS bem delimitado
Preencha os cinco campos entre colchetes. O agente deve examinar o espaço de trabalho atual e aguardar, para que você possa corrigir a jornada do usuário ou o modelo de isolamento entre clientes antes de alterar os arquivos.
Ajude-me a planejar um pequeno MVP SaaS neste espaço de trabalho Adios. Não edite nenhum arquivo ainda.
O produto:
- Nome: [NOME DO SAAS]
- Cliente: [UM TIPO DE CLIENTE]
- Problema: [UM PROBLEMA CUSTOSO OU FRUSTRANTE]
- Resultado principal: [O QUE O CLIENTE PODE CONCLUIR]
- Papéis: [PROPRIETÁRIO, MEMBRO OU OUTROS PAPÉIS NECESSÁRIOS]
Na primeira versão, inclua apenas:
- login na conta;
- um espaço de trabalho ou equipe por cliente;
- [O ÚNICO WORKFLOW PRINCIPAL];
- uma visão para o proprietário e outra para o membro;
- um campo simples de plano, sem cobrança real; e
- um estado vazio claro e dados de exemplo para testes.
Deixe para depois:
- [FUNCIONALIDADE 1];
- [FUNCIONALIDADE 2]; e
- cobrança real de assinaturas.
Primeiro, examine o código-fonte atual, o framework, os testes, a configuração do banco de dados e adios.yaml. Depois, forneça:
1. uma jornada do usuário em linguagem simples;
2. o menor modelo de dados;
3. os limites de isolamento entre clientes e de permissões;
4. as páginas ou rotas de API que você alteraria;
5. as verificações que executará; e
6. qualquer decisão de que precise de mim.
Aguarde minha aprovação antes de editar.O que uma resposta útil contém
- Uma jornada principal do cliente
- Um modelo de dados que respeita o isolamento entre clientes
- Permissões explícitas de proprietário e membro
- Uma lista de funcionalidades adiadas deliberadamente
Criar a parte aprovada
Gere o workflow e comprove o isolamento entre equipes
Cole este prompt somente depois que o plano corresponder ao produto desejado. Ele mantém a cobrança real fora da primeira implementação e pede um teste de acesso entre equipes.
Implemente o MVP SaaS a partir do plano que aprovei.
Requisitos:
- Mantenha o framework atual, o gerenciador de pacotes, a rota de saúde e a configuração de implantação Adios.
- Preserve adios.yaml e explique qualquer mudança necessária antes de fazê-la.
- Use a abordagem de autenticação já estabelecida no projeto. Não invente armazenamento de senhas nem criptografia.
- Aplique o isolamento entre equipes no acesso aos dados no servidor, além de esconder controles na interface.
- Armazene registros persistentes no banco configurado e adicione migrações reversíveis quando o projeto usar migrações.
- Dê às novas contas um estado vazio útil e forneça dados iniciais de desenvolvimento claramente identificados.
- Trate o campo de plano apenas como estado do produto. Não conecte pagamentos reais nesta etapa.
- Mantenha os valores dos segredos fora do código-fonte. Faça referência aos valores necessários pelo nome da variável de ambiente.
- Não invente depoimentos, logos de clientes, números de uso, receita ou certificações de segurança.
- Adicione ou atualize testes do workflow principal e de um usuário tentando acessar os dados de outra equipe.
- Execute os comandos existentes de formatação, lint, testes e compilação.
Ao terminar, mostre:
1. os arquivos alterados;
2. o modelo de dados e permissões;
3. os resultados dos testes;
4. as variáveis de ambiente que devo configurar no Adios; e
5. uma lista de verificações manuais em Preview.
Não implante em produção.O que uma resposta útil contém
- Registros reais persistentes em vez de cartões estáticos
- Aplicação de permissões no servidor
- Fluxos em Preview com dados iniciais para os dois papéis
- Verificações automatizadas mais uma lista de testes manual
Adicionar cobrança separadamente
Planeje assinaturas em modo de teste sem esconder as responsabilidades
A cobrança é uma etapa própria. Este prompt pede um projeto específico para o provedor, webhooks assinados, idempotência e as decisões de negócio que o código não pode tomar por você.
Planeje uma etapa separada de cobrança em modo de teste para este SaaS. Não edite nem implante ainda.
Use o provedor de pagamentos que eu confirmar: [PROVEDOR]. Use seu SDK oficial atual e checkout ou portal de cobrança hospedado quando apropriado. Nunca colete nem armazene dados brutos de cartão nesta aplicação.
O plano deve cobrir:
- os identificadores de produtos e preços armazenados como configuração;
- checkout em modo de teste;
- verificação de webhooks assinados;
- tratamento idempotente de eventos;
- transições de estado das assinaturas e pagamentos em falha;
- quais funcionalidades, se houver, dependem de autorização no servidor;
- comportamento de cancelamento e do portal de cobrança;
- nomes dos segredos a configurar no Adios; e
- casos de teste automatizados e manuais.
Liste as decisões sobre impostos, reembolso, privacidade, suporte e preços que continuam sob minha responsabilidade. Aguarde minha aprovação antes de alterar arquivos.O que uma resposta útil contém
- O modo de teste permanece separado das credenciais reais
- Verificação de webhooks e comportamento de reenvio
- Decisões de direitos de acesso no servidor
- Uma lista de obrigações comerciais não resolvidas
Revise antes da implantação
Peça evidências, riscos remanescentes e uma parada antes de implantar
Execute este prompt depois que Preview funcionar. Ele transforma as verificações importantes de permissões e configuração em uma decisão de implantação que você continua controlando.
Faça uma revisão final de implantação deste MVP SaaS. Corrija apenas problemas confirmados e não implante.
Verifique:
- um novo cliente consegue criar uma conta e concluir o workflow principal;
- os dados de uma equipe não podem ser lidos nem alterados por outra equipe;
- ações exclusivas do proprietário são protegidas no servidor;
- estados vazios, de carregamento, validação, acesso proibido e erro são compreensíveis;
- migrações do banco de dados e inserção de dados iniciais são seguras para o ambiente de destino;
- nenhum token, senha, chave privada ou string de conexão foi versionado;
- a rota de saúde e a configuração de implantação Adios existente continuam funcionando;
- a formatação, o lint, os testes e a compilação de produção existentes passam; e
- a cobrança real está desativada, salvo se eu a tiver aprovado e configurado separadamente.
Retorne as evidências, os riscos restantes, os segredos Adios necessários e uma lista manual de verificações de produção. Pare antes da implantação para obter minha aprovação.O que uma resposta útil contém
- Evidências de isolamento entre clientes
- Verificações do repositório aprovadas
- Segredos nomeados sem os seus valores
- Uma decisão de implantação sob controle humano
Testar o resultado
Uma compilação bem-sucedida é o início da revisão
Abra Preview e percorra você mesmo os fluxos importantes. Peça evidências ao agente, mas não confunda o resumo dele com a sua aprovação.
Acesso por cliente
- Um membro da Equipe A não pode ler, adivinhar, atualizar ou excluir registros da Equipe B.
- Apenas o proprietário pode convidar membros ou alterar o campo de plano da equipe.
- Um membro removido perde o acesso na próxima requisição protegida.
Jornada do produto
- Uma nova equipe vê um estado vazio útil e pode criar seu primeiro projeto.
- Um membro pode adicionar, atualizar e resolver feedback na ordem pretendida.
- A validação e as requisições em falha deixam o usuário com uma próxima ação clara.
Evidências da versão
- As migrações são aplicadas a um banco de dados de teste limpo.
- Formatação, lint, testes, compilação e verificações de saúde passam.
- Os logs explicam falhas sem gravar segredos ou conteúdo privado.
Etapa de aprovação humana
Implante o MVP somente depois de comprovar o isolamento
Uma página de preços bem-acabada não corrige um modelo de isolamento entre equipes que não funciona. Revise as evidências do agente, execute você mesmo o teste com duas equipes, configure os segredos nomeados no Adios e aprove apenas a versão que você viu em Preview.
hospedar e implantar o SaaS pronto criado com IA- 01Visualize a versão candidata exata com contas de duas equipes diferentes.
- 02Confirme que as migrações, as verificações de saúde e todas as verificações do repositório passam.
- 03Configure os valores necessários pelos segredos Adios, nunca por arquivos versionados.
- 04Mantenha a cobrança de teste desativada até que sua etapa separada passe nas verificações.
- 05Aprove a versão e verifique o login e o fluxo principal na URL em produção.
Perguntas antes de começar
O que este guia promete e seus limites
Quem não é desenvolvedor pode criar um MVP SaaS com IA?
Quem não é desenvolvedor pode orientar um MVP bem delimitado, mas ainda precisa definir o cliente, testar permissões e cenários de falha e assumir as decisões sobre cobrança, privacidade, suporte e lançamento. Os prompts deste guia tornam esses pontos de revisão explícitos.
Por que o guia adia a cobrança real?
Identidade, isolamento entre clientes e o workflow principal devem funcionar antes que o estado dos pagamentos introduza novos modos de falha. A cobrança é planejada e testada como uma etapa separada, com checkout hospedado, webhooks assinados e aprovação humana.
Como separar os dados de cada cliente?
Cada registro de um cliente deve identificar a equipe ou o espaço de trabalho a que pertence, e toda operação protegida no servidor deve respeitar esse limite. Apenas esconder os registros de outra equipe na interface não é suficiente.
Posso continuar alterando o SaaS após o lançamento?
Sim. Continue no espaço de trabalho ligado ao código-fonte, faça uma mudança bem delimitada, teste-a em Preview, revise o diff e as verificações e aprove uma nova versão sem substituir primeiro a versão atual em produção.