Empowering innovation at Opto: how we let everyone safely contribute code

At Opto, we believe great ideas can come from anywhere, not just from engineers. Whether you’re in product, design, finance, or marketing, if you’ve got a spark and want to ship something, you should be able to open a pull request (PR) and get it out into the world.

But moving fast shouldn’t mean breaking production. That’s why we built a GitHub App + AWS Lambda integration, a lightweight safeguard that ensures every change gets a proper review and approval from our engineering team before it merges, without turning collaboration into chaos.

Why we built this

We encourage everyone at Opto to jump into the codebase, dashboards, analytics scripts, prototypes, or even the UI. But as we opened the doors wider, we faced a familiar tension:

“How do we keep our quality bar high while letting everyone contribute freely?”

CODEOWNERS looked like the obvious fix, until it wasn’t.

GitHub’s built-in solution for enforcing reviews is the CODEOWNERS file. In theory, it’s great: you list which teams own which parts of the codebase, and GitHub automatically requests their review whenever a pull request touches those files.

But when we tried adding the entire Engineering team as a CODEOWNER, things got noisy, fast. Every single PR triggered a review request (and an email) to every engineer in the org. Everyone’s inbox and GitHub notifications were flooded with PRs they had no context for.

Instead of surfacing important reviews, it buried them. People stopped paying attention to the notifications altogether, because they couldn’t tell which ones actually needed their input. The result: CODEOWNERS technically enforced reviews, but in practice, it diluted accountability and made collaboration harder, not easier.

So instead of duct-taping our way forward, we built something new.

The Solution: a single source of approval truth

Our internal “PR Approval Check” GitHub App runs on AWS Lambda. It listens to PRs and review events, then verifies that at least one engineer from the Engineering team has approved before merge. The Engineering team is defined using GitHub’s built-in Teams functionality, a dedicated group that includes only the appropriate members.

It’s install-once, enforce-everywhere:

  • No repo-level configuration
  • No manual workflow management
  • No inbox explosions The result?

A calm, clear check in every pull request UI that says whether your change is ready to ship. You still move fast, but you know an accountable engineer has your back.

awaiting pull request approval

How it works

Here’s the simplified architecture:

GitHub Webhook → AWS Lambda → GitHub Checks API

The Lambda validates incoming webhook signatures, checks for approvals from the engineering team, and updates the pull request status in real time. It also handles edge cases, like dismissed reviews or “changes requested”, so that approvals always reflect the current state of the conversation.

Because it’s serverless, there’s no infrastructure to maintain. It scales automatically across every repo in which it’s installed, and can be enforced organization-wide with a single rule.

approved pull request

Why this matters

Opto’s culture is built on the idea that innovation isn’t confined to a job title. When anyone can suggest, build, or ship an improvement, the whole company moves faster and feels more connected to the product we’re building together.

This workflow is our way of safely saying yes to that creativity. Engineers stay focused on the meaningful reviews, non-engineers get empowered to contribute, and production stays stable.

At Opto, innovation isn’t gated, it’s guided. That’s how we move fast, learn fast, and build together.

For disclaimers, visit https://www.optoinvest.com/disclaimers.