I wouldn’t start by choosing between those titles. I’d start by designing the interview test.
The three roles you’re weighing — low-code builder, systems-minded engineer, implementation consultant — are all reasonable starting points. But at the scale you described: 500K+ records, 50 daily users, and multiple integrated tools, I’d worry less about the title and more about how the person thinks through the system.
A few things I’d test for in interviews:
1. **Data architecture thinking, not just workflow building.**
Before they touch n8n, I’d want to see how they would structure the Airtable base: what lives where, what should be normalized, what might need to be denormalized for performance, and which fields become the source of truth. At 500K records, a weak schema choice will show up everywhere.
2. **Integration boundary awareness.**
Your stack touches Airtable, Zapier, Stacker, Make, n8n, Supabase, and Polytomic. The harder question is not “can you build in each tool?” It’s “which tool owns which responsibility, and where do handoffs fail?” I’d ask candidates to explain the boundaries between tools, not just list experience with them.
3. **Maintainability as a requirement, not an afterthought.**
If you want this to scale and stay maintainable, the person should be able to explain naming conventions, error handling, documentation, and what another person would need to know to take over later.
So yes, “Business Systems Analyst / Architect” tracks as a direction. But I’d treat the title as secondary.
A useful interview filter might be: ask them to map the data model, integration boundaries, and failure paths before they talk about building workflows.