Quanto Tempo Demora a Construir uma App? [Prazos Reais por Tipo de Projeto]

Há uma pergunta que ouvimos em quase todas as primeiras conversas com um novo cliente: "Quanto tempo vai demorar isto?" É uma pergunta razoável. Os orçamentos dependem dela. As decisões do conselho de administração giram em torno dela. As datas de lançamento são anunciadas com base na resposta.

A resposta honesta — e a que frustra as pessoas — é que o prazo depende do que está a construir, do grau de clareza com que está definido, da rapidez com que as decisões são tomadas, e se o âmbito se mantém estável tempo suficiente para terminarmos. Dizer "seis meses" a um cliente pode ser preciso. Dizer o mesmo ao cliente seguinte com um briefing vago e um objetivo em constante mudança é preparar o caminho para um desastre.

Escrevemos este guia porque acreditamos que merece números reais, não respostas vagas e imprecisas. Vamos dar-lhe intervalos de tempo reais por tipo de projeto, percorrer as fases do desenvolvimento e quanto cada uma genuinamente demora, explicar o que especificamente faz os prazos derraparem (e o que os comprime), e dizer-lhe honestamente o que acontece quando um prazo fixo encontra um briefing mal definido. No final, deverá ter uma ideia muito mais clara do que o seu projeto provavelmente vai demorar — e o que pode fazer para tornar esse número o mais pequeno possível.

---

Prazo de Desenvolvimento por Tipo de Projeto

Cada projeto é diferente, mas a maioria enquadra-se em categorias reconhecíveis. A tabela abaixo reflete os prazos que observamos na prática — não casos otimistas ou catastrofistas, mas o intervalo realista quando um projeto está razoavelmente bem definido e é gerido por uma equipa experiente. Cada intervalo pressupõe uma equipa de entrega completa (gestor de produto, designer, pelo menos dois programadores, um engenheiro de QA) a trabalhar em sprints focados.

Tipo de Projeto	Prazo Típico	O Que Está Incluído	Principais Pressupostos
Aplicação web simples / ferramenta interna	6 – 12 semanas	Interfaces CRUD, autenticação de utilizadores, dashboard básico, até 2–3 integrações	Requisitos bem definidos, sem lógica de negócio complexa, sem aplicação móvel
MVP de SaaS	12 – 20 semanas	Arquitetura multi-tenant, subscrição/faturação, conjunto de funcionalidades principais, painel de administração, fluxo de onboarding	Conjunto de funcionalidades acordado antecipadamente, uma plataforma (web), sem integração com sistemas legados
MVP de aplicação móvel	16 – 24 semanas	iOS ou Android (ou ambos), ecrãs principais, notificações push, API backend, submissão para a loja de aplicações	Nativo ou multiplataforma, sem sincronização em tempo real, backend construído de raiz ou bem documentado
Plataforma marketplace	20 – 32 semanas	Fluxos de comprador e vendedor, pagamentos e desembolsos, listagens, avaliações, ferramentas de moderação	Modelo de utilizador duplo, integração de pagamentos, sem complexidade regulatória
Plataforma empresarial	6 – 18 meses	Fluxos de trabalho personalizados, integração ERP/CRM, controlo de acesso baseado em funções, requisitos de conformidade, relatórios	Grande grupo de partes interessadas, entrega faseada, sistemas existentes a integrar

Há alguns aspetos que vale a pena analisar com mais detalhe. Os intervalos são mais largos para projetos mais complexos não porque estejamos a ser evasivos, mas porque a complexidade e os fatores organizacionais criam genuinamente uma grande variância. Um marketplace construído para um cliente que já fez isto antes, que chega com um briefing detalhado e que consegue tomar decisões de design em 24 horas chegará ao lançamento mais rapidamente do que um construído para um fundador que está ainda a descobrir o produto enquanto a equipa o constrói. Ambas são situações legítimas. Apenas produzem prazos diferentes.

A linha empresarial é deliberadamente ampla — 6 a 18 meses — porque os projetos empresariais são onde o âmbito, a complexidade de integração e a velocidade de tomada de decisões institucionais variam mais dramaticamente. Já entregámos ferramentas empresariais em cinco meses. Também já vimos equipas bem financiadas demorar dois anos em plataformas de complexidade técnica comparável porque a aquisição, a aprovação de conformidade e o alinhamento das partes interessadas foram acrescentando mês após mês ao calendário.

