Staff Software Engineer — Integrations Platform

Fixify's Integrations Platform is both the framework and the ecosystem: the patterns, SDK, and abstractions our team builds, plus the integrations themselves that run on top of it across customer ticketing, identity, knowledge, and endpoint systems. We are heading toward hundreds of integrations authored by our team today, by FDEs and contractors against the SDK tomorrow, and by AI agents soon after. We have reached the point where the shape of the platform underneath all of that matters more than any single integration. Someone needs to own that shape across quarters, not weeks.

When you have built enough integrations to see the platform-shaped gaps, do you also have the patience to design the framework other engineers will use to fill them?

At Fixify, every integration starts as a small failure somebody is feeling. A password reset that did not go through before a meeting. A Jira ticket that landed in the wrong queue. An access request that has been pending since Tuesday. The integrations we build are invisible when they work and impossible to ignore when they do not. At the scale we are heading toward, with FDEs, contractors, and AI agents all authoring on top of the platform, the only way to keep them invisible is to design the platform underneath with real care. That design work spans quarters. It is the work this role exists for.

As a Staff Software Engineer on the Integrations Platform team, you would own the multi-quarter shape of the platform. You would set the integration strategy as a continuous workstream (taxonomy, prioritization, risk tiering, vendor partner relations). You would drive the architectural direction for non-API integration patterns where standard API-and-poll falls short: browser-driven flows, webhook-first designs, and iPaaS bridges like Okta Workflows and Tines. You would design the authoring framework that lets FDEs, contractors, and AI agents extend the platform safely (skill SDK, risk tier enforcement, sandbox environments, doc generator, CI gates). You would design the integration testing infrastructure that takes the team past tribal, per-integration fixtures. And you would do all of this as a multiplier for the team, not as a portfolio of solo wins.

This is a coaching role as much as a building role. You would pair on hard design decisions before they ship. You would run design reviews as a teaching forum. You would share the strategic and surge escalation surface with the engineering manager so the team executes predictably, and you would take your regular turn in the maintenance rotation like everyone else. The point of this hire is to make the next architecture decision easier for the rest of the team, not to become the person every decision routes through.

What we can do for you

• Hand you the architectural canvas for a platform that is mid-build, with the destination already meaningful (hundreds of integrations, agent authoring on top) and the room to shape how we get there.
• Pair you with a Chief Architect who is genuinely engaged on the integrations problem, and a small senior team who will push back on you the way you should push back on them.
• Connect you directly to the customers and analysts on the other end of your platform decisions, so the architecture is grounded in real user reality rather than abstract elegance.
• Trust your judgment on multi-quarter calls. We expect you to make them, document them, and revisit them when context changes.
• Give you the space to coach. This is part of the week, not a side activity.
• Share the strategic and surge escalation load so it is not a single funnel.

What you can do for us

• Own the integrations strategy as a workstream rather than a series of decisions made under pressure.
• Drive architectural decisions across multiple quarters and multiple integrations, including the trade-offs between extracting shared abstractions now versus carrying duplication for a defined period.
• Design the authoring framework that lets FDEs, contractors, and AI agents extend the platform safely, treating that authoring surface as a first-class platform problem.
• Coach the team through pairing on hard design decisions before they ship and running design reviews as a teaching forum.
• Share the escalation and surge surface, take your turn in the maintenance rotation, and treat operability as part of platform design rather than a follow-up task.
• Read CS threads, POPs escalations, and customer-facing reality as input to the strategy, not as interruptions.
• Frame staff-shaped projects so other engineers on the team can take meaningful pieces. Treat platform work as a multiplier rather than a personal portfolio.

What you should bring with you

• A track record of leading multi-quarter platform or integrations work, including architectural ownership across more than one product surface.
• Demonstrated experience designing SDKs, authoring frameworks, or systems that let other engineers, partners, or external authors extend a product safely.
• At least 8 years of experience building scalable, observable SaaS systems.
• Deep fluency in TypeScript and Node.js, and with AWS primitives (Lambda, SQS, S3), the kind of fluency that shows up in architectural trade-offs rather than only in syntax.
• Hands-on experience with non-API integration patterns: webhooks at scale, OAuth flows across many tenants, and at least one of browser-driven automation, iPaaS bridges (Okta Workflows, Tines, Workato), or callback-based designs.
• A documented architectural decision you are proud of, and another one you would do differently with a year of hindsight.
• A reviewer's instinct that is teaching-shaped rather than gatekeeping-shaped.
• Fluency with AI coding tools (Cursor, Claude Code, or equivalent) and a real point of view on how platforms should be designed when AI agents are part of the author base.
• The confidence to say "I do not know yet, here is how I would find out", especially in your first ninety days on this team.
• If you are looking for a role where you can ship big things solo and become the person every decision routes through, this is not it. The point of this hire is to multiply the team, not to centralise the architecture. Strong opinions are welcome after you have earned the context, not on day one.