Member of Technical Staff

ABOUT BEACON SOFTWARE Beacon http://www.beaconsoftware.com is acquiring and operating a portfolio of vertical SaaS companies. Most private equity firms scale by adding people. We are building Beacon to scale by adding software. The thesis is simple. Portfolio operations, value creation, and deal sourcing are bottlenecked by human attention, and the right software platform can lift that ceiling by an order of magnitude. We are building that platform. A cross-portfolio datalake on open table formats, with a feature store on top that makes the data usable by both people and software. An action layer that runs workflows across three domains: how we run the portfolio, how we grow the portfolio, and how we acquire into it. A feedback loop underneath that captures every action and outcome with stable identifiers. By the next phase of buildout we will have 100+ portfolio companies running on this platform. That is a problem set with serious data scale, real multi-tenant isolation requirements, and very few precedents to copy from. Beacon has raised $550M+ from investors including General Catalyst, Lightspeed, D1 Capital, CPMG, and the family offices of the founders of Stripe, DoorDash, and Ramp. ABOUT THE ROLE Members of Technical Staff (MTS) are the senior engineers who build the platform that everything else at Beacon runs on. You will own a piece of the core stack end-to-end: design, implementation, operations, and the long-term technical direction of that area. This is a Staff Engineer role in everything but name. We run flat. The work is systems engineering at its core. Multi-tenant data infrastructure across very different portcos. Event-driven pipelines that have to be correct under partial failure. Service architectures that have to stay simple as the product surface grows. APIs and SDKs that other engineers — including FDEs out in the field — will build on every day. ML and agentic systems are part of the stack. They sit on top of a foundation that has to be solid first. This is not infrastructure for its own sake. The platform has to be solid before anything else at Beacon works. That is the job. WHAT YOU'LL DO You will own one of these areas end-to-end: - Data platform. The cross-portco data lake on Iceberg with Snowflake or Databricks as the query engine. Per-portco S3 and KMS isolation. The ingestion pipeline from QuickBooks, HubSpot, Salesforce, PostHog, Intercom, Linear, Slack, Gmail, Postgres, Stripe, Zendesk, and our internal tools. The canonical data model that survives contact with very different portcos. The catalog and semantic layer on top so a query like "show me sales across all portcos" actually resolves. - Core services and APIs. The backend services that everything else at Beacon depends on: identity, access control, audit, workflow orchestration, the internal APIs that FDEs and ops engineers build against. The bar here is not novelty. It is correctness, latency, observability, and the kind of API design that ages well. - Multi-tenant isolation. Per-portco data, compute, and credential boundaries. Cross-cloud (AWS and Azure) connectivity. Regional residency for portcos in regulated verticals. This is the unglamorous infrastructure work that determines whether we can onboard portco 50 as fast as portco 5. - Workflow and action runtime. The execution layer that runs operational workflows across the three domains. Typed action surfaces, idempotency, retries, rollback paths, human-in-the-loop approval gates, audit trails. Some workflows are scripted. Some are model-driven. The runtime treats them as variations of the same primitive. - Observability and evals. The harness that tells us whether the system is working: traces, metrics, structured logs, replay infrastructure, regression suites, the ability to safely A/B-test changes across the portfolio. Both for traditional services and for model-driven workflows. - Safety and blast radius. Wrong actions against a portco's customers, revenue, or product are the wors