You're the technical 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.

The Role

This is a product engineering role. Its center 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. 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, you want a team to manage, you like tasks that arrive well-defined, or you'd be frustrated building against platforms that change without notice.

What You'll Actually Do Day-to-Day

• 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 work you repeat into internal tools and checks the whole team uses.

• Run experiments: change one thing, then measure (Datadog for production behavior, Mixpanel for user behavior), 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.

Required Experience

• 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, 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 modeling: 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.

Useful but Not Required

• Real-time or distributed systems at scale.

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

How We Work

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 behavior are first-class product requirements, designed in from the start.

What Success Looks Like

• 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.

Why Join Tactiq

• 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 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.

How We Hire

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.

To Apply

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?