Está agrupado por serviço, porque é normalmente como a malta cá chega. Vais ao que te interessa, ignoras o resto. Se a tua pergunta não estiver aqui, manda mensagem pelo contacto e respondemos a sério.
Engenheiros seniores a levar um produto da ideia até algo que os utilizadores abrem mesmo. Discovery, construção, shipping, manutenção.
Quase todo o caminho. Uma equipa pequena de engenheiros seniores e design, normalmente quatro a seis pessoas, começa com discovery e depois constrói em ciclos curtos. Fazemos front end, back end, a parte chata de DevOps que mantém aquilo de pé. Se já tens alguma coisa internamente, entramos ao lado. Não trabalhamos numa ilha.
A maioria das builds anda entre três e nove meses, conforme o scope e a clareza dos requisitos. As primeiras semanas são discovery e um plano. Depois demos quinzenais, software a funcionar e estado honesto. Tentamos manter isto chato no bom sentido. Nada de heróis na sexta à noite.
Escolhes. Alguns clientes ficam com uma squad pequena em retainer para continuar a lançar. Outros querem um handover limpo para a equipa interna assumir. Escrevemos o README como se alguém tivesse de o ler numa segunda feira, porque é isso que costuma acontecer. Sem conhecimento escondido, sem código refém.
Os nossos engenheiros seniores a juntarem se à tua equipa, não o contrário. Mesmas standups, mesmo repo, mesmas code reviews.
O outsourcing tende a acontecer atrás de uma parede. Fazemos o contrário. As tuas ferramentas, o teu board, os teus rituais. As pessoas aparecem nas vossas standups, fazem push no vosso repo, apanham comentários em PRs como toda a gente. Não tens um PM no meio a traduzir tudo. Tens engenheiros.
Sim, dentro do razoável. A maior parte da equipa sobrepõe quatro a seis horas com a costa leste dos EUA, menos com a oeste. Com clientes na Europa há sobreposição de dia inteiro. Somos diretos sobre os timezones que uma pessoa consegue cobrir à vontade, para ninguém fingir que está acordado às três da manhã.
A maioria dos engenheiros em augmentation tem mais de oito anos de carreira. Não porque fica giro no site. É porque júnior mais codebase nova mais equipa nova é uma combinação má. Se precisas de uma stack específica ou de um perfil específico (um staff engineer, alguém que já fez payments), dizemos logo. Nada de trocar a meio.
Alguém que já viu muita arquitetura, muito tech debt e muitas decisões maradas, disponível numa cadência saudável.
Quando estás prestes a tomar uma decisão difícil de desfazer. Arquitetura nova, trocar de base de dados, separar um monólito, escolher cloud, contratar o primeiro VP interno. Às vezes só querem uma segunda opinião porque o CTO está esticado. Tudo razões válidas.
Normalmente uma sessão semanal ou quinzenal com os leads técnicos, mais perguntas async no Slack. Lemos o código, participamos nas reviews de arquitetura, sinalizamos riscos e metemos o importante por escrito para não se perder. Não gerimos a tua equipa. Ficamos ao lado de quem gere.
A auditoria é um mergulho num ponto específico no tempo. O advisory é contínuo e mais conversado. A auditoria é um check up. O advisory é ter um bom médico ao telefone. Muitos clientes fazem os dois. Um diz onde estás, o outro ajuda a não cair de um penhasco no próximo trimestre.
MVPs rápidos, com forma de produção. Polido o suficiente para demo, estrutura o suficiente para não atirar fora em três meses.
Quatro a oito semanas é o realista para a maioria das ideias, assumindo que sabes mais ou menos o que queres e decides depressa. Dez semanas se o domínio for confuso. Quem te vende um MVP em duas semanas está a vender uma demo, não um produto. Dizemos qual se aplica ao teu caso.
Cortamos scope, não qualidade. Menos funcionalidades, mas auth, observabilidade básica, um modelo de dados decente e um deploy que não é fita cola. Uma feature dá sempre para acrescentar. Arrancar uma fundação podre três meses depois é a parte que mata startups.
Dois caminhos típicos. Ficamos para a próxima fase (o mais comum) ou contratas pessoas internas e ajudamos no onboarding. Em qualquer dos casos, deixamos docs, uma sessão de handover e uma lista curta do que atacaríamos a seguir. Sem drama, sem código refém.
Um olhar independente sobre o teu código. Segurança, performance, tech debt, e o que atacar primeiro.
Quatro ângulos, normalmente. Riscos de segurança, gargalos de performance, tech debt e onde magoa a sério, e DX (este repo é suportável). Lemos o código, corremos ferramentas, falamos com os teus engenheiros. As conclusões ficam num relatório com severidade e esforço estimado.
Normalmente uma a duas semanas, conforme o tamanho do codebase. Precisamos de acesso de leitura ao repo, uma intro curta de alguém que conhece o sistema e uma ou duas calls quando batemos em coisa esquisita. Os teus engenheiros não têm de tomar conta de nós. É meio que essa a ideia.
Um relatório escrito que um founder não técnico consegue ler e um engenheiro consegue agir. Problemas ordenados por severidade e esforço, mais um roadmap de 30, 60, 90 dias. Sem enchimento, sem PDFs de 80 páginas que ninguém lê. Se quiseres ajuda a executar depois, ajudamos. Se não, o relatório vale por si.
Para equipas que já passaram a fase scrappy. Org design, processos, infra, contratação, cultura. O que parte quando cresces depressa.
A partir dos dez engenheiros, mais ou menos, quando os hábitos antigos começam a ranger. Os deploys abrandam, contratação parece aleatória, decisões de arquitetura acontecem no Slack e mais lado nenhum. Se estás aí ou quase, é boa altura. Se ainda são cinco pessoas, o que precisas é de lançar.
Normalmente os dois, e estão mais ligados do que parece. Um pipeline de deploy frágil é muitas vezes problema de gestão. Uma equipa sempre em burnout é muitas vezes problema de arquitetura. Olhamos para estrutura da organização, on call, processo de contratação e o lado da infra (CI, observabilidade, resposta a incidentes). Puxas um fio, vem tudo atrás.
Coisas tangíveis. Um plano de contratação, uma topologia de equipa revista, uma lista curta de investimentos de infra com custos aproximados e uma rotação de on call que não castiga sempre os mesmos três. Mais sessões semanais enquanto as mudanças acontecem. Se não se consegue medir num trimestre, provavelmente não devíamos estar a fazê lo.
Explore serviços, trabalhos ou entre em contacto.