O Base44 é uma plataforma web que transforma uma descrição em linguagem natural numa aplicação funcional. O editor reúne conversa com IA, pré-visualização interativa e painel de gestão.
Já usou esta ferramenta? Avalie-a
Já usou esta ferramenta? Avalie-a
O Base44 é uma plataforma web que transforma uma descrição em linguagem natural numa aplicação funcional. O editor reúne conversa com IA, pré-visualização interativa e painel de gestão. A partir de um pedido, pode produzir páginas, entidades de dados, formulários, regras de acesso, funções de backend, integrações e uma versão publicada. A documentação para programadores apresenta ainda o Base44 como backend gerido que pode ser consumido por uma interface externa através do SDK JavaScript e da CLI.
Esta integração reduz o trabalho inicial de escolher alojamento, base de dados, autenticação e execução de funções para testar uma ideia. Não elimina, porém, as decisões de produto, a modelação dos dados, a segurança, os testes nem a operação. Uma pré-visualização visualmente convincente pode esconder permissões demasiado amplas, estados incompletos ou falhas com dados reais. O método mais seguro consiste em criar um fluxo vertical pequeno, validá-lo com funções e utilizadores diferentes e só depois alargar o âmbito.
O percurso documentado começa com um pedido no chat, mostra páginas e dados gerados na pré-visualização e permite configurar o projeto no dashboard antes de o publicar num endereço Base44. A documentação técnica acrescenta armazenamento persistente, autenticação, atualizações em tempo real, funções TypeScript, integrações e alojamento. Trata-se, portanto, de aplicações web com estado e papéis, e não apenas de maquetas estáticas produzidas por IA.
É importante separar capacidade documentada, funcionalidade anunciada e recomendação de implementação. Os modelos disponíveis, os créditos, as funções beta e os direitos associados a cada plano podem mudar. Uma captura antiga ou um tutorial de outra conta não prova o que existe no workspace atual. Antes de assumir um compromisso de custo ou prazo, confirme a tabela oficial vigente e o comportamento observado na conta concreta.
A Wix anunciou a aquisição do Base44 em 18 de junho de 2025 e declarou que o produto continuaria a operar como negócio distinto. Este facto empresarial não demonstra que todos os serviços da Wix estejam integrados, nem que uma determinada capacidade da Wix esteja disponível numa conta Base44. Para decisões técnicas, devem prevalecer a documentação do próprio Base44 e os controlos efetivamente apresentados no workspace.
Em junho de 2026, a TechCrunch noticiou o início da disponibilização do Base1, um modelo especializado. A expressão «início da disponibilização» não equivale a acesso universal, desempenho idêntico ou custo fixo. Se o projeto depender desse modelo, a equipa deve confirmar o seletor, os créditos mostrados e o resultado real no editor no momento da avaliação.
No modo Default, o Base44 interpreta o pedido e aplica alterações à aplicação. Discuss serve para planear, esclarecer requisitos e comparar opções sem modificar o projeto. Edit permite selecionar elementos na pré-visualização e ajustar a apresentação. Como alterações manuais e assistidas podem ter efeitos diferentes no consumo de créditos, escolher o modo adequado evita reconstruções desnecessárias.
Discuss é útil para pedir uma crítica ao modelo de dados, antecipar casos-limite e formular critérios de aceitação. Edit adapta-se a tipografia, cor, espaçamento e componentes concretos. Um pedido em Default deve indicar o papel afetado, o estado inicial, a regra de negócio, o resultado esperado e o que não deve mudar. Quanto mais verificável for o pedido, mais fácil será avaliar a resposta.
O Base44 inclui entidades persistentes e um painel onde os registos podem ser consultados e geridos. A documentação descreve uma camada NoSQL, atualizações em tempo real, autenticação, funções, integrações e alojamento geridos. Também é possível utilizar estes serviços a partir de um frontend externo através do SDK, o que separa a experiência visual da infraestrutura fornecida pela plataforma.
Antes de criar muitas páginas, convém estabilizar o modelo. Separe identidade de perfil público, defina os estados válidos e associe cada registo privado ao respetivo proprietário ou organização. Numa aplicação com vários clientes, ocultar um botão não substitui uma regra de autorização que impeça a leitura ou alteração de dados pertencentes a outra organização.
O fluxo oficial cobre autenticação gerida, visibilidade da aplicação, utilizadores convidados, papéis de utilizador e administrador e permissões sobre dados. A opção de atuar como outro utilizador ajuda a testar perspetivas diferentes. Autenticar responde a quem é a pessoa; autorizar determina que objetos e ações lhe são permitidos. As duas camadas devem ser verificadas separadamente, incluindo tentativas deliberadas de acesso proibido.
A documentação consultada indica que não existe um fluxo de autenticação totalmente personalizado nem ecrãs integrados completamente white-label, sendo o white labeling apresentado como planeado. Requisitos de SSO, fornecedor de identidade ou marca integral não devem ser inferidos de uma referência secundária. Confirme-os na documentação e no plano atuais antes de desenhar a arquitetura em torno deles.
Chamadas sensíveis, webhooks, operações privilegiadas e verificações de pagamento devem ocorrer numa função de backend ou numa integração gerida. O Base44 distingue ações incorporadas, conectores cuja autorização é administrada pela plataforma e integrações do workspace importadas a partir de OpenAPI. Credenciais nunca devem aparecer no código entregue ao navegador, em prompts partilhados ou em campos comuns da base de dados.
Teste a expiração da autorização, os scopes, a paginação, os limites de pedidos, os duplicados e as falhas parciais. Registe quem é responsável pela ligação e como se repete ou reconcilia uma operação. Qualquer ação externa que mova dinheiro ou altere um estado importante precisa de verificação, idempotência e uma forma de explicar o resultado ao operador.
Segundo a documentação, as aplicações criadas a partir de 6 de julho de 2026 usam Workflows em substituição de Automations; projetos anteriores podem conservar o sistema antigo. Uma aplicação apresenta um ou outro. Workflows podem iniciar por horário, alteração de entidade, conversa com um agente interno ou evento de conector, combinando condições, esperas e ações com progresso observável por execução.
Esta transição explica por que motivo alguns tutoriais deixaram de coincidir com o produto. Antes de copiar um exemplo, confirme qual superfície existe na aplicação. Defina o evento inicial, o estado terminal e a proteção contra ciclos. Para efeitos externos, guarde uma chave que permita reconhecer um evento já processado e não repetir a mesma operação.
Cada aplicação recebe um endereço Base44 e pode ser publicada a partir do editor. Os domínios personalizados com HTTPS gerido dependem do plano aplicável. Publicar deve ser tratado como uma release: reveja papéis, permissões, segredos, scanner, integrações, domínio e procedimento de retirada ou recuperação antes de expor a aplicação a utilizadores reais.
A vista de código, a exportação ZIP e a sincronização bidirecional com GitHub apoiam desenvolvimento local, branches e pull requests em planos elegíveis. A exportação do código não reproduz automaticamente autenticação, base de dados e alojamento como componentes autoalojados. Uma migração integral precisa de substituir essas camadas e de confirmar o formato e a integridade dos dados exportados.
Estão documentados o uso em navegador móvel e aplicações de criação para iOS e Android. A aplicação publicada funciona no browser e pode ser adicionada ao ecrã principal. Algumas tarefas de administração podem exigir computador; a experiência móvel deve ser considerada uma superfície complementar e precisa de testes próprios em tamanhos, teclado e conectividade diferentes.
Num plano elegível, o Base44 pode analisar a preparação e gerar pacotes IPA e AAB. Esses pacotes são wrappers web-view da aplicação publicada, não reconstruções nativas. Atualmente não acrescentam notificações push nativas nem funcionamento offline completo. O proprietário continua responsável pelas contas Apple e Google, fichas, declarações, revisão e envio às lojas.
O scanner descrito procura permissões, credenciais expostas, verificação de login, pacotes vulneráveis e cabeçalhos. O resultado é uma lista de problemas a analisar; não transfere a responsabilidade para a plataforma nem constitui, por si só, certificação. A equipa deve compreender cada alerta, corrigir o que se aplica e repetir testes de acesso com contas e dados preparados para esse efeito.
O scanner também não substitui uma revisão independente quando existem pagamentos, dados sensíveis ou obrigações regulatórias. Nessas situações, documente o modelo de ameaça, retenção, subprocessadores e resposta a incidentes e valide-os contra os termos e controlos atuais. Não atribua ao Base44 garantias de encriptação ou conformidade que as fontes consultadas não demonstram.
Um fundador pode testar registo, introdução de dados, geração de um resultado e regresso posterior sem montar toda a infraestrutura convencional. A primeira versão deve demonstrar uma função, um objeto principal e um resultado mensurável. Num marketplace inicial, por exemplo, parte da correspondência pode ser operada manualmente enquanto a aplicação valida procura, qualidade e repetição.
Confirme que um utilizador novo recupera os seus registos, que outro papel não os consegue ver e que um erro não destrói o estado existente. O objetivo do MVP é obter evidência sobre uma hipótese de produto. A rapidez com que o primeiro ecrã aparece não deve ser confundida com validação do problema, segurança ou capacidade de operação.
Inventário, aprovações, onboarding, incidentes e painéis de serviço são processos delimitados que podem ser modelados com entidades, papéis e workflows. O Base44 pode ser útil quando um produto genérico obriga a combinar folhas de cálculo, mensagens e atalhos. Comece pelo sistema que é fonte de verdade e pelo momento exato em que cada caso muda de responsável ou estado.
Uma ferramenta interna não é automaticamente de baixo risco. Dados de trabalhadores, clientes ou finanças precisam de regras, retenção e rastreabilidade. Defina quem corrige conflitos, como se exporta informação e o que acontece se uma integração estiver indisponível. Teste o processo com pessoas que não participaram na construção.
Autenticação e regras de dados podem sustentar pedidos, documentos, entregas e solicitações. Cada registo privado deve estar relacionado com o proprietário ou tenant correto. Crie duas organizações de teste e tente atravessar a fronteira em pesquisas, URLs, formulários e atualizações; a personalização da interface não protege uma consulta mal autorizada.
Planeie revogação de acesso, histórico de alterações e propriedade das integrações. As mensagens de erro devem ajudar o utilizador sem revelar nomes, identificadores ou configurações de terceiros. Se o portal tratar documentos sensíveis, confirme termos, localização de armazenamento e subprocessadores em vez de extrapolar a partir do simples facto de existir login.
Um novo lead pode desencadear confirmação, espera, verificação e alerta; um evento de calendário pode atualizar uma reserva; uma tarefa programada pode preparar um resumo. Modele tentativas repetidas, eventos duplicados, autorização expirada e estado terminal observável. O operador precisa de saber se a execução terminou, falhou ou ficou à espera.
Filtre eventos irrelevantes antes de consumir créditos ou chamar terceiros. Operações financeiras e outras ações irreversíveis exigem aprovação ou reconciliação. Teste um serviço lento, uma resposta incompleta e a chegada do mesmo evento duas vezes. Um percurso feliz numa demonstração não prova fiabilidade.
O Base44 pode criar sites, landing pages e calculadoras com domínio e alojamento. É mais interessante quando a experiência exige contas, preferências guardadas, resultados gerados ou um processo após o formulário. Para um site sobretudo editorial, compare também um CMS em SEO, redirecionamentos, edição, versionamento e governação do conteúdo.
Experimente textos longos, estados vazios, erros, teclado, contraste e ecrãs estreitos. Uma capa elegante não prova que uma tabela complexa seja utilizável nem que o formulário mantenha o estado depois de uma falha. Estabeleça métricas de conclusão e suporte antes de considerar a experiência pronta.
Escreva os papéis, os registos principais, as ações permitidas, o resultado observável e as exclusões. Num cenário multi-tenant, explique como a organização é armazenada e como cada consulta fica limitada. Use Discuss para pedir uma crítica ao esquema, casos-limite e riscos sem aplicar alterações ao projeto.
Evite começar por uma lista de ecrãs. Uma descrição como «o gestor aprova um pedido da sua organização e a decisão fica registada» contém papel, ação, âmbito e auditoria. A mesma precisão ajuda a IA a construir regras e permite à equipa escrever testes objetivos.
Peça o registo, a criação de um objeto, a sua leitura pelo papel correto e uma ação relevante. Reveja os campos, validações, recarregamento da página e início de uma nova sessão. Se o modelo estiver errado, corrija-o antes de acrescentar dashboards, integrações ou dezenas de páginas que dependam desse erro.
Use dados representativos desde cedo: nomes extensos, valores vazios, caracteres especiais e relações duplicadas. A fatia deve demonstrar que o estado persiste, que a autorização funciona e que uma pessoa consegue completar a tarefa sem conhecer o prompt que originou a aplicação.
Teste criar, ler, atualizar e eliminar para cada papel, incluindo operações proibidas. Mova credenciais para o mecanismo de segredos e operações sensíveis para o backend. Execute o scanner, leia cada recomendação e tente aceder a registos de outro utilizador com contas fictícias. A ausência de um botão não é um controlo suficiente.
Considere também os caminhos indiretos: pesquisa, exportação, ficheiros, endpoints chamados pela interface e workflows iniciados por eventos. Registe os testes negativos, porque são mais fáceis de perder quando a aplicação cresce. Para dados de maior risco, acrescente revisão independente.
Para cada integração, confirme a conta, os scopes e o proprietário. Teste sucesso, recusa, várias páginas de resultados, limite, expiração e repetição. Num workflow, defina primeiro trigger, condições, esperas e final; só depois ligue ações externas. Alterações pequenas são mais fáceis de explicar, medir e desfazer.
Se uma operação puder ser repetida, associe-lhe uma chave idempotente ou uma reconciliação. Guarde apenas a informação necessária para diagnosticar, sem expor segredos. Uma integração deve ter um modo explícito de ser desligada quando o fornecedor ou as credenciais falham.
Use limites de texto, anexos e coleções próximos da realidade. Abra a aplicação com cada papel num navegador limpo, no telefone e em ligações menos estáveis. Verifique estados de carregamento, mensagens de erro, teclado e orientação. O wrapper de loja apresenta a aplicação web publicada, por isso o fluxo web deve estar sólido primeiro.
Meça também o custo do cenário real. Uma execução pode combinar mensagem de IA, ação de integração e várias tentativas. Um exemplo pequeno não revela o comportamento com dados volumosos ou atividade simultânea. Faça um piloto controlado antes de migrar um processo crítico.
Antes da release, exporte dados e código importantes, registe a versão revista, o plano e as ligações, repita o scanner e confirme o domínio. Depois de publicar, entre com uma conta nova e execute o percurso principal. Observe funções, workflows, integrações e créditos em vez de assumir que a pré-visualização e a produção são equivalentes.
Defina responsável, janela de observação e critério para recuar. Se uma integração falhar, deve ser possível interrompê-la sem perder o estado confirmado. Documente o incidente e a correção fora do chat, para que o conhecimento não dependa da memória de uma única sessão.
«Adiciona uma página de aprovação» deixa por decidir quem aprova, quais registos vê e o que acontece depois. Indique papel, tenant, estado inicial, ação, estado final e campos de auditoria. Separe pedidos funcionais de pedidos visuais, para que uma mudança de estilo não esconda uma alteração de lógica ou permissão.
Não misture autenticação, esquema, pagamentos e redesign no mesmo pedido. Aplique uma mudança, reveja o diff ou comportamento e execute os testes relevantes. Mantenha um registo externo do requisito, prompt, entidades, decisões e release. O histórico do chat dá contexto, mas não substitui documentação estável.
Mensagens de IA e ações de integração usam saldos separados. O modelo, a complexidade, as execuções programadas e as chamadas externas influenciam o consumo. Planeie em Discuss, filtre triggers ruidosos e meça o workflow real durante o período de avaliação. Não fixe no desenho números de uma tabela que pode mudar.
Documente entidades, exportações, funções, segredos, domínios e pressupostos de autenticação. Teste exportação e reconstrução de uma amostra. Desligue deliberadamente uma integração, duplique um evento e force um erro. O utilizador precisa de uma mensagem compreensível e o operador de um caminho para recuperar ou reconciliar o estado.
Para cada função, escreva exemplos positivos, negativos e limites observáveis. Isto permite comparar gerações e detetar regressões sem depender da impressão visual. Inclua privacidade entre tenants, comportamento após recarregar, falha externa e permissões. Quando o produto mudar, atualize os critérios antes de pedir nova geração.
O Base44 pode ajustar-se a fundadores que conseguem definir regras mas não querem montar infraestrutura para testar uma hipótese; a product managers e designers que precisam de protótipos funcionais; e a equipas de operações que querem modelar um processo específico. O melhor encaixe surge quando a equipa aceita um runtime gerido e está disposta a validar segurança e operação.
Programadores podem combinar editor, código, GitHub, CLI, SDK e backend. Agências podem entregar portais e ferramentas quando propriedade, conta, créditos, manutenção e transferência ficam definidos desde o início. Git e exportação facilitam colaboração, mas não transformam automaticamente os serviços geridos numa stack autoalojada equivalente.
É menos indicada quando são obrigatórios self-hosting, controlo profundo da infraestrutura, funcionamento offline completo, comportamento fortemente nativo ou requisitos regulatórios que dependam de controlos auditados de forma independente. Nestes casos, construa uma prova pequena e compare-a com desenvolvimento convencional ou plataformas de maior controlo antes de assumir compromisso.
O editor, a pré-visualização e as aplicações publicadas centram-se na web. O acesso por navegador móvel e as aplicações de criação para iOS e Android estão documentados, embora algumas tarefas administrativas possam exigir desktop. Teste a experiência publicada em dispositivos reais; um layout responsivo no preview não cobre teclado, permissões do browser ou ligações instáveis.
Uma interface criada fora do Base44 pode utilizar o backend gerido através do SDK JavaScript e da CLI documentados. Esta opção ajuda quando a equipa precisa de controlar a camada visual, mas continua a depender de entidades, autenticação e serviços da plataforma. Avalie autorização, tratamento de erros, versionamento e plano de migração como parte da integração.
Domínios personalizados, ZIP e sincronização GitHub dependem do plano aplicável. Os pacotes para lojas são wrappers da aplicação web e exigem contas Apple e Google próprias. Confirme cada direito importante na tabela e na conta atuais, especialmente antes de prometer domínio, branch, pacote móvel ou processo de publicação a um cliente.
A documentação consultada apresenta os planos Free, Starter, Builder, Pro e Elite e uma tabela de comparação. Como os direitos podem mudar sem alteração do nome, este guia não associa permanentemente uma função a um nível. Consulte a tabela oficial e o workspace para limites, créditos, domínio, GitHub, mobile e suporte antes de escolher.
As mensagens de IA e as ações de integração têm atribuições distintas. Modelo e complexidade influenciam as mensagens; integrações e workflows consomem o outro saldo conforme o uso. Inclua geração, correções, tarefas programadas e manutenção no piloto. Confirme preço e capacidade no momento da compra, em vez de extrapolar um exemplo antigo.
O custo operacional inclui iteração, integração, observação, revisão de segurança, eventual trabalho local e contas externas. Meça um fluxo representativo durante tempo suficiente para incluir falhas e repetição. Se o negócio depender de um limite, registe a fonte e a data; uma estimativa sem carga real não é base suficiente para produção.
Lovable e Bolt são alternativas orientadas à criação web por prompts. Replit combina agente, ambiente de desenvolvimento e deployment. A comparação deve usar o mesmo fluxo vertical, os mesmos papéis e a mesma integração, não apenas a qualidade visual da primeira geração. Observe como cada solução explica mudanças, erros e propriedade do código.
Softr orienta-se a aplicações empresariais estruturadas, enquanto Retool e Power Apps dão ênfase a conectores e governação interna. Podem ser mais adequados quando o objetivo é uma ferramenta operacional com fontes existentes. Compare permissões, auditoria, implantação, custo por utilizador e experiência fora do percurso ideal.
Uma stack construída à medida oferece maior controlo sobre infraestrutura, dados, autenticação e comportamento nativo, em troca de mais engenharia e operação. A decisão não deve ser «IA ou código», mas qual sistema satisfaz requisitos verificáveis com risco e custo aceitáveis. Inclua exportação, migração, suporte e resposta a incidentes na prova.
Product Hunt e G2 continham experiências favoráveis e críticas, mas as amostras são autoselecionadas. A G2 mostrava quatro avaliações e a Capterra três, números insuficientes para generalizar fiabilidade ou qualidade. Transforme as observações em perguntas para um piloto próprio e não em percentagens ou promessas universais.
O scanner ajuda a encontrar classes de problemas, mas o proprietário decide, corrige e valida. A documentação de privacidade descreve armazenamento nos Estados Unidos por defeito e opções variáveis para UE/Reino Unido; não autoriza inventar certificações, encriptação específica ou adequação regulatória. Compare dados, retenção, acessos e subprocessadores com os termos vigentes.
Exportar código e dados é útil, mas não recria autenticação, base de dados e alojamento como componentes independentes. Faça inventário de funções, entidades, segredos, ficheiros, domínios e integrações. Uma prova de migração deve reconstruir uma pequena funcionalidade e confirmar que utilizadores e dados continuam coerentes, não apenas abrir o código num editor.
Os pacotes IPA e AAB são wrappers web-view. Não acrescentam push nativo nem modo offline completo segundo a documentação consultada. Se notificações, background processing, sensores ou operação sem rede forem requisitos centrais, valide-os explicitamente e compare uma implementação nativa ou híbrida com capacidades diferentes.
Uma aplicação com poucos registos não prova comportamento com maior volume, vários utilizadores ou workflows concorrentes. Reproduza carga representativa, meça tempos e créditos e force timeout, duplicação e autorização expirada. Confirme o canal de suporte do plano atual e defina como a equipa continua a operar se a plataforma ou uma integração ficar indisponível.
Uma região de armazenamento não implica que todo o processamento ocorra nesse local. Catalogue os tipos de dados, o tempo de retenção, os papéis com acesso e os subprocessadores relevantes. Para informação sensível ou regulada, obtenha validação jurídica e técnica baseada nos documentos atuais, não numa inferência a partir da localização da base.
Sim. A documentação cobre interface, dados persistentes, autenticação, funções, integrações, workflows e alojamento. Isso cria uma aplicação funcional, mas produção continua a exigir desenho de permissões, testes, observabilidade e operação.
Não para iniciar um protótipo, porque a conversa pode gerar páginas, dados e lógica. Conhecimentos técnicos ajudam a modelar autorização, rever código, integrar serviços e diagnosticar falhas. Quanto maior o risco, maior deve ser a revisão especializada.
A documentação consultada lista Free entre os cinco planos. Direitos, limites e créditos podem mudar; confirme a tabela oficial e o que aparece na conta antes de assumir que uma função ou volume específico está incluído.
Mensagens estão ligadas ao trabalho da IA no editor; créditos de integração cobrem ações externas e workflows. São saldos distintos. Meça ambos com um cenário real e inclua tarefas recorrentes e tentativas repetidas.
Existem vista de código, ZIP e sincronização GitHub em planos elegíveis, além de exportação de dados. A exportação não transforma autenticação, base de dados e alojamento geridos numa solução autoalojada pronta; uma migração tem de substituir essas camadas.
O Base44 pode gerar pacotes num plano elegível. O proprietário fornece as contas de programador e trata das fichas, declarações e revisão. Os pacotes são wrappers web-view e não acrescentam push nativo nem offline completo.
Configure visibilidade e permissões, guarde credenciais em segredos, execute o scanner e teste cada papel com contas separadas. Tente acessos proibidos e reveja funções e integrações. Dados de maior risco justificam avaliação independente.
Sim, em planos elegíveis segundo a documentação. Os domínios recebem HTTPS gerido e o GitHub oferece sincronização bidirecional. Confirme o entitlement no plano e defina propriedade da conta e do repositório.
Não. Aplicações criadas a partir de 6 de julho de 2026 usam Workflows; projetos anteriores podem manter Automations. Uma aplicação mostra apenas o sistema que lhe corresponde, pelo que tutoriais de outra geração podem não se aplicar.
Pode ser, se a equipa aceitar o runtime gerido e validar permissões, fiabilidade, custo, portabilidade e suporte com carga real. Quando self-hosting, controlo profundo ou requisitos regulatórios são obrigatórios, compare uma arquitetura mais controlável.
