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:

- Intro conversation (30 min). Mutual fit. Ask difficult questions.
- 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.
- Architecture deep dive (60 min). A decision the product genuinely faced — real constraints, real trade-offs, incomplete information.
- References. Focused conversations, conducted directly by the founder.
- 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 [email protected] & [email protected]— 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.

📌 Senior Engineer — Platform & API (Hyderabad)
🏢 CanadianSME Small Business Magazine
📍 Hyderabad