Apps mobile
iOS e Android, nativas ou híbridas. Publicação nas lojas, notificações, pagamentos, modo offline quando faz falta.

iOS, Android e web, nativo ou híbrido conforme o projeto pede. Desenhadas para o gesto que se repete, medidas por quem volta.
Vamos falarMetade das apps são abertas uma vez. O problema raramente é técnico: é uma app feita para o lançamento, com dez funcionalidades na primeira versão e nenhuma razão para voltar na segunda semana.
Do outro lado, as ferramentas internas: folhas de cálculo partilhadas, formulários por e-mail e três sistemas que não se falam, a custar horas todos os dias a quem tinha mais que fazer.
Começamos pelo gesto que se repete: a única coisa que a app tem de fazer melhor do que qualquer alternativa. A primeira versão faz isso muito bem e pouco mais, e vai para utilizadores reais em semanas.
Depois, mede-se quem volta e porquê, e cada versão seguinte é decidida por isso. Nativo ou híbrido, web ou loja, decide-se pelo projeto e pelo orçamento, não pela moda.
iOS e Android, nativas ou híbridas. Publicação nas lojas, notificações, pagamentos, modo offline quando faz falta.
Back-offices, portais de cliente, áreas reservadas e ferramentas internas que substituem folhas de cálculo e e-mails.
Do protótipo navegável à primeira versão em produção. Utilizadores reais desde cedo, funcionalidades ordenadas pelo que aprendem.
O serviço por trás da app: autenticação, dados, integrações com CRM, pagamentos e sistemas da casa.
Fluxos desenhados e testados antes do código. Um ecrã a menos vale mais do que uma funcionalidade a mais.
Versões, sistemas operativos e lojas mudam todos os anos. Ficamos, com um plano de evolução e o custo à vista.
Duas semanas: quem usa, o que repete, o que existe hoje. Sai o gesto central e a lista do que fica de fora da primeira versão.
Fluxos navegáveis testados com utilizadores reais antes de uma linha de código. Aqui é barato mudar de ideias.
Ciclos de duas semanas com versão instalável no fim de cada um. O cliente usa a app enquanto ela se faz.
Publicação nas lojas, medição de retenção e um plano de versões decidido pelo que os utilizadores fazem, não pelo que se imaginou.
Tem uma ideia de app, ou uma folha de cálculo que já devia ser uma?
Descreva-nos o gesto que se repete. Respondemos com uma primeira leitura: nativo ou híbrido, o que entra na primeira versão e quanto custa chegar lá.
Depende do que a app precisa do telemóvel. Câmara, sensores, desempenho gráfico ou offline pesado apontam para nativo. Uma app de conteúdo, serviço ou comércio fica bem servida em híbrido, com uma base de código para as duas lojas e metade do custo de manutenção. Decidimos na descoberta, com o orçamento à frente.
Só se houver um gesto que se repete e que o telemóvel faz melhor: notificações, câmara, localização, acesso rápido. Muitas vezes a resposta certa é uma aplicação web instalável, sem lojas nem aprovações. Dizemos-lhe qual é antes de propor.
Um MVP bem delimitado, três a quatro meses da descoberta à publicação. As aprovações da Apple e da Google contam-se em dias, quando a app está preparada para elas desde o início.
A app precisa de quem a mantenha: sistemas operativos novos, regras das lojas, dependências. Propomos um plano de evolução com horas mensais e prioridades decididas pela medição.
Reserva de transporte, leilões online, saúde, plataformas de descontos, apps de bairro e de cidade, personalizadores de produto para retalho. Os casos estão na página de trabalho.