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.
Desenvolvimento de aplicativos
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
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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çãoServiços relacionados