Build vs. Buy: desenvolver a integração de hardware ou usar uma API?

A decisão que ninguém explica bem

Quando um cliente pede para seu SaaS ler os terminais biométricos dele, há dois caminhos para responder. Build: seu time estuda o protocolo do fabricante, escreve o adaptador, monta a infraestrutura e mantém tudo vivo. Buy: você consome uma API gerenciada como a API Connect, que já resolveu esse problema e expõe os equipamentos como endpoints REST.

A conversa costuma começar mal porque se compara o errado: compara-se o preço do desenvolvimento com o preço da assinatura. A comparação correta é o custo total de propriedade do primeiro ano contra uma linha no seu plano de gastos. Veja o porquê.

O que o Build realmente implica

Desenvolver a integração própria não é um sprint de duas semanas. É um módulo permanente do seu produto com estes componentes:

• Engenharia de protocolo: os terminais não falam HTTP. Implementar o modo push/ADMS significa lidar com sessões, formatos binários de transferência de dados e variações por família de firmware. Cada modelo novo é um dialeto novo.
• Infraestrutura pública: para que os equipamentos se conectem ao seu SaaS, você precisa de um servidor com endereço público estável, TLS, alta disponibilidade e monitoramento 24/7. Não é a mesma infraestrutura da API do seu negócio: é infraestrutura de dispositivo.
• Armazenamento de eventos: cada marcação chega por conta própria; você precisa de ingestão tolerante a picos, deduplicação (os terminais reenviam ao reconectar) e consultas eficientes por intervalo de datas.
• Manutenção permanente: firmware mudam comportamentos, fabricantes corrigem bugs, clientes relatam modelos raros. O adaptador nunca fica "pronto": é mantido por toda a vida.
• Segurança: autenticar dispositivos que não têm usuário e senha, com tudo o que isso implica em risco e auditoria.

O que o Buy realmente implica

Com uma API gerenciada, o trabalho do adaptador, a infraestrutura de conexão e a manutenção do protocolo já estão feitos e se mantêm sozinhos. Sua parte do trabalho é a que realmente agrega valor ao seu SaaS:

• Autenticação: um login padrão contra a API te dá um token JWT com expiração.
• Consumo: relatórios por terminal com intervalo de datas e paginação, e eventos em tempo real (por webhook ou stream) para a lógica urgente.
• Gestão: cadastro de usuários e credenciais por número de série via API.

curl -X POST https://TU-DOMINIO-API/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "tu_usuario", "password": "tu_password"}'

# Token pronto para chamar a API
{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...",
  "token_type": "bearer",
  "expires_in": 3600
}

A comparação honesta

Quando o Build SIM faz sentido

Para não ser enganoso: existem casos em que construir é a decisão certa. Todos compartilham estas características:

• Você tem um requisito muito específico que nenhuma API expõe (por exemplo, controle direto de um periférico não suportado).
• Você tem um time de engenharia dedicado que pode assumir a manutenção indefinida sem sacrificar o roadmap.
• Seu roadmap de produto inclui hardware próprio: o adaptador seria um ativo estratégico, não um remendo.
• O volume justifica o investimento: milhares de terminais onde cada centavo por terminal muda a economia.

Se o seu caso é "meu SaaS precisa ler os terminais ZKTeco dos meus clientes", nenhum desses quatro se aplica. Você está no território do Buy.

A regra de decisão em uma frase

Construa o que diferencia seu produto; compre todo o resto. Seu SaaS não compete por saber parsear o protocolo ADMS — compete por folha de pagamento melhor, condomínios melhores, segurança melhor. A integração de hardware é um meio, não o seu produto.

Perguntas frequentes