Desenvolvimento sob medida
Alguns problemas não cabem em um site. Quando o trabalho é uma ferramenta, um aplicativo, uma integração ou um processo que não deveria mais ser feito à mão, construímos isso em vez de um site.
Pequenos, sêniors e honestos quanto ao escopo. Se um produto existente resolve o seu problema, diremos isso em vez de cobrar para reconstruí-lo.
Registro
Os tipos de trabalho que aceitamos
Uma forma útil de descrever software sob medida é pelo problema que ele resolve. Estes são os casos que mais aparecem, e o que costumamos acabar construindo.
| O problema | O que construímos |
|---|---|
| A mesma tarefa manual, todos os dias, feita por alguém sênior demais para isso | Uma ferramenta interna com as etapas codificadas de uma vez por todas: um formulário, uma fila, um histórico de auditoria claro e permissões que refletem como a equipe realmente trabalha. |
| Dois sistemas que não conversam entre si | Uma integração que administra o mapeamento entre eles, tenta de novo com segurança quando um lado está fora do ar, e avisa quando algo precisa de uma pessoa. |
| O negócio rodando em uma planilha que ninguém ousa tocar | Uma pequena aplicação web com um modelo de dados de verdade por trás, para que duas pessoas possam trabalhar ao mesmo tempo e os números do trimestre passado não sejam sobrescritos por acidente. |
| Um relatório que alguém monta à mão toda semana | Uma tarefa agendada que reúne os dados, os verifica e entrega o relatório para quem precisa dele, com um registro de cada execução. |
| Trabalho que acontece longe de uma mesa: em um celular, em uma van, no chão de fábrica | Um aplicativo móvel sobre a mesma base do resto do sistema, compartilhando o seu modelo de dados, o seu padrão de revisão e as suas checagens automatizadas, para que o celular e o computador nunca discordem dos fatos. |
| Um fluxo de cliente encaixado à força em um site institucional até quebrar | Uma aplicação de verdade em seu próprio endereço, compartilhando o design system do site para que ainda pareça uma única empresa. |
| Algo que ninguém consegue orçar porque ninguém definiu o escopo | Uma etapa curta de descoberta: a menor versão funcional definida por escrito, com as partes que não construiríamos listadas com a mesma clareza. |
Critério
Como decidimos o que construir
- A menor coisa que funciona, primeiro. Uma ferramenta enxuta em produção ensina mais em duas semanas do que uma especificação completa ensina em um trimestre, e pode ser ampliada assim que você souber quais partes importam.
- Tecnologia sem graça de propósito. Escolhemos a opção comprovada em vez da interessante. Software sob medida é julgado no dia em que alguém precisa alterá-lo, não no dia em que é lançado.
- Acertar o modelo de dados cedo. Interfaces são baratas de redesenhar e dados são caros de reestruturar, então o formato dos dados é definido antes das telas.
- Comprar antes de construir. Se um produto licenciado cobre o seu caso, a recomendação honesta é usá-lo. Preferimos construir a pequena peça que o conecta do que cobrar para reinventá-lo.
- Projetar para o segundo desenvolvedor. Código legível, configuração documentada, testes que explicam a intenção. A medida do trabalho é se outra pessoa consegue alterá-lo com segurança.
Stack
A tecnologia que realmente usamos
Nomeá-la faz parte de ser honesto sobre o escopo. Um comprador técnico deveria conseguir avaliar em uma única tela se somos o estúdio certo, e um comprador não técnico deveria conseguir passar esta seção para o seu próprio desenvolvedor e obter uma resposta direta.
TypeScript, do início ao fim
Astro, HTML e CSS puros, React onde uma aplicação precisa, além de aplicativos móveis
Node e Cloudflare Workers
Bancos de dados compatíveis com Postgres, migrações SQL versionadas
Cloudflare Pages, Workers, armazenamento de objetos, gatilhos agendados
Playwright, Vitest, tipos estáticos, auditorias automatizadas de acessibilidade
- Uma linguagem em todo o sistema. TypeScript para a interface, a API, as tarefas agendadas e os testes, com os tipos checados a cada mudança. Uma linguagem significa uma única cadeia de ferramentas e um único padrão de revisão, e nenhuma camada de tradução entre o navegador e o serviço por trás dele.
- Renderização escolhida por tarefa. O conteúdo compila em HTML estático. Uma interface que genuinamente precisa de estado no cliente recebe um framework de componentes, restrito à parte da tela que precisa dele, em vez de um framework envolvendo conteúdo que nunca muda.
- Aplicativos móveis, com a mesma disciplina. Quando o trabalho pertence à mão de alguém, e não a uma aba do navegador, construímos o aplicativo com o mesmo padrão de tudo o mais: a mesma cadeia de ferramentas centrada em TypeScript, o mesmo padrão de revisão, as mesmas checagens automatizadas, e o mesmo modelo de dados do serviço por trás dele, em vez de uma segunda versão da verdade. Qual stack um determinado aplicativo deve usar é uma decisão que tomamos com você enquanto o escopo está sendo escrito, não uma preferência da casa aplicada a todo projeto.
- Um banco de dados relacional, não uma sopa de documentos. Um banco de dados compatível com Postgres, com uma camada de consulta tipada, e mudanças de esquema que são revisadas, aplicadas em ordem e reversíveis. Ninguém edita um esquema de produção à mão.
- Serverless por padrão, porque não há servidor para esquecer. O código roda na plataforma de borda da Cloudflare, com armazenamento de objetos para arquivos e workers agendados para qualquer coisa que precise acontecer em um horário. Nenhuma máquina sua para remendar à meia-noite e nenhuma capacidade para adivinhar.
- Integrações por interfaces documentadas. Outros sistemas são acessados por suas APIs e webhooks, com novas tentativas, idempotência e um registro de cada chamada. Onde um fornecedor não oferece API, um feed de arquivo ou dados agendado é a alternativa deliberada, nunca um scraping de tela que vai quebrar no próximo trimestre.
- Ambientes e segredos como configuração, nunca como folclore. A infraestrutura é declarada no repositório, as credenciais vivem em um cofre de segredos e chegam ao serviço em produção como variáveis de ambiente, e uma máquina nova roda o projeto na mesma tarde.
- O seu stack, quando você já tem um. Se a sua equipe mantém algo razoável, a resposta certa costuma ser trabalhar dentro dele em vez de introduzir uma segunda forma de fazer tudo. E se o que você tem é genuinamente o problema, você também vai ouvir isso.
Padrões
O mesmo piso de engenharia dos sites
O piso não muda entre as duas linhas de serviço, porque uma ferramenta interna é usada por anos por pessoas que não podem escolher outra. Código padrão em um repositório com todo o histórico, checagens automatizadas que impedem um deploy que falha, lançamentos em um único comando que revertem em uma etapa, interfaces acessíveis (a equipe merece o mesmo padrão que os clientes recebem), segredos fora do código, e nenhuma plataforma proprietária por trás de nada disso. Está detalhado em sites corporativos em vez de ser repetido aqui.
Duas coisas pesam mais em software do que em um site, e vale a pena nomeá-las separadamente.
Os dados sobrevivem ao código
Interfaces são substituídas; os registros permanecem. Então mudanças de esquema são migrações no repositório, aplicadas em ordem e reversíveis, backups são responsabilidade da plataforma e não de um script que alguém escreveu uma vez, e os seus dados podem ser exportados em um formato que você poderia carregar em outro lugar inteiramente.
Um sistema em produção precisa ser observável
Tudo o que acontece sem ninguém olhando deixa um registro: o que rodou, quando, o que tocou e onde falhou. Uma tarefa agendada que silenciosamente para de funcionar nos avisa, em vez de ser descoberta um mês depois pela pessoa que ficou se perguntando para onde foi o relatório dela.
Escopo
Onde paramos
Ser claro sobre os limites faz parte de ser confiável. Somos uma equipe pequena e sênior, então aceitamos o trabalho que sabemos fazer bem e dizemos não ao que não sabemos.
Não revendemos plataformas licenciadas, não alocamos gente em um projeto que não estamos construindo, e não vamos passar um valor para um problema que ainda não foi escopado. Quando uma parte do trabalho pertence a um especialista, diremos isso claramente em vez de você descobrir às suas custas.
Os limites técnicos são igualmente específicos:
- Usar um modelo sim, ciência de dados não. Chamamos um modelo hospedado ou um serviço existente a partir da sua aplicação e construímos a interface e a integração ao redor dele. Treinar modelos, análise estatística e pipelines de dados em escala de data warehouse não é o que fazemos.
- Plataformas gerenciadas sim, servidores seus não. Fazemos deploy em plataformas gerenciadas de borda e serverless. Se o trabalho precisa rodar no seu próprio data center, em máquinas que você administra, ou em um sistema operacional que alguém precisa manter atualizado, somos o estúdio errado e você vai ouvir isso já na primeira conversa.
- Regimes certificados precisam de um especialista ao nosso lado. Aplicamos engenharia de segurança de verdade como rotina, mas uma auditoria formal contra um regime nomeado é uma especialidade que não vendemos. Se o seu projeto precisa de uma, dizemos isso antes de você assinar qualquer coisa, não depois.
- Firmware, e revenda. Firmware embarcado não é a nossa disciplina, e também não é qualquer coisa cujo valor seria uma licença revendida em vez de trabalho que fizemos.
Operação
Quem mantém o sistema rodando depois
Software sob medida não está pronto quando é lançado. Ele passa a ser usado, e então precisa mudar. Quem opera o sistema e quem faz as mudanças pertence ao escopo desde o início, não a um e-mail incômodo seis meses depois.
Nós hospedamos e mantemos o sistema no ar
Esse é o padrão: nós hospedamos e operamos o sistema por uma mensalidade, e as mudanças depois do lançamento seguem o mesmo ciclo da construção, ou seja, uma branch, uma prévia, o conjunto completo de checagens, e um deploy que reverte em uma etapa. As pessoas que escreveram o sistema são as mesmas que o observam em produção, o que costuma ser a diferença entre um ajuste tranquilo e uma longa discussão sobre de quem é o problema.
Ser uma equipe pequena e sênior tem um custo, e preferimos declará-lo: não mantemos um plantão de 24 horas e não vendemos um tempo de resposta garantido em minutos. Se o que você está construindo genuinamente precisa disso, nos diga cedo e responderemos com honestidade se conseguimos atender.
Ou a sua própria equipe assume
Quando o seu contrato inclui essa opção, o software pode migrar para a sua própria hospedagem e para os seus próprios desenvolvedores: código padrão, os testes, a configuração documentada e um deploy que é um único comando. É exatamente para isso que serve projetar para o segundo desenvolvedor, mencionado acima. É uma opção que registramos por escrito quando você quer, não o combinado padrão.
A plataforma ajuda aqui também. Um site estático e um serviço serverless não têm servidor para remendar nem sistema operacional para manter em dia, então o que resta são atualizações de dependências e de plataforma: uma mudança agendada e revisável, não uma emergência.
Você não precisa de uma especificação para começar. Fale conosco pelo formulário de contato ou em sales@wwi.dev e descreva o trabalho em linguagem simples.