Desenvolvimento de aplicativos

Aplicativos que conversam com o sistema que sua empresa já usa.

iOS e Android, para seus clientes ou para quem trabalha com você. O que decide se um aplicativo vale a pena não é a tela: é se ele lê e escreve nos dados que a empresa já tem, sem ninguém digitar a mesma coisa duas vezes.

Quando a pergunta aparece

O aplicativo costuma aparecer por um destes três motivos.

A operação vive em planilhas e no WhatsApp.

Cada pedido chega por mensagem, alguém copia para uma planilha e o status real depende de quem você perguntar. Não é falta de organização: é que ninguém tem o dado na hora em que precisa dele.

Seus clientes já pedem para resolver pelo celular.

Querem pedir, agendar ou ver em que pé está o serviço sem ligar e esperar resposta. Hoje quem responde isso é uma pessoa, em horário comercial.

O site resolve a primeira visita, não a décima.

Ele serve para te encontrarem e falarem com você. Quando a mesma pessoa volta toda semana para repetir a mesma tarefa, o navegador vira o caminho longo: procurar a página, entrar de novo e só descobrir uma mudança se abrir.

O que construímos

Um aplicativo são quatro trabalhos, não uma tela.

Aplicativo para seus clientes

Pedir, agendar, acompanhar uma entrega, ver o histórico e pagar quando faz sentido. O que hoje uma pessoa resolve por mensagem, disponível às onze da noite de um domingo.

Aplicativo para sua equipe

Para quem trabalha longe da mesa: o registro acontece onde o trabalho acontece, com a foto e a assinatura anexadas ali mesmo, e o que foi feito não se perde quando o galpão ou a estrada ficam sem sinal.

Publicação na App Store e no Google Play

Contas de desenvolvedor, ficha da loja, capturas, política de privacidade, assinatura e o vaivém com a revisão da Apple, que recusa por motivos nem sempre óbvios. Depois, cada atualização passa por ali de novo.

Integração com o que você já tem

O aplicativo não cria um banco de dados paralelo: consulta o seu. Se o seu sistema não expõe uma API, nós escrevemos. É o mesmo trabalho que está por trás dos sites que publicamos.

Como trabalhamos

A primeira versão se define tirando, não somando.

  1. 01

    Entendemos como vocês trabalham hoje.

    Um dia real de operação: quem registra o quê, onde trava, o que se resolve por mensagem e qual papel ainda circula. Sem isso, o aplicativo vira uma versão digital da bagunça.

  2. 02

    Definimos o escopo mínimo útil.

    A lista de funções sempre cabe inteira numa reunião e nunca cabe inteira na primeira versão. Ficamos com as poucas que justificam alguém instalar o aplicativo e anotamos o resto para depois.

  3. 03

    Construímos, e quem testa é gente de verdade.

    Cada entrega é testada em celulares reais, com quem vai usar e com dados da sua operação. É desconfortável, e é ali que aparece tudo o que nenhuma reunião previu.

  4. 04

    Publicamos e continuamos.

    Entrada nas lojas, medição do que é usado e do que não é, e correções com esse sinal. Um aplicativo sem manutenção não quebra de uma vez: Apple e Google atualizam seus requisitos e, um dia, uma atualização deixa de ser aceita.

Perguntas frequentes

Nativo ou multiplataforma?

Na maioria dos casos escrevemos uma única base de código e dela saem os dois aplicativos: há menos para manter e as duas versões não vão ficando diferentes uma da outra. Vamos para nativo quando o aplicativo depende de algo que o sistema operacional só entrega ali: trabalho contínuo em segundo plano, integração com um equipamento ou um leitor específico, ou uma exigência de desempenho que medimos antes de decidir. Nativo significa dois códigos, e dois códigos custam o dobro para manter. É uma decisão tomada com o caso na mesa, não por preferência.

Quanto custa um aplicativo?

Depende de quatro coisas, nesta ordem: quantas telas tomam uma decisão de negócio, se a API ainda precisa ser construída, se o aplicativo lida com pagamentos ou dados sensíveis e se precisa funcionar sem sinal. Um aplicativo para consultar um status e um aplicativo que substitui o processo de faturamento não dividem o mesmo orçamento nem a mesma conversa. O número vem depois do primeiro passo, entender a operação, e não na primeira mensagem. E há custos que não são nossos: as contas de desenvolvedor de cada loja e a infraestrutura onde o backend roda.

Vocês fazem iOS e Android?

Sim, e normalmente a partir da mesma base de código. Publicar nas duas lojas ao mesmo tempo não dobra o desenvolvimento, mas dobra o trabalho de loja: duas fichas, duas revisões, dois ciclos de atualização. Se o aplicativo é para a sua equipe e os celulares são da empresa, às vezes uma plataforma basta, e vale dizer isso logo no começo.

Ele consegue conversar com o sistema que já uso?

Quase sempre sim, e a pergunta real é por onde. Se o seu sistema expõe uma API, o aplicativo consome. Se não expõe, mas dá para chegar aos dados, escrevemos a camada intermediária. Se for um produto de terceiros fechado, sem API e sem caminho de integração, não existe mágica: falamos isso antes de começar e decidimos ali o que fazer, em vez de descobrir no meio do projeto.

Quem publica o aplicativo nas lojas?

O trabalho é nosso: contas, ficha, capturas, política de privacidade, assinatura e envio para revisão. As contas de desenvolvedor, porém, ficam no nome da sua empresa. Dá mais burocracia no início e é a única forma de o aplicativo e os usuários continuarem do seu lado se um dia deixarmos de trabalhar juntos. Se o aplicativo for só para a sua equipe, as duas plataformas permitem distribuição interna sem ficha pública.

O que acontece depois do lançamento?

Nas primeiras semanas aparece o que nenhum teste previu, porque o uso real cria combinações que ninguém planejou, e é quando a correção é rápida. Depois o trabalho muda de natureza: acompanhar os requisitos da Apple e do Google, ver quais funções são usadas e quais não são, e decidir o que construir com essa informação. Dá para combinar um acompanhamento mensal ou trabalhar por mudanças pontuais; o que não recomendamos é publicar e nunca mais olhar.

Antes de orçar um aplicativo, vale saber se você precisa de um.

Conte como sua equipe trabalha hoje e o que seus clientes vêm pedindo. Se isso se resolve melhor ajustando o site ou o sistema que você já tem, vamos dizer isso antes de você gastar com um aplicativo.

Falar sobre minha operação