CanadianSME Small Business Magazine
Website:
canadiansme.ca
Job details:
Senior Engineer — Platform & API
Own the backend and infrastructure beneath an AI-powered front desk for small businesses: API architecture, auth and multi-tenancy, billing, telephony, and reliability. You'll write production code every day and manage nobody.
Where
India · Remote
Experience level
Senior · 5 to 7+ years
Full-time
Individual contributor
Salary
upto 50 INR per month
ABOUT THIS ROLE
Why this role exists
SMB AI Hub was built extraordinarily quickly using AI-assisted development into a substantial, working product: an assistant that answers a business's phone, runs its chat, manages campaigns, and operates its public hub site.
Speed built the product. It doesn't replace the judgment that comes from operating production systems — responding to incidents, evolving complex databases, protecting tenant boundaries, designing APIs other systems depend on, and knowing what breaks once real customers arrive. That judgment is what this role brings.
Your job is not a blank page and not a rewrite. It is to understand what exists, challenge it where necessary, independently verify and harden the foundations, and build the next stage of the platform on top of them.
The technical team is three people: the founder — who owns customer problems, priorities, and sequencing — and two senior engineers who own how those become reliable production software. Within the platform domain, you make the technical decisions.
RESPONSIBILITIES
What you'll own
Ownership is intentionally broad: if multiple product surfaces depend on it, it's yours.
• API & action platform — one well-designed capability model with multiple consumers: the versioned API, AI tool calling, and future first-party clients. You set and defend the standards: versioning, idempotency, pagination, error contracts, webhooks, backwards compatibility.
• Auth, authorization & multi-tenancy — the organization, role, and tenant-isolation model. An early mandate is an independent, adversarial review of the security-critical layers: your review is the evidence the platform builds on.
• Billing, wallet & metering — Stripe, usage metering, automated charging. Paths that move customer money get designed accordingly: idempotent, observable, auditable, recoverable.
• Telephony & communications — voice and messaging providers, OAuth-connected channels, webhook-heavy integrations, delivery state, retries. Exact providers matter less than having survived asynchronous third-party systems in production.
• Infrastructure & provisioning — customer subdomain provisioning, DNS automation, deployment controls.
• Reliability, security & observability — not projects after features ship, but how the platform gets built: CI safeguards, integration testing, structured logging, alerting, audit trails, runbooks. The objective: the system gets safer as development gets faster.
THE FIRST SIX MONTHS
What success looks like
Month 1 — understand the system and strengthen its safeguards
Build a detailed understanding of the existing architecture before proposing structural change. Independently review the security-critical layers, strengthen automated test and audit coverage, and put safeguards around the workflows that move money or send customer communications. Determine what can be trusted, what needs evidence, and what needs to change.
Months 2–3 — production voice runtime
Ship the platform capabilities for realtime AI voice calls — as production infrastructure, not a successful API integration: provider failures, duplicate events, concurrency, call lifecycle, latency, metering, recovery.
Months 4–5 — multi-channel platform
Take additional communication channels to production quality while establishing the shared API and auth architecture that future clients build on without duplicating business logic.
Month 6 — stable, documented, dependable
By six months, the platform's important capabilities should not just work — they should be monitored, tested, recoverable after failures, auditable, documented, and understandable by another senior engineer.
REQUIREMENTS
Required experience
Most strong candidates will have around 7+ years of professional experience. We care more about demonstrated production judgment than the exact number of years, and we will ask about all of the areas below.
• Multi-tenant SaaS, operated — you've reasoned about where tenant boundaries fail and how to enforce them, not just added an organization column.
• PostgreSQL depth — schema design, transactions, RLS, roles, SECURITY DEFINER, migration discipline; comfortable evolving a large existing database, not just designing a new one.
• Backend TypeScript — strong production Node.js/TypeScript preferred; deep backend engineers from another modern ecosystem who convert quickly are welcome.
• API design others depended on — idempotency, versioning, webhook semantics, and error design as production experience, not interview vocabulary.
• Production ownership — on-call, incidents, debugging under pressure, and a design you changed because production proved an assumption wrong.
• Webhook-heavy external integrations — telephony, messaging, or notification infrastructure; you've experienced the edge cases of asynchronous third-party systems.
• AI tool interfaces — capabilities AI systems can call reliably: granularity, deterministic behaviour, recoverable errors, authorization boundaries. Deep MCP experience is not required; the principles underneath it are.
Strong signals
You hear “privileged access bypasses row-level security” and immediately ask what enforces tenant scoping. You think about idempotency before anyone reminds you. You know a webhook arriving doesn't mean the event happened exactly once. You review AI-generated code as untrusted until it earns evidence. When you find a bug, you ask what allowed the whole class to exist.
This may not be a fit if
✕ You want to replace the system before understanding it.
✕ You need detailed specs before you can start solving a problem.
✕ You treat API design as CRUD scaffolding around tables.
✕ You've never had to reason seriously about tenant isolation.
✕ You want architecture, security, reliability, and backend split across separate teams — here they're one job.
✕ You're primarily looking for a management role.
HOW WE WORK
A small team with clear ownership and few meetings
• Daily — one 15-minute standup; a short written end-of-day update so context survives time zones.
• Weekly — Friday is working software demonstrated, not described. No standing meetings without a purpose.
• Review — the two senior engineers review each other's meaningful changes; no routine self-merges. Human review is backed by automated tests, CI safeguards, and rollout controls, with proportionally higher scrutiny on auth, tenancy, billing, and destructive paths.
• Decisions — the founder owns product priorities and commercial constraints; the engineers own architecture, standards, and technical trade-offs. Cross-domain deadlocks are settled by the founder as product decisions, documented once, not relitigated.
• Operations — engineers operate what they build, with an on-call model sized for a small team and deliberate cross-training so no one becomes a single point of failure.
HIRING PROCESS
An interview based on real work
No algorithm puzzles, no whiteboard Twitter designs:
1. Intro conversation (30 min). Mutual fit. Ask difficult questions.
2. Real code review (60 min). A representative pull request from the actual codebase. Much of the platform was AI-assisted; reviewing such code critically is part of the job, so we test it directly.
3. Architecture deep dive (60 min). A decision the product genuinely faced — real constraints, real trade-offs, incomplete information.
4. References. Focused conversations, conducted directly by the founder.
5. Paid final working exercise. Short, real, and structured so currently-employed candidates can participate. It evaluates how we work together — not how much unpaid work can be extracted.
To apply: send your profile to Info@smbaihub.com & raoof@canadiansme.ca— skip the cover letter.
Tell us two things: the production system you've shipped that you're most proud of and what you personally owned, and the production incident that taught you the most and what you changed afterward.
Those two stories tell us more than any paragraph about passion for scalable systems.
Click on Apply to know more.
