role overview we are building an extensible, connector-based operations engine (“claw”) that: • connects to external systems (simpro, square, fresha, etc.) • normalizes schedule data • runs scheduled tasks (6am summaries) • supports a chat interface • logs usage and events • adds messaging capabilities (sms) • will expand into multi-connector, multi-vertical architecture this is not a basic crud web app. this is infrastructure designed to evolve across industries. we are looking for a long-term backend engineer to architect and evolve this engine over time. ⸻ what we are building (phase 1) • engine core with pluggable connectors • simpro adapter (read-only) • snapshot engine • scheduler • deterministic output • llm usage tracking • dockerized deployment future phases include: • additional connectors (square, fresha) • messaging module (sms) • delay broadcast logic • reply handling • multi-tenant support • governance features ⸻ the candidate we want must have: • 5+ years backend engineering experience • strong experience with: • rest apis • third-party api integrations • authentication flows (oauth, api keys) • webhooks • async job processing • message queues (optional but preferred) • deep understanding of: • data modeling • timezone handling (utc vs local) • deterministic system design • connector/adaptor pattern • clean architecture principles • experience building: • multi-tenant saas systems (preferred) • production deployments (docker required) • logging + observability • comfortable with: • versioned schemas • interface contracts • writing clean abstractions ⸻ not a fit if • you primarily build frontend-heavy apps • you’ve only built small crud dashboards • you rely heavily on no-code tools • you cannot explain how to design a connector abstraction cleanly • you do not understand utc storage vs local rendering ⸻ technical evaluation questions 1. how would you design a connector interface to allow swapping simpro with square without touching core logic? 2. how would you ensure timezone safety across dst changes? 3. how would you prevent business logic from leaking into adapter layers? 4. how would you design the database to support future multi-tenant isolation? 5. how would you structure a system that may add sms, webhooks, and external connectors later? 6. how would you test third-party api integrations safely? ⸻ desired stack (flexible but opinionated) open to node.js, python, or go. must include: • postgresql • docker • clear environment config separation • proper logging bonus: • experience with event-driven patterns • experience with idempotency • experience with rate limiting • experience with background job processing ⸻ long-term role we are not hiring for a one-off build. we are building an extensible engine that will: • expand to multiple verticals • add connectors over time • possibly evolve into multi-tenant saas we want someone who: • thinks in systems • pushes back on weak architecture • is comfortable evolving infrastructure • can work long-term ⸻