monday dev é o produto da monday.com feito para times de produto e engenharia de software: um conjunto de quadros conectados para planejar roadmap, quebrar épicos em tarefas, rodar sprints com story points e burndown, rastrear bugs e sincronizar tudo isso com o repositório de código pelo GitHub, GitLab ou CircleCI. Ele roda sobre a mesma plataforma dos outros produtos da monday.com, mas é vendido à parte, com planos, assentos e recursos próprios.
Neste artigo eu explico o que o monday dev é e o que ele não é, como o mecanismo de sprint funciona por dentro, o que cada plano libera, quanto custa nos valores em reais que a própria monday.com publica e em que situações eu não recomendo a compra. Uma ressalva que muda a decisão de muita gente vem já na introdução: o plano de entrada, o Básico Dev, não inclui gestão de sprints nem integração com GitHub. Quem quer um monday dev de verdade começa no Padrão. A Audatia é parceira da monday.com e os links de teste deste texto são de parceiro. A licença é contratada direto do fabricante, sem revenda nacional; o que eu entrego é consultoria, treinamento e sustentação. Por isso mesmo, este texto credita as alternativas onde elas são melhores.
O que é o monday dev
A monday.com vende quatro produtos separados, todos construídos sobre a mesma base: a plataforma de trabalho com IA (gestão de tarefas e projetos em geral), o monday CRM, o monday service e o monday dev. Cada produto tem plano, preço e número de assentos próprios. Uma empresa pode comprar só um deles ou combinar vários na mesma conta, e cada produto pode estar em um plano diferente, com uma condição: todos precisam compartilhar o mesmo ciclo de cobrança, mensal ou anual. No Enterprise, todos os produtos combinados precisam estar no plano Enterprise, com contrato mínimo de doze meses.
Na prática, o monday dev é um pacote de quadros interligados que a monday.com chama de fluxo de trabalho: um quadro de roadmap com épicos organizados por trimestre, um quadro de tarefas onde os grupos são as sprints, uma fila de bugs, um quadro de retrospectivas e um conjunto de visualizações e widgets que só existem nesse produto, como o Kanban com limite de trabalho em andamento, o painel de desempenho de engenharia e os gráficos de Agile Insights. Boa parte das colunas desses quadros é o que a monday.com chama de coluna central: ela não pode ser apagada, porque os quadros dependem uns dos outros para funcionar.
O que o monday dev não é: não é um plugin nem um modelo instalado por cima da conta de gestão de trabalho que você já tem. É outro produto, com outra fatura. E não é um substituto direto do Jira em profundidade de configuração; volto a isso na seção sobre onde ele não vale.
Como funciona o monday dev
O mecanismo tem três movimentos encadeados. Quem entende os três entende por que as colunas centrais não podem ser apagadas.
1. O roadmap quebra a visão em épicos. No quadro de roadmap, cada item é um épico ou uma funcionalidade grande, posicionado por trimestre. O cartão do épico guarda a descrição completa, o que permite que produto e design escrevam ali o detalhe da funcionalidade. Esse quadro é o que a diretoria e as áreas de negócio olham, porque mostra o plano sem o ruído das tarefas. O épico se conecta às tarefas por uma coluna de conexão de quadros, e a visão de detalhamento do épico reúne, em uma tela, todas as tarefas ligadas a ele.
2. O quadro de tarefas organiza as sprints. É o coração do produto. Os grupos do quadro são as sprints, mais um grupo de backlog com as tarefas ainda não alocadas. Cada tarefa tem colunas de responsável, status, prioridade, tipo, story points estimados e story points realizados, sprint, épico e fila de bugs. Para começar uma sprint, você cria um grupo novo com nome, datas de início e fim e metas, e arrasta tarefas do backlog para dentro. A sprint pode ser iniciada e encerrada à mão ou de forma automática, em horários definidos, e no encerramento você escolhe o que fazer com o que sobrou: manter na sprint encerrada, mover para a próxima ou devolver ao backlog. Com o modo automático, a monday.com gera um resumo da sprint ao final. Com o modo manual, a documentação é clara: você perde o resumo automático, o burndown e os Agile Insights.
3. O repositório devolve o status para o quadro. A integração com o GitHub é instalada uma vez, no nível da conta, e exige que quem instala seja administrador da conta monday.com e administrador da organização no GitHub. Depois disso, qualquer pessoa do time usa modelos prontos de automação: quando um pull request é criado e menciona o identificador do item, mude o status; quando o pull request é mesclado, mude o status de novo; quando uma issue recebe um rótulo, crie um item; quando alguém sobe um comentário TODO, crie uma tarefa. A ligação entre os dois mundos é o identificador do item, que o desenvolvedor coloca no nome da branch ou do pull request. Há também sincronização de duas vias, que mantém campos como responsável e status iguais nos dois lados, e um widget de Git que mostra branches, commits, pull requests e status de CI dentro do cartão da tarefa.
Repare no padrão: o dado nasce uma vez e viaja. O épico vira tarefa, a tarefa vira branch, a branch vira pull request e o pull request devolve o status para o quadro, que alimenta o burndown, que alimenta o roadmap. Quando alguém apaga uma coluna central ou pula o identificador do item no nome da branch, a corrente quebra em silêncio, e o quadro passa a mentir com aparência de organizado. Metade do trabalho de implantação é garantir que a corrente não quebre.
Para ver a corrente inteira funcionando, o teste gratuito é de catorze dias e roda no plano Profissional, com todos os recursos liberados. Dá para começar o teste do monday dev pelo link de parceiro, instalar o aplicativo no GitHub em um repositório de teste e acompanhar uma sprint curta antes de decidir o plano.
O que cada plano libera
A monday.com publica a diferença entre os planos na central de ajuda. O que importa para um time de desenvolvimento está resumido abaixo.
| Plano | O que entra (acumulativo) | Ações de automação e de integração por mês |
|---|---|---|
| Básico Dev | Visualizadores gratuitos ilimitados, itens ilimitados, modelos de desenvolvimento, workdocs, aplicativos móveis, Kanban, painel com 1 quadro, 5 GB de armazenamento, teste único de 6.000 créditos de IA | A documentação do plano não lista cota de automações nem de integrações |
| Padrão Dev | Gestão de sprints, integração com GitHub, painel de desempenho de engenharia, roadmap tracker, detalhamento de épicos, automações de sprint, integração com CircleCI, visualizações de linha do tempo e Gantt, painel com 5 quadros | 250 de automação e 250 de integração |
| Profissional Dev | Agile Insights (velocidade, planejado × não planejado, burndown), relatórios ágeis, roadmap entre times, gestão de feedback e pedidos de clientes, quadros privados, controle de tempo, painel com 20 quadros | 25.000 de automação e 25.000 de integração |
| Corporativo Dev | Condições para mudança de rótulo (campos obrigatórios antes de trocar o status), construtor de fluxos entre quadros, painel com 50 quadros, SSO, SCIM, log de auditoria, restrição por IP, programa HIPAA, permissões em vários níveis, onboarding dedicado, teste único de 12.000 créditos de IA | 250.000 de automação e 250.000 de integração |
A leitura prática da tabela: o Básico Dev não é um produto para desenvolver software, é um quadro de tarefas com modelos de desenvolvimento. Sprint, GitHub e roadmap entram no Padrão. E o Padrão tem um teto que ninguém olha na hora da compra: 250 ações de integração por mês são pouco mais de 8 por dia para a conta inteira. Cada pull request que muda um status é uma ação, cada branch criada que atualiza um item é outra, cada commit que vira atualização é mais uma. Um time de cinco pessoas abrindo três pull requests por dia consome a cota do Padrão na segunda semana do mês, e as automações simplesmente param de disparar até o ciclo virar. Para quem quer a integração com o repositório funcionando de verdade, o plano de trabalho é o Profissional. É a diferença entre um preço de entrada e um preço de uso.
Quanto custa o monday dev
Os valores abaixo são os que a monday.com publica na página de preços do monday dev em português, por usuário por mês, no plano anual, para uma equipe de três usuários. A própria página avisa que os preços não incluem impostos e que o valor é definido pelo país de faturamento, com o total final exibido na tela de compra.
| Plano | Por usuário/mês (anual) | Total mensal para 3 usuários |
|---|---|---|
| Básico Dev | R$ 50 | R$ 150 |
| Padrão Dev | R$ 66 | R$ 198 |
| Profissional Dev | R$ 110 | R$ 330 |
| Corporativo Dev | Sob cotação com a monday.com | Sob cotação |
Três regras de cobrança pesam mais do que o preço unitário. A primeira: o plano anual tem 18% de desconto sobre o mensal, e é pago à vista, adiantado. A segunda: a monday.com vende por faixa de assentos, não por assento. O mínimo é 3, e a partir daí as faixas sobem de 5 em 5: um time de 4 paga 5 assentos, um time de 6 paga 10. Acima de 40 usuários, o preço sai por cotação com a equipe de vendas. A terceira: não existe plano gratuito no monday dev. O plano Free só existe na plataforma de trabalho com IA; no dev, o que existe é o teste de catorze dias no Profissional, sem cartão de crédito, e depois a escolha de um plano pago.
A leitura prática: para um time de 7 desenvolvedores que quer GitHub e burndown funcionando, a conta real é 10 assentos no Profissional, e não 7 no Padrão. Vale fazer essa conta antes de aprovar o orçamento, porque o número que aparece no cartão de preço raramente é o número da fatura. Visualizadores, que só leem, não contam como assento, o que é uma boa saída para diretoria e stakeholders que só acompanham o roadmap.
Integrações e migração: o que a monday.com documenta
Além do GitHub, a central de ajuda documenta integrações com GitLab, Jira Cloud, Jira Server e Data Center, CircleCI, GitHub Actions, PagerDuty, Zendesk, Slack e Microsoft Teams. Para quem vem do Jira, existe um guia de migração que usa a própria integração como veículo: primeiro você monta a estrutura do monday dev, define requisitos de dados uniformes para todos os tipos de issue e cria uma pasta de time Scrum como modelo; depois configura a integração com um rótulo de gatilho, como “migração”, e vai projeto a projeto, editando em lote cerca de cem itens por vez para disparar a sincronização. Esse caminho está disponível a partir do Padrão. A ordem do guia é a mesma que eu defendo em qualquer implantação: estrutura e regra de dados antes de qualquer dado entrar.
Há ainda um ponto que conecta o monday dev ao assunto de agentes de IA: o servidor MCP da monday.com expõe ferramentas específicas do dev, que permitem a um assistente descobrir os quadros de sprint, ler os metadados e gerar o resumo da sprint em linguagem natural. Não é um recurso do produto em si, mas é um motivo a mais para manter as colunas centrais intactas: é delas que o resumo é calculado.
Onde o monday dev não vale a pena
Esta é a parte do artigo que mais economiza dinheiro, e eu prefiro ser específico.
- Quando o time vive dentro do ecossistema Atlassian. Quem depende de esquemas de permissão por projeto, de linguagem de consulta avançada, do marketplace de plugins do Jira e da ligação nativa com Confluence e Bitbucket vai sentir falta de profundidade. O Jira ganha em configurabilidade de fluxo por tipo de issue; o monday dev ganha em quem mais usa o quadro além dos desenvolvedores. Se a segunda vantagem não importa para você, a primeira decide.
- Quando o orçamento é o do Básico. Sem sprint, sem GitHub e sem cota de automação documentada, o Básico Dev entrega menos do que um quadro de tarefas bem montado na plataforma de trabalho com IA, que ainda tem plano gratuito. Se o dinheiro só dá para o Básico, não compre o dev.
- Quando o time é pequeno e o ritmo de pull requests é alto no Padrão. As 250 ações de integração por mês acabam rápido. Ou se assume o Profissional desde o início, ou se aceita que a integração com o repositório vai falhar na metade do mês.
- Quando a empresa quer o mesmo produto para todo mundo. O monday dev é um produto à parte, com fatura própria. Se o marketing, o financeiro e a engenharia precisam trabalhar nos mesmos quadros, o desenho correto é combinar produtos na mesma
