Gearset wants to end the Salesforce release-night shift

The software was supposed to make work easier. The release process had other ideas. At McKesson’s Medical-Surgical group, preparing or deploying Salesforce changes could take six to twelve hours apiece. Developers and administrators were overwriting one another’s work. A home-built mix of tools had become another thing to manage. Eventually, there had been enough late nights.

That is the territory Gearset chose: the gap between making a useful change in Salesforce and getting it safely into the system people actually use. It is a less photogenic problem than inventing a new customer app. It also returns with every release. Gearset sells the machinery for comparing, checking, moving and recovering those changes, giving mixed teams a shared process.

Now the company wants a hand in making the changes themselves. In September 2026, Gearset launched Cam, an AI agent that takes on Salesforce tickets and feeds its work into a governed delivery process. The ambition has expanded from helping people ship their work to supplying some of that work. The release-night headache remains the organizing idea.

A small change with a long passenger list

Salesforce is a customer-management platform that businesses can adapt extensively. Those adaptations include code, fields, permissions and visual automations called Flows. Much of this structure is described by metadata: instructions about how the system behaves. A change may therefore depend on several other pieces being present and correctly configured. Moving the obvious component is only part of the job.

Gearset’s comparison tools show differences between environments and source control. Its deployment workflow helps teams assemble changes and identify dependencies before moving them. Pipelines adds a visual route through development, testing and production, with automated checks along the way. An administrator making changes through clicks can participate alongside an engineer working in Git. That shared route is central to the product’s appeal.

The company occupies a specialized layer of enterprise software. It does not replace Salesforce or run a customer’s sales department. Its users are the people responsible for keeping customized Salesforce systems useful: administrators, developers, release managers and platform teams. Consultancies use it, too. Public customer names span IBM, Veolia, Sonos and Johnson & Johnson, illustrating how widely the same underlying maintenance problem travels.

Before the platform, nearly 100 phone calls

Kevin Boyle and Matt Dickens met at Redgate Software in Cambridge. When Redgate adopted Salesforce, engineers accustomed to automated releases found themselves wrestling with manual deployment work. The prospective founders did something sensible before assuming their irritation was a market: they spoke to nearly 100 Salesforce developers and administrators. Other teams recognized the problem.

Gearset dates its founding to 2015. Its anniversary history supplies a second milestone: seven founding team members left Redgate in February 2017, with the company’s blessing. Prototypes, customer conversations and a trip to Dreamforce had helped validate the idea. This was an enterprise software company whose early research involved asking people about chores.

Even the name carries a small engineering joke. A gearset transfers force; Salesforce developers then talked about the Force.com platform. The name connected the physical mechanism to moving code and configuration between environments. An available domain helped. The origin is appropriately practical for a business built around work that customers would prefer to finish before dinner.

What persuaded the people doing the releases

McKesson’s account gives the sales pitch a concrete shape. Its team initially used first-party tools, then combined in-org development, change sets and the Force.com migration tool. Complexity and overwritten work pushed the team toward a third-party product. Gearset’s comparisons reduced reliance on manually tracking every change; automation made more frequent releases practical.

“My life has definitely gotten easier!”

Matt Avitable, DevOps Architect at McKesson, in Gearset’s customer story

A later walkthrough by McKesson developer Monica Thornton Hill explains the mechanics. Declarative changes move automatically from staging to production every four hours. Code changes follow a Friday compare-and-deploy routine. That distinction matters: automation did not require every type of work to travel on an identical timetable. The team adapted the process to the work.

The useful lesson is about workflow design. Compare actual environments, make the contents of a release visible and choose a cadence for different changes. A buyer can copy those practices while evaluating software. The customer account describes one team’s experience, however; it is not a controlled benchmark or a promise that every deployment will shrink by the same amount.

The bill has more than one unit

Gearset sells subscriptions, with different meters for different jobs. Its pricing guide, checked September 7, 2026, lists Starter deployment access at $215 per Gearset user per month and Teams at $320. Automation starts at $550 per team per month. Backup starts at $2.75 per Salesforce user per month, subject to a $275 monthly minimum. Enterprise packages and several newer products require a quote.