---

As 5 Fases do Desenvolvimento de Software e Quanto Cada Uma Demora

É útil perceber o que realmente acontece dentro desse prazo — porque "desenvolvimento" não é uma coisa só. É uma sequência de fases, cada uma com os seus próprios outputs, dependências e modos de falha.

Fase 1: Discovery — 2 a 4 Semanas

O discovery é a fase que a maioria dos clientes quer saltar e que a maioria das agências executa mal. Feito corretamente, é o investimento de maior impacto em todo o projeto.

Durante o discovery estamos a tentar responder a três perguntas: Que problema estamos realmente a resolver? Como é o sucesso em termos mensuráveis? E quais são os riscos que precisamos de planear? Realizamos workshops estruturados com as partes interessadas, mapeamos os fluxos de trabalho existentes, auditamos os sistemas que precisam de integrar, e produzimos um documento de requisitos de produto que se torna a verdade de base para tudo o que se segue.

Duas semanas é realista para uma ferramenta interna ou MVP bem definido. Quatro semanas é adequado para qualquer coisa com múltiplos grupos de partes interessadas, integrações legadas ou requisitos regulatórios. O discovery não pode ser comprimido com segurança além disto — o que se perde é a precisão que torna tudo o que vem a seguir mais rápido.

Fase 2: Design — 2 a 4 Semanas

O design corre em grande medida em sequência com o discovery, embora na prática os dois se sobreponham. Produzimos arquitetura de informação, wireframes e designs de UI de alta fidelidade que a equipa de desenvolvimento constrói com exatidão — não "interpreta livremente."

A velocidade desta fase depende quase inteiramente da rapidez com que as decisões de design são aprovadas. Um único stakeholder do cliente que pode dizer sim ou não a um design num dia significa que duas semanas de trabalho de design permanecem em duas semanas. Um comité de cinco pessoas com opiniões divergentes sobre as cores dos botões significa que duas semanas de trabalho de design se tornam cinco.

Usamos design baseado em componentes no Figma, o que significa que o sistema de design criado aqui continua a gerar dividendos ao longo do desenvolvimento e torna o trabalho de funcionalidades futuras significativamente mais barato.

Fase 3: Desenvolvimento — 4 a 24 Semanas (Varia por Tipo de Projeto)

Esta é a fase mais longa e mais variável. Os programadores estão a construir o produto real, o que significa APIs de backend, arquitetura de base de dados, interfaces de frontend, integrações com serviços de terceiros, e a infraestrutura em que tudo corre.

Trabalhamos em sprints de duas semanas, entregando software funcional e testável no final de cada sprint em vez de um grande lançamento único no final. Isto é importante porque significa que vê progressos reais, não apenas atualizações de estado. Significa também que as mudanças de âmbito — e quase sempre existem algumas — podem ser geridas de forma deliberada em vez de absorvidas de forma invisível até se tornarem uma crise.

O tempo de desenvolvimento é onde vivem principalmente os intervalos por tipo de projeto da nossa primeira tabela. Uma ferramenta interna simples pode precisar de quatro semanas de desenvolvimento ativo. Uma plataforma marketplace pode precisar de dezoito.

Fase 4: Testes — Corre em Paralelo com o Desenvolvimento

Os testes não são uma fase que acontece depois de o desenvolvimento terminar. São uma atividade contínua que corre em paralelo ao longo da construção. Os nossos engenheiros de QA escrevem casos de teste a partir do documento de requisitos, executam-nos contra o output de cada sprint, e devolvem os bugs ao ciclo de desenvolvimento antes que se acumulem.

Os testes end-to-end dedicados antes do lançamento demoram tipicamente uma a duas semanas adicionais relativamente aos testes sprint a sprint. Isto não é negociável. O custo de um bug em produção — em termos de confiança dos utilizadores, de tempo de programação de emergência, em reputação — é de uma ordem de grandeza superior ao custo de o detetar em testes.

Fase 5: Implementação e Lançamento — 1 a 2 Semanas

Implementar uma aplicação web moderna não é apenas premir um botão. Envolve configurar infraestrutura de produção, configurar monitorização e alertas, realizar verificações de segurança finais, inserir dados de produção quando necessário, e executar uma sequência de lançamento que torna a transição do staging para o ambiente em direto o mais invisível possível para os utilizadores.

