Engenheiros React Native de produto
UI partilhada com navegação, state e testes tratados como trabalho de produto, não um snack Expo que vazou para produção.
React Native · iOS · Android
Programadores React Native que publicam nas duas lojas
Uma contratação React Native não é um engenheiro web com um wrapper. Os engenheiros da iQud entregam UI partilhada, native modules e pipelines de release prontos para as lojas que sobrevivem a caminhos offline, APIs de device e revisão App Store / Play, não uma WebView disfarçada de app.
- UI partilhada, native modules
- iOS e Android a partir de um lugar
- Cadência de release pronta para lojas
- Primeiro PR em cerca de uma semana
Sinais de entrega React Native
- 5 dTempo típico até ao primeiro pull request
- RNUI de produto partilhada, não um wrapper web
- 2 OSiOS e Android sem um segundo vendor
- 2 sem.Cadência de sprint com revisão em device
Os lugares React Native que realmente preenchemos
«React Native» não é um único ofício. Emparelhamos a superfície de produto de que precisa, as mesmas stacks por trás das nossas páginas React Native, Mobile Apps e iOS em produção.
01 02 Native modules quando a bridge não chega
Câmara, trabalho em segundo plano, pagamentos e bridges de hardware possuídos no repo, não um pacote npm que ninguém consegue depurar.
03 Lugares de release prontos para lojas
Certificados, builds, faixas TestFlight / Play e correcções de revisão como trabalho possuído, não um job de CI que só corre num portátil.
04 Workflows offline e de campo
Sync, filas e redes degradadas tratadas como superfícies de produto, não um «nice to have» após o happy path.
05 Performance que sobrevive a devices reais
Listas, animações e tamanho de bundle revistos em telemóveis de gama média, não uma demo fluida só no flagship do engenheiro.
06 Quando Flutter, iOS nativo ou um lugar web é melhor
Uma superfície de produto Dart-first, uma integração Swift profunda ou uma PWA de marketing ainda quer outra contratação. Diremo-lo na chamada intro em vez de forçar um lugar só-React Native.
Ferramentas que abrem no primeiro dia
Cada ladrilho é uma página de tecnologia ou serviço iQud. A faixa abaixo é React Native com as ferramentas de device, loja e dados mobile que estes engenheiros já entregam, não Flutter, Ionic, nem o catálogo mobile completo.
Da chamada intro a um PR fundido
Uma contratação React Native deve entregar num device no vosso repositório, não dois meses de teatro de onboarding enquanto os certificados expiram.
1 Mapear o fosso React Native
Expo vs bare, prioridade iOS vs Android, native modules, seniority, horas de sobreposição, e o que é «feito em 30 dias» nas duas lojas.
2 Pré-selecionar engenheiros reais
Emparelhamos especialistas React Native disponíveis com o vosso brief e partilhamos trabalho de app de produto, native modules ou release.
3 Vocês entrevistam
Conheçam a pessoa que vai entrar no standup. Validem como fala de uma fuga de bridge, de um build de loja falhado e do último caminho offline que realmente possuiu.
4 Primeiro sprint nas vossas ferramentas
Acesso ao repo, simuladores e primeiro pull request, normalmente numa semana após o go.
Comece com um lugar. Cresça se o backlog o disser.
A maioria dos clientes incorpora primeiro um engenheiro React Native. Um par ou um split de plataforma só se o trabalho o precisar mesmo.
Um engenheiro incorporado
Um especialista React Native junta-se ao vosso squad, segue o lead e trabalha nos vossos rituais.
Ideal paraFechar um fosso mobile cross-platform sem um processo de vendor novo
Lugar React Native dedicado
Um owner estável para a app partilhada, os native modules ou o pipeline de loja, com revisão sénior no sprint.
Ideal paraUm produto que precisa de um owner React Native com nome
Iniciativa React Native delimitada
Uma fatia definida: uma nova app consumer, um cutover de native modules, ou um caminho de release em loja com contratos já em movimento.
Ideal paraUm marco que possam apontar, não um banco aberto
Tarifas de contratação React Native, por escrito
Duas formas de staffar um engenheiro React Native. À hora para picos e tickets definidos. Um lugar mensal dedicado se quiserem alguém no standup todos os dias, a uma taxa efetiva mais baixa do que deixar o relógio correr.
Contratar à hora
20 €/ hora
Capacidade React Native flexível para picos de features, revisões e tickets delimitados. Pagam apenas as horas trabalhadas.
- Os mesmos engenheiros React Native que um lugar mensal
- Ideal para overflow, um fix de native module ou uma release única
- Começar depressa, pausar quando o pico acaba
- Faturado sobre horas reais, não um retainer
Melhor valor
Contratar por um mês
1840 €/ mês
Um engenheiro React Native com nome no vosso sprint, cerca de 160 horas de capacidade mobile dedicada, com revisão sénior na cadência.
Um mês a tempo inteiro a 20 € é 3200 €. Este lugar é 1840 €.
- Engenheiro com nome no repo, simuladores e standup
- UI partilhada e native modules no mesmo engagement
- Mês a mês. Sem compromisso anual.
- Mais barato do que as mesmas horas faturadas a 20 €
Tarifas para engenheiros React Native dedicados (UI partilhada, native modules, releases em loja). Mix de seniority e sobreposição confirmados na chamada intro. Não cotamos uma stack que não entregamos já.
Porque é que as equipas de produto staffam React Native aqui
Um programador React Native medíocre produz uma demo que funciona no simulador. Estes engenheiros produzem uma app que sobrevive a devices reais, lojas reais e ao próximo trimestre de releases.
Trabalho de produto em device, não «quem sabe eject Expo»
Vivem na bridge, no desempenho de listas, e porque o crash da semana passada vinha de um native module que deveria ter possuído o seu próprio caminho de retry.
O vosso repo, as vossas lojas, as vossas horas
Sobreposição GIFT City com a Europa e os EUA. As revisões em device acontecem em direto quando os leads estão online.
Olhos seniores no sprint
Velocidade mid-level sem dívida de bridge sem supervisão. A revisão faz parte do engagement, não um SKU extra.
Dez clientes por trimestre, de propósito
Não fazemos girar um banco. A capacidade é limitada para que o engenheiro que entrevistam seja o do standup.
Perguntas de contratação React Native
Comece com um. A maioria dos clientes incorpora um engenheiro React Native sénior ou mid, e depois acrescenta um par se o backlog de produto ou loja o justificar.
Os três quando é trabalho de produto. Um lugar Expo é um workflow gerido que publica nas duas lojas. Um lugar bare possui os projetos nativos. Um lugar native modules faz bridge a APIs de device que a camada JS não consegue simular. Só pré-selecionaremos engenheiros em stacks que já entregamos.
Isso é uma contratação mobile, uma contratação iOS, ou uma contratação React/Next.js, não este lugar. Digam-no na chamada intro e não imporremos um perfil só-React Native a um banco misto.
Depois de mapear o papel e o vosso OK, os primeiros pull requests aterram normalmente numa semana, mais rápido se o repo, simuladores e contas de loja estiverem prontos.
Sim. GitHub, Jira, a vossa CI, os vossos standups. Não inventamos um processo paralelo a menos que peçam.
À hora (20 €) é para picos e tickets definidos, pagam só as horas trabalhadas. O lugar mensal (1840 €) é um engenheiro React Native com nome no vosso sprint, cerca de 160 horas de capacidade dedicada. O mesmo mês faturado à hora seria 3200 €. Seniority e sobreposição confirmam-se na chamada intro.
Dê ao produto um engenheiro React Native que consiga publicar nas duas lojas
Digam-nos Expo vs bare, quais native modules importam, e a primeira release que querem no TestFlight ou Play. Voltaremos com um perfil com nome, uma janela de arranque e um plano de duas semanas.