HubSpot is a marketing and sales platform with more than 15,000 customers in 90 countries—and it is growing fast.

In 2012, HubSpot decided to simplify their development process in a way that consolidated the tools they were using, worked at scale as their headcount increased, and fit the company’s security requirements. But according to Tech Lead Mike Champion, the decision to switch to GitHub Enterprise ultimately came from HubSpot developers.

After three years using GitHub Enterprise, it has become deeply and broadly ingrained in HubSpot’s product teams—encompassing more than 1,000 repositories and over 1,500 deployable components. Here is how their team uses GitHub to securely communicate, recruit, and build software in the way that works best for them.

A medium for conversation and feedback

Pull requests are a central forum for conversation among HubSpot’s product team. They’re one of the main ways we communicate about ideas, said Mike, GitHub has definitely become more than where we store code—it’s where we communicate about building software.

The conversation around HubSpot code is open and casual—often sprinkled with emoji—and rooted in the company’s feedback culture. Whether they are newly hired or have been around for years, HubSpot developers use GitHub to proactively seek out and receive feedback in informal channels. According to Mike, GitHub makes it easy for people to get feedback and comment on code across the company, no matter what project they are working on.

Support for how HubSpot works best

After three years on the platform, Mike considers GitHub deeply ingrained into how HubSpot builds software. Running on a model of customer feedback and continuous innovation, HubSpot engineers continuously deploy code—deploying to production up to 300 times a day—and use GitHub to support the way they work.

We build software through shipping many incremental changes, said Mike, the flow of creating pull requests and merging branches removes friction, helps us quickly push small changes, and get feedback from customers. HubSpot’s model allows for accelerated learning and iteration. The faster the team can push code to production, the faster they can get feedback and improve their product.

The option to open source

HubSpot has an active set of open source projects that they use to automate their development process and help developers write software without having to fully understand all levels of HubSpot’s tech stack. The biggest, most complex of their open source projects is Singularity.

A lot of us were already fans of GitHub. We care a lot about the tools we use every day. If we like a tool and it makes us happy and productive, we will want to invest in it.

A customizable platform

From webhooks that send information to HipChat to systems for notifying the team when a pull request is merged, HubSpot engineers have built custom tools using the GitHub API to keep communication effortless and their workflows more efficient.

More specifically, the team uses GitHub to automate how they internationalize their product for customers in more than 90 countries. Using GitHub API, they built an internal automation service called Babel to trigger a translation workflow when developers commit language changes in GitHub.

Babel and GitHub work seamlessly together, says Mike, We’ve saved a lot of time by simply automating this piece of the translation process. It lets us work quickly without having to wait on manual steps.

A tool to foster growth and culture

For years, HubSpot has focused on growth from both a hiring and a platform perspective. As the engineering team has grown in step, using tools that developers were already familiar with has proved crucial for recruiting and onboarding. Mike says, It makes it easier for developers to get started when they’ve used GitHub on their own time or at previous jobs, and I think they’re happy to see it.

GitHub has also become part of the team’s efforts to foster a collaborative culture that developers love. For Mike, Using GitHub is a sign of an environment in which people prioritize the tools that they enjoy. He explains, it’s part of a larger investment in developer happiness and in helping them focus on the challenging problems of building product, rather than on tools.