Para aplicações móveis, acrescente o tempo de revisão da loja de aplicações. A revisão da App Store da Apple demora atualmente dois a sete dias para submissões padrão, embora possa demorar mais para aplicações em certas categorias. O Google Play tipicamente revê em um a três dias, embora novas contas de programador possam demorar mais.

---

O Que Faz os Projetos Demorar Mais do Que o Esperado

Todo o projeto que ultrapassa o prazo fá-lo por uma razão. Na nossa experiência, as causas agrupam-se em cinco categorias — e são maioritariamente previsíveis com antecedência se souber o que procurar.

Requisitos Vagos ou Incompletos

A causa mais comum de ultrapassar o prazo é começar a construir antes de alguém ter definido claramente o que está a construir. Quando os requisitos são vagos, os programadores fazem suposições. Essas suposições são revistas em testes ou sessões de demonstração e revelam-se erradas. O trabalho é refeito. Este ciclo repete-se em cada funcionalidade mal definida até consumir semanas.

A solução é um discovery adequado. Parece um overhead no início. Compensa muitas vezes.

Tomada de Decisão Lenta do Lado do Cliente

As equipas de desenvolvimento têm um ritmo. Quando esse ritmo atinge uma decisão que não pode ser tomada sem contributo do cliente — uma aprovação de design, uma revisão de texto, uma questão de política sobre como os utilizadores são segmentados — e essa decisão demora cinco dias a chegar em vez de um, o sprint inteiro ajusta-se. Multiplique isso por dez decisões ao longo de um projeto e acrescentou duas a quatro semanas ao prazo sem uma única linha de código estar errada.

Isto não é uma crítica aos clientes. Fundadores e líderes operacionais ocupados têm outros trabalhos. Mas é uma contabilidade honesta de onde o tempo vai.

Complexidade de Integração

Integrar com sistemas de terceiros é quase sempre mais difícil do que parece do exterior. APIs mal documentadas, que se comportam de forma diferente em ambientes sandbox versus produção, que impõem limites de taxa de forma inesperada, ou que devolvem formas de dados inconsistentes, acrescentam tempo de desenvolvimento. Sistemas legados — ERPs, CRMs antigos, bases de dados à medida — muitas vezes não têm API formal alguma, exigindo middleware personalizado ou camadas de transformação.

Avaliamos o risco de integração no discovery. Mas parte dele só surge quando um programador se liga realmente ao sistema e começa a enviar pedidos reais.

Mudanças de Âmbito a Meio da Construção

"Podemos só adicionar..." é a frase mais cara no desenvolvimento de software. Não porque as alterações individuais sejam sempre grandes, mas porque se acumulam. Uma funcionalidade adicionada na semana seis pode exigir repensar o modelo de dados que foi finalizado na semana dois. Um novo tipo de utilizador adicionado na semana dez pode quebrar pressupostos integrados em todos os ecrãs da aplicação.

As mudanças de âmbito não são inerentemente más — os requisitos evoluem, os mercados mudam, aprende-se coisas. Mas precisam de ser geridas através de um processo formal de controlo de alterações que tenha em conta o seu impacto real no prazo e no custo. Quando são absorvidas informalmente, o prazo estira-se de forma invisível e depois de repente.

Restrições Técnicas Não Descobertas

Algumas restrições só aparecem depois de a construção começar: um browser móvel que processa uma interação de UI de forma diferente do que foi testado, uma query de base de dados que funciona bem com dados de teste mas degrada com carga de produção, um requisito de segurança que a API do parceiro de integração não consegue satisfazer sem uma solução alternativa personalizada. Estas não são falhas de planeamento — são a incerteza inerente de construir software complexo. As boas equipas detetam-nas cedo através de spikes e protótipos. As equipas menos experientes descobrem-nas na semana catorze.

---

O Que Realmente Acelera um Projeto

Os fatores que aceleram um projeto são o espelho dos que o atrasam — mas vale a pena enunciá-los explicitamente porque são acionáveis.

