No comenzaría eligiendo entre esos títulos. Comenzaría diseñando la prueba de entrevista.
Los tres roles que estás considerando — creador de código bajo, ingeniero orientado a sistemas, consultor de implementación — son todos puntos de partida razonables. Pero en la escala que describiste: 500K+ registros, 50 usuarios diarios e herramientas integradas múltiples, me preocuparía menos por el título y más por cómo la persona piensa el sistema.
Algunas cosas que probaría en entrevistas:
1. **Pensamiento de arquitectura de datos, no solo construcción de flujos de trabajo.**
Antes de que toquen n8n, querría ver cómo estructurarían la base de Airtable: qué va dónde, qué debería normalizarse, qué podría necesitar desnormalizarse por rendimiento, y qué campos se convierten en la fuente de verdad. Con 500K registros, una mala elección de esquema se verá en todas partes.
2. **Conciencia de límites de integración.**
Tu stack toca Airtable, Zapier, Stacker, Make, n8n, Supabase y Polytomic. La pregunta más difícil no es “¿puedes construir en cada herramienta?” Es “¿qué herramienta es responsable de qué, y dónde fallan los puntos de entrega?” Preguntaría a los candidatos que expliquen los límites entre herramientas, no solo que enumeren experiencia con ellas.
3. **Mantenibilidad como requisito, no como una idea tardía.**
Si quieres que esto escale y siga siendo mantenible, la persona debería poder explicar convenciones de nombres, manejo de errores, documentación, y qué necesitaría saber otra persona para hacerse cargo después.
Entonces sí, “Analista de Sistemas de Negocio / Arquitecto” se ve como una dirección. Pero trataría el título como secundario.
Un filtro de entrevista útil podría ser: pídeles que mapeen el modelo de datos, los límites de integración y las rutas de fallo antes de que hablen sobre construir flujos de trabajo.