Staff Software Engineer, Browser Extension & Persistence

You're the owner of Tactiq's capture and persistence reliability domain: the extension-to-backend contract, the transcript durability model, observability, rollout safety, and the engineering mechanisms that keep capture reliable as meeting platforms change.

This role lives in the browser and the meeting platforms, and a lot of it is investigative. Its centre of gravity is the browser extension and the capture path across Google Meet, Zoom, and Teams, but it spans the extension-to-backend API and the persistence path through durable storage. Most systems you will work with don't document how they really behave, so you work it out from evidence and build capture mechanisms that survive their changes. You own that domain end-to-end, and the reliability bar you set here is inherited across the product. Tactiq is growing fast, and so is the set of problems where the right answer isn't obvious in our context yet.

You own the how (the technical approach and execution) outright; you shape the what (priorities and scope) with product; and review, automated and human, is a quality gate that catches defects, not an approval gate on your calls.

This role is for you if you like making a critical, already-in-production system more reliable and faster, want to own a domain end-to-end, and expect to grow your remit from it into more product areas over time.

It's probably not if you're after greenfield, want a team to manage, like tasks that arrive well-defined, or would be frustrated building against platforms that change without notice.

• Frame the problem: clarify ambiguous product and system problems with product: the user or system failure, the success metric, and the smallest reversible path to learn.

• Design and ship: the extension and capture pipeline across Meet, Zoom, and Teams, and the save path that gets each transcript into storage. Done means rolled out and observable, and either moving the metric or clearly reverted, not just merged.

• Build the tooling: turn repetitive work into internal tools and checks that the whole team uses.

• Run experiments: change one thing, then measure (Datadog for production behaviour, Mixpanel for user behaviour), and revert or iterate.

• Raise the bar: review designs and code, mentor engineers, and reduce single-person dependencies.

• Reliability: a dropped capture is a meeting a user never gets back, so you own reliability by design for this domain: SLOs, prevention, and durability.

• Deep experience owning user-facing systems end to end, ideally a browser extension (MV3) or a comparable constrained client: service workers, cross-context messaging, permissions, WebRTC, and the failure modes that only show up in the field.

• Strong TypeScript/Node, or the ability to ramp fast in a TypeScript-heavy codebase.

• System design across APIs, data flows, reliability, and observability. You don't need equal depth across browsers, backend, and infrastructure, but you reason across the boundaries and go deep where a project needs it.

• Sound judgment on durable storage and data modelling: you design persistence that stays correct and fast as data grows. We use Firestore; the judgment matters more than the specific store.

• Product judgment: connecting technical work to activation, retention, quality, cost, or reliability, and using telemetry and product metrics to guide iteration.

• Real-time or distributed systems at scale.

• Native desktop experience, macOS or Windows (an adjacent capture surface).

Under the hood: a TypeScript monorepo — Node.js/GraphQL backend with Temporal, Firebase, Elasticsearch, a React web app, a Chromium extension, and a native macOS app. You don't need prior experience with every part of the stack, but you should be comfortable becoming productive in a TypeScript-heavy system. We ship in small, reversible slices, often many times a day; bigger bets land as stacked PRs, not one big drop. CI runs codegen, linting, layered tests, and AI-assisted review checks for general, security, and performance issues; human review stays responsible for engineering judgment. Datadog watches production. SRE owns the pager and incident coordination, so there's no standing pager rotation for you; when something you own breaks, you help diagnose and remediate, and you own the engineering follow-ups from the postmortem.

We handle sensitive meeting data, so privacy, permissions, access control, retention, and safe AI behaviour are first-class product requirements, designed in from the start.

• In your first month: you get deep enough on the product, stack, and observability to ship small improvements safely, and you agree a target metric with the team: say capture success rate, lost-transcript rate, p95 save latency, or capture-related support volume.

• In your first three months: you lead one ambiguous problem from framing to production rollout, including instrumentation and iteration.

• In your first six months: you've moved that metric materially or removed a known source of capture risk.

• Timing: AI meeting intelligence is a category still being defined, and we're one of the ones defining it.

• Scale: a business that works, aimed at the next milestone of $100M ARR, with a PLG motion that grows itself reinforced with PLS and a lot still ahead.

• Leverage: a small, AI-enabled team, so one engineer's work goes a long way.

• Equity & impact: your work is visible, and you have equity in what you build.

• Flexibility: autonomy-first and flexible about how you work, with at least a half-day overlap with Sydney time (you're first-line for your own regressions).

• Modern tooling: Linear, Mixpanel, Datadog, Claude Code, Cursor, and whatever else earns its place.

A first conversation; a one-hour paired session on our real codebase, AI tools welcome (not a whiteboard puzzle); a one-hour deep dive on system design and past work; and a conversation with the founders. We aim to go from first call to offer in about two weeks, and keep the process useful on both sides.

If you don't tick every box but think you're a strong fit, apply anyway - we'd rather meet you and figure it out.

Send us at engineering2026 at tactiq io a brief note (1-2 sentences each) covering:

1. Why Tactiq?

2. Describe the last feature you built or significantly improved. What was your approach?

3. What was the result of that change?