• Requisitos claros e escritos antes de o desenvolvimento começar. Não uma apresentação de slides. Um documento de requisitos com histórias de utilizador, critérios de aceitação e wireframes anotados que todos aprovaram. Isto elimina a maior fonte única de retrabalho.
• Um product owner dedicado do lado do cliente. Uma pessoa com autoridade para tomar decisões de produto, disponível diariamente, que pode responder a perguntas em horas em vez de dias. Na nossa experiência, este fator único tem mais impacto no ritmo do projeto do que quase qualquer outra coisa.
• Bibliotecas de componentes e sistemas de design pré-construídos. Mantemos bibliotecas de componentes de frontend reutilizáveis e módulos de backend que significam que elementos comuns — autenticação, permissões baseadas em funções, sistemas de notificação, fluxos de pagamento — não precisam de ser arquitetados do zero em cada projeto.
• Entrega faseada e âmbito de MVP definido. Acordar antecipadamente o que a primeira versão lançável contém — e manter todo o resto num backlog futuro — previne a expansão de âmbito que bloqueia a maioria dos projetos. Coloca algo nas mãos dos utilizadores mais rapidamente, o que gera feedback real que melhora as fases subsequentes.
• Uma equipa experiente com peso de seniority. Os engenheiros seniores tomam decisões arquiteturais corretamente à primeira. Identificam riscos antes de se materializarem. Escrevem código mais fácil de testar e de expandir. O custo diário é mais elevado. O custo total do projeto é rotineiramente mais baixo porque não geram o retrabalho que as equipas com peso em juniors geram.

---

Comparação de Prazos: Agência vs. Freelancer vs. Equipa Interna

Uma das decisões que define o prazo tanto quanto qualquer fator técnico é quem faz a construção.

Tipo de Envolvimento	Tempo Típico para Começar	Velocidade de Desenvolvimento	Pontos Fortes Típicos	Riscos Típicos
Agência de Software	2 – 4 semanas (onboarding)	Rápido uma vez iniciado — equipa completa disponível	Capacidade completa, entrega gerida, responsabilização	Taxa diária mais elevada, pode gerir múltiplos clientes
Freelancer / Programador Solo	1 – 2 semanas	Mais lento — uma pessoa, uma tarefa de cada vez	Custo mais baixo, comunicação direta	Ponto único de falha, capacidade limitada, lacunas em competências não técnicas
Equipa Interna	3 – 6 meses (contratação)	Mais rápida uma vez constituída, mais lenta a montar	Conhecimento profundo do produto, disponibilidade total	Custo fixo elevado, difícil de escalar, recrutamento demora tempo

Para a maioria das empresas que constroem um primeiro produto ou uma nova plataforma, uma agência é o caminho mais rápido para uma aplicação funcional. A razão é simples: a equipa já existe. Não precisa de contratar um designer, um programador de backend, um programador de frontend e um engenheiro de QA separadamente — já estão a trabalhar juntos, com processos estabelecidos, no primeiro dia do seu envolvimento.

Os freelancers podem funcionar bem para projetos pequenos e bem definidos onde é necessária uma única disciplina. Um programador solo não pode, contudo, ser simultaneamente gestor de produto, designer, engenheiro full-stack e engenheiro de QA — e a maioria das aplicações sérias precisa de todas essas coisas.

As equipas internas fazem sentido uma vez que lançou um produto, tem necessidades de desenvolvimento contínuas e pode justificar os custos fixos. Construir um novo produto com uma equipa interna que ainda não contratou é um risco de prazo que a maioria das empresas não pode dar-se ao luxo de correr.

---

A Estratégia MVP em Primeiro Lugar

Um dos conselhos mais consistentes que damos a clientes preocupados com o prazo é este: não tente construir tudo de uma vez.

A estratégia MVP em primeiro lugar significa definir a versão mais pequena da sua aplicação que entrega valor real a utilizadores reais — e construir isso primeiro. Tipicamente isto demora 8 a 14 semanas dependendo do tipo de projeto. A visão completa pode demorar nove meses a construir. Entregar algo utilizável em doze semanas supera uma construção completa de nove meses por razões que vão além da gestão do calendário.

Em primeiro lugar, obtém feedback real dos utilizadores antes de ter gasto todo o orçamento. A funcionalidade que pensava ser a proposta de valor principal pode revelar-se algo que os utilizadores mal tocam. O que considerava secundário pode ser aquilo sobre que perguntam em todas as conversas de suporte. Saber isto na semana catorze muda a forma de cada sprint que se segue.

Em segundo lugar, reduz o risco de construir a coisa errada. A maioria dos primeiros produtos evolui significativamente entre o conceito inicial e o product-market fit. Um MVP de doze semanas que chega aos utilizadores coloca-o numa posição de evoluir de forma inteligente. Uma construção completa de nove meses que chega aos utilizadores coloca-o nove meses atrás do que poderia ter estado — e ainda requer a mesma evolução.

