Senior Backend Engineer

You will own how our systems communicate.

Onix is building Personal Intelligence: AI that runs on your device, belongs to you, and connects you with real human expertise. Small team. We ship daily. Building the infrastructure to scale to millions without surveillance architecture.

We have mobile apps, a web app, an admin panel, and a backend engine. They need to talk to each other. Someone needs to own how.

You’re that person.

This isn’t DevOps. We have that. This is the person who owns the database and everything above it: schema design, query performance, migrations, event queues, real-time sync, service contracts. The full backend picture.

When the team is deep in product, you’re the one who says “we need to talk about this before you ship.”

What You’ll Own

Service communication architecture. You define how our clients and services communicate as we scale. When to use real-time subscriptions vs. polling. Where message queues make sense. How state changes propagate. The contracts between systems.

The data layer decisions. Not the administration, the architecture. Schema patterns that survive 100x growth. Migration strategies that don’t break production. The hard opinion on when denormalization is right and when it’s lazy.

Backend performance at scale. Query optimization. Connection pooling. Caching strategy. You instrument, you measure, you fix before it’s a fire.

The technical roadmap. You own the path from where we are to where we need to be. Not just the spec, the shipped code that sets the pattern.

What You’ll Do in the First 90 Days

• Audit the architecture. Tell us the decisions that will hurt at scale.
• Define the contracts between backend and clients.
• Ship code that sets the pattern. Not just diagrams.
• Be the person the team asks “how should I build this?” for anything backend.

You Should Be

Someone who’s seen what happens when backend architecture isn’t owned. You’ve cleaned up that mess. You’ve debugged the cascade failure at 3am because nobody thought about how services would talk at scale. You don’t want to do it again.

Deep on PostgreSQL. But also deep on the layer above it: queues, caching, real-time sync, edge compute.

Opinionated. You have strong views on when to use websockets vs. SSE vs. polling. On schema design tradeoffs. On why that migration is going to hurt. You’ll argue with founders about architecture, and you’ll be right often enough that we listen.

A builder who ships. Not an architect who diagrams. You’ll write the first implementation of the patterns you design. Your code becomes the reference for the team.

Autonomous. You’ll find the problems before they find us. You’ll audit our schema without being asked. You’ll flag the migration that smells wrong before it ships.

This Role is NOT For You If:

• You want to be a specialist who only touches the database
• You prefer process and alignment over speed and judgment
• You need a large team to feel supported
• You see architecture as diagrams, not shipped code
• You’re optimizing for title, not ownership
• You’re not willing to be in Montreal (we’ll relocate you, but this is an in-person team)

Why This and Not Google/Shopify/Meta

You won’t get this at a big company:

• You make the calls. Not implement someone else’s architecture decisions.
• Small senior team. No politics. No process theater. No waiting for approval.
• The problem is genuinely interesting: privacy-preserving AI, edge-first, real-time expert matching.
• The mission is real. We’re not pretending to change the world while optimizing ad clicks.

How to Apply

Submit your application and include:

1. One architectural decision you made that you’re proud of. What was the context, what did you decide, what happened.
2. One you got wrong. Same format.
3. Your take on direct database access vs. API layers. When does each make sense?

Skip the cover letter. We’d rather see how you think.