There is a certain kind of software company that gets rich by solving a problem you did not know had a name. Trunk, founded in San Francisco in 2021, is one of them, and the problem is this: your continuous integration pipeline is red, and nobody is entirely sure why, and the fix that everyone quietly uses is to click "re-run" until it turns green. This is not a rigorous engineering practice. It is closer to a superstition. Trunk's pitch is that the superstition is expensive, measurable, and fixable, and that a great many engineering organizations will pay to make it go away.
The company was started by a group of engineers with the kind of resume that makes venture capitalists reach for their checkbooks - alumni of Uber, Google, Amazon, and Microsoft. The chief executive, Eli Schleifer, previously ran a startup called Directr that Google acquired, and worked on YouTube before that. The founding thesis was unglamorous: developers spend enormous amounts of time on what the industry calls the "outer loop" - not writing code, which is the fun part, but getting written code reviewed, tested, merged, and shipped without breaking everything for everyone else. The tools for the fun part are excellent. The tools for the outer loop, Trunk argued, were terrible.
Two bottlenecks, one green light
Trunk's flagship products attack two specific failures. The first is the flaky test - a test that passes sometimes and fails other times without any change to the underlying code. Flaky tests are the software equivalent of a smoke detector that goes off when you make toast. Eventually people stop trusting it, which is worse than not having it at all, because now a real failure and a false one look identical. Trunk Flaky Tests watches your test suite across CI runs, identifies which tests are behaving non-deterministically, and automatically quarantines them - pulling them out of the blocking path so a false alarm stops holding up an otherwise-shippable change. It works across essentially any language, test runner, or CI provider, which matters, because the whole point is that you should not have to rewrite your test suite to find out which parts of it are lying to you.
The second product is the merge queue, and here the argument gets more interesting. A merge queue is infrastructure that serializes the act of merging code: instead of ten engineers all merging their pull requests into the main branch and hoping the combination works, the queue takes them one at a time, tests each against the current state of main, and only lets it land if the tests pass. This solves a genuinely nasty problem - the logical merge conflict, where two pull requests are each perfectly green on their own branch but break the moment they are combined. Your unit tests never see it coming, because they never tested the combination.
The trouble with the naive version of a merge queue is that it is slow. If you test every pull request against every one ahead of it, one at a time, a busy repository can develop a merge queue longer than the line at a Bay Area brunch spot. Trunk's answer is to parallelize. Its merge queue batches pull requests - up to 100 in a single CI run - and tests non-overlapping changes simultaneously, so a front-end pull request is not stuck waiting behind an unrelated back-end test. When a batch fails, it does not throw out all 100 changes; it bisects to find the one that actually broke, and lets the rest through. The company says this can cut CI compute costs by up to 90 percent, which is the sort of number that gets a platform engineering team's attention, because CI compute is a real line on a real budget.
If your 10-person team is running agents, you probably need a merge queue already.
The AI angle, minus the hype
Now, every software company in 2026 has an AI story, and most of them are tedious. Trunk's is actually load-bearing, which is refreshing. The observation is simple: AI coding assistants are very good at generating pull requests, and generating them quickly, and in large volume. What they are not good at is the outer loop. An AI agent can open twenty pull requests in an afternoon. It cannot make your merge queue faster, or make your flaky tests reliable, or resolve the logical conflict when eight of those twenty pull requests touch overlapping code. So the more code AI writes, the more the bottleneck shifts downstream - from authorship, which is getting cheaper by the month, to integration, which is not. Trunk is a bet that the value migrates to wherever the constraint sits, and that the constraint is moving squarely into Trunk's territory.
This is why Schleifer makes the slightly provocative claim that a ten-person team running AI agents may already need infrastructure that used to be reserved for companies with hundreds of engineers. It is a self-serving argument, obviously - he sells the merge queue. But it is not wrong. The economics of software delivery are being rearranged, and the rearrangement happens to point at the exact problems Trunk was founded to solve, a year or two before the industry noticed.
Who is actually paying
The proof, as always, is in the customer list. Trunk's tools are used by engineering teams at Brex, Faire, Zillow, Gusto, Cockroach Labs, Retool, and BetterUp, among others - companies that ship a lot of code and feel the pain of the outer loop acutely. One customer, the accounting-software firm Caseware, reported cutting its median merge time from six hours to ninety minutes using Trunk's intelligent batching, processing four to eight pull requests per batch with, in the company's telling, zero manual intervention. Six hours to ninety minutes is not a rounding error. It is the difference between shipping twice a day and shipping once, and for a team that lives or dies by iteration speed, that is the whole game.
Trunk's business model is the familiar developer-tools playbook: a free tier and an open-source command-line meta-linter at the top of the funnel, paid subscriptions for the merge queue, flaky-test management, and analytics underneath, and enterprise plans - SOC 2 compliant - for the larger organizations. The company employs roughly 63 people and operates as a hybrid-remote outfit with an office at 14 Mint Plaza in San Francisco. Its stated culture rests on three tenets that read exactly as you would expect from a company of ex-big-tech engineers who left to build for people like themselves: take initiative, enjoy autonomy, practice empathy. The empathy part is the one worth taking seriously - it is developers building for developers, which in this category is less a slogan than a competitive moat. It is very hard to build good tools for a workflow you have never personally hated.
The money and the competition
On the funding side, Trunk raised a $3.5 million seed round in 2021 - notably with GitHub co-founder Tom Preston-Werner among the angels, which is a nice endorsement given that GitHub is both a partner and, with its own native merge queue, a competitor. In April 2022 the company raised a $25 million Series A led by Initialized Capital, with Andreessen Horowitz participating, bringing total funding to roughly $28.5 million. The competitive field is real: GitHub's built-in merge queue, plus Mergify, Aviator, and Graphite on the merge side, and the likes of BuildPulse, Datadog, and CircleCI's test insights on the flaky-test side. Trunk's wager is that doing both - and doing the parallelization and cross-provider flake detection better than the incumbents - is a durable position rather than a feature that a larger platform eventually absorbs.
That is the open question hanging over any focused developer-tools company: is this a product or a feature? GitHub could, in principle, make its native merge queue much better. But it has not, so far, and the gap between "in principle" and "in the product roadmap" is where companies like Trunk live. The bet is that CI reliability is deep and thorny enough - flaky tests alone are a genuinely hard distributed-systems problem - that a specialist can stay ahead of the generalist. It is the same bet Datadog made against cloud-provider monitoring, and that one worked out fine.
The linter that started it all
It is worth noting where Trunk began, because it explains the company's instincts. Before the merge queue, before the flaky-test detector, Trunk's first product was a humble command-line meta-linter - a single tool that pooled together dozens of existing open-source code checkers and formatters so that developers did not have to individually install, configure, and babysit each one. That does not sound like a venture-scale idea, and on its own it is not. But it taught the company something useful about its customers, which is that engineers will tolerate almost any amount of complexity in their own code and almost none in their tooling. The moment a tool becomes annoying, it gets disabled, worked around, or quietly ignored - which is precisely what happens to a flaky test suite or a slow merge queue. The meta-linter was a small product that revealed a large pattern: the friction in software delivery is death by a thousand small annoyances, each individually ignorable and collectively enormous.
From there the trajectory makes sense. Each subsequent product moved further down the pipeline and further up the stakes - from formatting your code, to trusting your tests, to safely landing your changes on the branch everyone depends on. It is a company that has been walking, deliberately, toward the most consequential and least glamorous part of the software lifecycle, on the theory that consequential-and-unglamorous is exactly where an incumbent's attention runs thin and a specialist's obsession pays off.
What Trunk is really selling, in the end, is trust in a green checkmark. When your CI passes, you should be able to believe it, and when it fails, you should be able to believe that too. For an industry that has quietly normalized "just hit re-run," restoring that belief turns out to be worth quite a lot of money - and possibly more of it every month that AI writes another pull request nobody has time to babysit through the queue.