Em terceiro lugar, demonstra progresso às partes interessadas. Sejam os seus stakeholders investidores, um conselho de administração, utilizadores internos ou clientes pagantes, algo real no qual se podem autenticar tem um peso diferente de um diagrama de Gantt e uma atualização de estado. Cria confiança, atrai feedback e gera dinamismo.

Estruturamos quase todos os novos envolvimentos de produto em torno do MVP em primeiro lugar. O objetivo é sempre levá-lo a algo lançável, para depois iterar a partir daí com a vantagem de dados do mundo real.

---

Prazos Fixos e o Que Custam

Por vezes o prazo não é negociável. Uma data de entrada em vigor regulatória. Um anúncio numa conferência. Um marco contratual com um cliente seu. Quando a data é fixa, as variáveis que tipicamente absorvem pressão — âmbito, custo e qualidade — têm de ser geridas deliberadamente.

A realidade da gestão de projetos está capturada no que é por vezes chamado o triângulo de ferro: pode tê-lo rápido, barato ou bom — e tipicamente pode escolher dois. Quando a velocidade é fixa, outra coisa tem de ceder.

Comprimir o prazo através de recursos adicionais funciona até um certo ponto. Adicionar um segundo programador de frontend a uma construção constrangida pelo frontend pode encurtar o calendário. Mas há um limite — adicionar cinco programadores a um projeto que tem um programador não o torna cinco vezes mais rápido. O onboarding, o overhead de coordenação, e as partes não paralelizáveis do desenvolvimento de software limitam os ganhos. Há também um custo: cada programador sénior adicional acrescenta um custo de taxa diária significativo, e o tempo gasto a integrar o seu trabalho acrescenta o seu próprio overhead.

Comprimir o prazo através da redução do âmbito é a alavanca mais fiável. Se o prazo é inamovível, a conversa que temos com os clientes é sempre: o que podemos adiar para uma versão subsequente sem comprometer o valor central do lançamento? Isto requer priorização honesta, não otimismo. As funcionalidades que parecem essenciais no planeamento revelam-se frequentemente coisas com que os utilizadores conseguem viver sem nas primeiras semanas.

Comprimir o prazo aceitando dívida de qualidade é a opção sobre a qual ninguém quer falar mas que muitos projetos acabam por adotar implicitamente. Reduzir o tempo de testes, saltar a revisão de código, lançar sem tratamento de erros adequado — estas coisas podem poupar dias a curto prazo e custar meses a longo prazo. Somos transparentes com os clientes quando vemos esta pressão a aumentar, porque a decisão de carregar dívida técnica deve ser tomada conscientemente, não descoberta em produção.

---

Como Planeamos os Prazos na Cyberbeak

Vamos ser diretos sobre o nosso próprio processo porque acreditamos que a transparência aqui constrói melhores relações de trabalho.

Cada projeto começa com uma fase de discovery estruturada que produz um documento de âmbito escrito, um backlog de funcionalidades priorizado, e uma estimativa de prazo dividida por sprint. O prazo não é uma data única escrita a lápis com base numa suposição otimista — é um plano sprint a sprint com marcos, dependências marcadas explicitamente, e riscos identificados documentados juntamente com abordagens de mitigação.

Incorporamos buffer ao nível do sprint — tipicamente dez a quinze por cento da capacidade de cada sprint — para absorver as incógnitas que são inerentes ao desenvolvimento de software sem fazer derrapar o calendário geral. Isto não é padding; é planeamento honesto. Projetos que afirmam não ter margem estão a tomar emprestada essa margem da fase de testes ou do trabalho de integração, e pagam-na sempre com juros.

Realizamos revisões semanais de marcos com os clientes. Estas não são reuniões de estado onde lemos a partir de uma folha de cálculo de progresso. São sessões de trabalho onde demonstramos o que foi construído, revemos o que está a vir, sinalizamos qualquer coisa que se tenha desviado do plano, e tomamos decisões conjuntas sobre como responder. Se uma funcionalidade está a demorar mais do que estimado, dizemo-lo na reunião dessa semana — não na semana final antes do prazo.

