It’s your mother’s birthday and your siblings are planning something extra special for her this year. Affording that dream present might mean splitting the bill, whether you’re sending funds across the couch or around the world. No matter how far your money has to move, all you have to do is unlock your phone. And in just a few taps, you can help your family secure a thoughtful gift, almost instantly. So instantly, in fact, it’s easy to miss the technical complexity behind every step of your transaction, from the encryption protecting your financial information to the APIs connecting your bank account to your payment app.

Electronic payments made through passwords and touch IDs are now commonplace, but these transactions used to be much more difficult. Remember when verifying your banking information meant entering your routing and account numbers, watching your checking account for small deposits and withdrawals, and then typing the amounts into a site? Now, watching $0.01 enter and exit your bank account is becoming a quirk of recent history—and you have Plaid to thank for that. Plaid’s API provides a simpler way to confirm account ownership in just a few clicks. It’s made this process so convenient, it’s become a linchpin of the most popular payment apps, brokerages, and more.

Behind Plaid’s increasingly popular technology is a staff of more than 500—including over 200 developers—with engineering offices in San Francisco, New York, Salt Lake City, Amsterdam and remote. The Developer Efficiency team, led by Engineering Manager Jeeyoung Kim, is responsible for helping developers work smoothly, no matter where they’re based and connecting them to efficient, dependable internal tools. Kim describes his team’s role as rooted in developer happiness: “We want to make sure Plaid engineers are happy and that their tools aren’t getting in their way.”

Plaid started as a single API that allowed developers to get access to consumer-permissioned account and routing information. But it’s expanded to include more data types and more intelligent logic, like machine learning and fraud detection models. Through these changes, GitHub has been a consistent platform for development.

“The UI is polished, and everyone is accustomed to it,” Kim explains, “So when we want to add additional functionality to the development workflow, it’s much better to build on top of GitHub’s interface rather than rolling out our own version.”

Plaid has used GitHub since its launch in 2013, and it’s still the foundation of their development lifecycle. “GitHub has been vital to Plaid engineering ever since day one,” he says. The company’s first repositories were hosted on GitHub.com, but their unique security needs required them to run much of their software on a VPN. “We self-host as many tools as we can,” he explains. Now they’ve migrated their code to a self-hosted instance of GitHub Enterprise to manage their own infrastructure while taking advantage of core flows, like pull requests.

Kim sees pull requests as much more than a vehicle for change. They allow developers to structure their thoughts, and add narrative and context to a new feature or bug fix. “A pull request is a solution,” says Kim. “It allows developers to gain more comprehensive context. And makes them less likely to accidentally introduce bugs in unrelated systems.”

Pull requests are increasingly the language that Plaid engineers use throughout their work. Using GitHub as a base, Plaid developers build engineering workflows with software that accelerates and automates every step of their development cycle—from pairing the platform with Jenkins to experimenting with GitHub Actions. To make and manage production changes, they use Atlantis, an application for automating Terraform via pull requests. So if developers want to create an additional database, new services, or a new set of load balancers, these changes are propagated through Atlantis to Terraform.

Atlantis is integrated as a GitHub Webhook server. “You just leave comments on your pull request,” says Kim. The comment “Atlantis plans” previews the changes it plans to make. And If you’re happy with the plan it generates, “Atlantis apply” makes the changes on production.

Kim’s team has also built on GitHub’s code owners feature with custom logic that streamlines their review process. They built a GitHub webhook receiver for tagging people who should be notified about a given pull request, allowing them to loop in reviewers without blocking the process. And because the team has their own GitHub webhook receiver, they can automatically notify Slack users when a pull request that’s eligible to be merged passes or fails.

Integrating with Slack helps developers stay in the flow, and keeps team members who aren’t on GitHub in touch with product developments. “Bringing GitHub updates into Slack gives developers another option and increases the responsiveness and the usability of our system,” notes Kim, “By keeping developers tuned in, it helps everyone work faster.”

The team also leverages canary releases to make deployments more efficient. Whenever they deploy, they deploy a pre-merged commit to a Canary environment, and allow very small amounts of traffic to flow against that environment before the pull request is fully merged. “Without having to go through a different environment, developers don’t need to wait for the entire CI/CD pipeline to kick in,” explains Kim. “You can see the change immediately, right from your pull request. This maximizes iteration speeds by reducing a workflow from hours to minutes. If developers want to make changes to code multiple times a day, they can complete a full day’s work within an hour.”

You can see the change immediately, right from your pull request. This maximizes iteration speeds by reducing a workflow from hours to minutes. If developers want to make changes to code multiple times a day, they can complete a full day’s work within an hour.

Kim feels the progress his team has made is thanks, in part, to the developer community outside of Plaid. Software companies around the world rely on open source. It’s no longer novel for open source software to make up a significant portion of a company’s stack, but more teams are taking the plunge into contributing back to existing projects and open sourcing their own code—Plaid included.

“We stand on the shoulders of giants,” says Kim as he elaborates on Plaid’s involvement in open source. He feels it’s important to give back to the community with things like upstream bug fixes but also sees additional benefits in releasing open source software. “First, it’s a branding exercise: you can increase the awareness of the company through open source projects,” he says. “And second: open sourcing work creates higher quality, more secure, better structured code. It forces you to separate out specialized business logic from the general purpose logic you plan to open source.”

The Developer Efficiency team advocates for open source principles applied to internal development through innersource. Nearly all of Plaid’s repositories—with the exception of sensitive repositories maintained by the security team—are open to every developer in the company. Kim sees the shared tools and knowledge that accompany more open development as key to keeping developers efficient and to creating a strong foundation for them to build on.

“For a long time, shared libraries were maintained by different teams,” he says. “They were created to solve a particular problem, not to spread knowledge.” This was causing governance issues in the long term. Teams that weren’t impacted by bugs and other issues weren’t incentivized to fix them. It’s now the team’s goal to inherit ownership of these shared components, and keep them up to date, dependable, and ready for all developers to use.

No matter how large a team is or how it’s structured, the importance of easy-to-access documentation can’t be overestimated. And for Plaid’s growing engineering organization, internal documentation is a top priority for the Developer Efficiency team. “Documentation is something we’re always revisiting and improving,” says Kim. Most recently, they are working towards unifying documentation from across Confluence, GitHub repositories, and Google Docs into a GitHub Pages site.

“We’re happy with the result, so far,” says Kim. “Publishing documentation with Jekyll to GitHub Pages uses a workflow that’s natural to developers and keeps documentation and code in the same repository. You can make a change to the code and modify its documentation at the same time.”

From knowledge management to innovative new toolchains, Plaid’s Developer Efficiency team is approaching faster workflows from as many angles as they can. They’ve proven that small improvements can ripple outward to the larger organization, a reminder that thoughtful tools are force multipliers for the entire company. As Kim puts it: “The more developers can accomplish, the more everyone can.”