Orchids

Você descrevia a aplicação que queria e o Orchids produzia um projeto, não uma imagem de um. Isso significava arquivos reais e componentes reais que você podia executar. Não um mockup de design que você ainda teria que construir à mão. Para quem não tem base em programação, esse era todo o atrativo. A pegadinha? Prompts vagos davam resultados vagos. A qualidade da saída acompanhava a clareza da sua descrição. Sem código para arrumar à mão, você tinha que acertar a descrição nas primeiras tentativas.

O Orchids não parava no front end. Ele montava as peças de backend que uma aplicação funcional precisa, com lógica de aplicação e um banco de dados, para que recursos como formulários e contas guardassem dados reais. Essa é a diferença entre um site que parece pronto e um que funciona. Isso fazia o Orchids servir para aplicações web pequenas, não só para páginas institucionais. O que fosse complexo ainda precisava de uma pessoa conferindo a saída.

Cada mudança aparecia numa pré-visualização ao vivo, e você refinava o resultado conversando em vez de editar código. Podia pedir um layout diferente, um campo novo ou uma troca de cor e ver aplicado. Esse ciclo tornava a ferramenta acessível. Você julgava a aplicação olhando para ela, não lendo arquivos de código. Também significava que a maior parte do seu tempo ia para descrever a intenção com clareza, algo que alguns acharam mais difícil do que esperavam. Programar em linguagem natural parece simples até você precisar ser específico.

Os projetos que precisavam guardar dados podiam usar um banco de dados gerenciado provisionado para você. Um formulário de cadastro, uma lista de tarefas ou um pequeno gestor de clientes conseguia guardar registros reais sem você montar um servidor ou escrever scripts de migração. Para usuários sem perfil técnico, isso removia um dos maiores obstáculos para construir algo interativo. Nenhum servidor para vigiar. A contrapartida era o controle. Você trabalhava dentro da configuração gerenciada em vez de ajustar o banco de dados por conta própria.

O Orchids cuidava da implantação, então um projeto pronto podia entrar no ar numa URL pública de dentro do painel. Sem conta de hospedagem separada. Sem pipeline de CI. Você podia mostrar seu trabalho sem sair da ferramenta. Quando o serviço fechou, essa conveniência virou o problema: os projetos implantados pararam de funcionar e tiveram que ser reivindicados ou movidos para outro host. É um lembrete de que hospedagem atrelada a uma única ferramenta vive e morre com essa ferramenta.

Junto com a versão web, o Orchids oferecia um aplicativo de desktop que guardava seus projetos localmente, geralmente numa pasta da sua máquina. Para quem se importava em conservar o trabalho, essa cópia local fazia diferença. Ele sobreviveu ao encerramento sem nenhum passo de migração. Um recurso pequeno que, visto com o tempo, acabou sendo um dos mais úteis.