Usamos um processo de controlo de alterações para quaisquer adições de âmbito que surjam a meio do projeto. Isto não é burocracia por si mesma. É como mantemos o prazo original honesto. Cada pedido de alteração recebe uma avaliação de impacto documentada: quantos dias adicionais, qual é o custo, o que desloca do plano do sprint atual. Isso torna a troca visível, e o cliente decide se a aceita.

Por fim, acompanhamos o risco técnico explicitamente. Durante o discovery identificamos as integrações, as estruturas de dados, e os casos extremos que têm maior probabilidade de gerar surpresas. Calendarizamos spikes — explorações curtas e com limite de tempo — no início do projeto para validar os nossos pressupostos sobre esses riscos antes de se tornarem pressupostos críticos. Isto deteta as restrições não descobertas que afundam os prazos nos projetos que não as planeiam.

---

Perguntas Frequentes

É possível entregar mais rapidamente se eu pagar mais?

Até um certo ponto, sim — mas com limites claros. Orçamento adicional pode financiar uma equipa maior, que pode paralelizar mais trabalho e comprimir o calendário. No entanto, o desenvolvimento de software tem dependências sequenciais inerentes: certas coisas não podem começar até outras estarem terminadas, independentemente de quantos programadores estão disponíveis. Adicionar recursos ajuda mais em construções constrangidas pelo frontend ou pelo backend onde existe trabalho genuinamente paralelizável. Para além de um certo tamanho de equipa, headcount adicional acrescenta overhead de coordenação mais rapidamente do que acrescenta output. Iremos sempre aconselhá-lo honestamente sobre se o investimento adicional pode realmente mover a sua data.

E se eu mudar os requisitos a meio do projeto?

Os requisitos vão mudar. Esperamos isto, e o nosso processo lida com isso. A chave é que as alterações passem por uma avaliação de impacto formal antes de serem aceites no plano de sprint. Documentamos o que é a alteração, quantos dias acrescenta, qual é o seu custo, e o que desloca. Decide se a aceita. Alterações absorvidas informalmente — "é só uma coisa pequena" — são a forma como os projetos perdem semanas sem que ninguém saiba bem onde foi o tempo.

Os testes acrescentam tempo?

Os testes correm em paralelo com o desenvolvimento ao longo do projeto, por isso não acrescentam tempo por cima do desenvolvimento da forma que as pessoas por vezes assumem. A fase de testes end-to-end antes do lançamento — tipicamente uma a duas semanas — está contemplada no prazo desde o início. Saltar ou comprimir os testes para cumprir um prazo é uma das decisões mais caras que um projeto pode tomar. O custo de um bug crítico em produção, em termos de confiança dos utilizadores e tempo de engenharia de emergência, raramente vale o que se poupou no calendário de testes.

Quanto tempo demora a aprovação na loja de aplicações?

A revisão da App Store da Apple demora atualmente dois a sete dias úteis para a maioria das aplicações, embora aplicações com certas funcionalidades sensíveis ou novas contas de programador possam demorar mais, e as rejeições — que requerem uma nova submissão — acrescentam mais tempo. A revisão do Google Play demora tipicamente um a três dias. Contemplamos o tempo de revisão da loja de aplicações nos nossos prazos de projetos móveis e submetemos com margem suficiente para lidar com uma rejeição em ciclo padrão e uma nova submissão sem empurrar a data de lançamento.

O que causa mais atrasos nos projetos reais?

Na nossa experiência honesta: decisões lentas, não programadores lentos. A causa mais comum de um projeto ultrapassar o prazo não é técnica — é aguardar aprovações de design, conteúdo dos clientes, acesso a sistemas, confirmação de regras de negócio que se revelam não estar acordadas internamente, ou uma mudança de direção estratégica que exige repensar trabalho já construído. A segunda causa mais comum são requisitos que eram mais vagos do que pareciam no planeamento. Ambos são amplamente evitáveis com o investimento inicial correto em discovery e o compromisso de disponibilidade correto do lado do cliente ao longo do projeto.

---

Se está a tentar planear um prazo para um projeto e quer algo mais específico do que uma tabela de intervalos, a coisa mais útil que podemos fazer é conversar sobre o que está a construir. Oferecemos uma chamada de definição de âmbito gratuita de uma hora onde lhe faremos as perguntas que transformam um prazo vago num prazo realista — e daremos uma visão honesta do que o seu projeto provavelmente vai demorar e porquê.

Contacte a nossa equipa e trataremos disso a partir daí.