For illustration, five Starter deployment seats plus Starter automation total $1,625 a month at those published rates, before taxes or other modules. That calculation is a narrow configuration, not a complete enterprise quote. Add backup or specialist deployment products and the bill changes. Counting only the people who click the deployment button will not necessarily capture the whole subscription.

The sensible comparison includes time as well as license fees. How many people prepare each release? Who repairs failures? Who maintains the scripts? Gearset includes onboarding and support and offers a 30-day trial. A team with occasional, uncomplicated releases may find less value in a paid platform than a team repeatedly spending evenings untangling dependencies.

A deployment is only the middle of the story

The product expansion follows what happens on either side of a release. Gearset acquired Salesforce code-analysis company Clayton in September 2024, adding security and quality capabilities now offered through Code Reviews. Detecting a problematic pattern before deployment gives a release team an earlier opportunity to act. The acquisition also made Gearset responsible for more of the customer’s development process.

Automated Testing addresses another awkward distinction: a change can deploy successfully while a user journey still fails. The product supports tests created through natural language or recorded browser interactions, including tests using different roles and permissions. A process that works for an administrator may behave differently for a colleague with limited access. Checking that experience belongs before the release becomes everybody’s problem.

Sandbox seeding supplies related records for development and testing, with masking for sensitive data. Backup and restore provides a way back after loss or unwanted changes, while archiving moves older records off-platform. These are different jobs. A realistic test environment helps before a release; a usable recovery process matters after something goes wrong.

Observability, introduced in 2025, watches production errors and limits. Org Intelligence helps explain metadata relationships. Together, the additions reveal the commercial logic: once Gearset understands how an environment is put together, it can use that knowledge in more places. Customers get connected tools; Gearset gets more opportunities to sell within an existing account.

More customers, more of each customer’s work

In June 2022, Gearset announced its first outside investment: $55 million led by Silversmith Capital Partners. The business already served more than 1,700 companies. The stated uses included expanding products, sales and marketing, and the team in Britain and the United States. Boyle emphasized finding a partner who shared his preference for a business built to last.

The later figures suggest expansion inside accounts has become consequential. Gearset reported 37% revenue growth for 2025, more than 3,500 customers and net revenue retention above 110%. It also reported a 49% increase in new-product adoption among existing customers. Those are company figures, but they support a specific reading of the business: the sale increasingly concerns several connected activities.

Gearset competes with specialists such as Copado and Flosum, alongside Salesforce’s own DevOps Center and workflows assembled from Git, command-line tools and CI services. Its case rests on accessible comparisons, visual automation and a broad set of connected products. Integrations with GitHub, GitLab, Bitbucket and Azure DevOps let it fit existing engineering habits. Its Salesforce partnership and consultancy program help it reach teams implementing the platform.

Support is part of that positioning. Gearset says it handles support in-house through Cambridge and Chicago, connecting customers with people who understand the product. Its published culture emphasizes ownership and communication across teams. Those principles have a practical test: whether a customer with a blocked deployment can reach someone capable of helping.

Cam still has to get past the checks

Cam takes the platform into new territory. The agent plans and builds Salesforce changes, then submits them through the team’s delivery workflow. Gearset’s September launch announcement said selected pilot customers had Cam creating up to 44% of their teams’ pull requests. That is an upper-end pilot result, not an average, and a pull request is proposed work rather than proof of a successful production outcome.

The engineering argument is more interesting than the percentage. In February, Dickens described combining language models with deterministic analysis of Salesforce dependencies. An agent needs context about the system it is changing; a fluent answer alone cannot provide that. Existing release checks then offer a place to examine the resulting work before it reaches users.

For a team considering Gearset, a useful trial would follow an ordinary change through comparison, review, testing and recovery. Include both an administrator and a developer. Record the preparation time, manual interventions and surprises. If ownership is unclear, tests miss important behavior or nobody practices restoration, software alone will leave those gaps intact. The result to look for is wonderfully mundane: a useful Salesforce change delivered during working hours, with everyone comfortable going home.