I evaluated Buildkite at a previous job, and I came to these conclusions.
1. Buildkite is probably the best commercial, off-the-shelf CI system right now, in terms of providing all the correct building blocks at the correct level of abstraction.
2. The impact of your CI system itself being good or bad is tiny in comparison to everything else in your end-to-end CI workflow. Far more important are your own CI scripts and what they run. A distant second is the observability tooling around your CI.
3. It's hard to justify the per-seat pricing of Buildkite, as a separate line item, when whatever CI offering your source control host bundles in will suffice.
maccard · 1h ago
> the impact of your CI system itself being good or bad is tiny in comparison to everything in your end to end CI workflow.
I disagree here. A bad CI system makes it very, very easy to make the end to end workflow incredibly painful. Some small QOL features (buildkites input step was probably the reason it stuck for so long with us) are the difference between a tool being indistinguishable from others and being leaps and bounds ahead.
> it’s hard to justify the per seat pricing of buildkite
Buildkites pricing starts at 50% more than GitHub enterprise does. I couldn’t justify it as someone who loves buildkite and is in charge of making those decisions.
RainyDayTmrw · 1h ago
In most enterprises, the choice isn't Github vs Buildkite, it's Github vs Github plus Buildkite. That's what makes it so hard to pay for a separate CI vendor that costs more, when your source code hosting vendor already bundles one, as good or as bad as it might be.
maccard · 55m ago
Sorry - I agree with you entirely.
maccard · 7h ago
My last company were buildkite customers and I was a champion for buildkite. Their offering was superb, and we loved it. This story pretty succinctly explains why we left buildkite - they chased enterprise billing to their success, and left the smaller companies behind. We had built our entire org around buildkite pipelines - using them for everything, because it was a convenient way to run tasks. We had 60 people who weee considered users. On their current pricing that would be $1800/month just for licenses which is nothing for a large company but it was the same cost as the hardware we ran the tasks on, and that wouldn’t fly. We left for team city which still had a viable middle ground for smaller companies.
Its a pity because it shows that there’s just so much more money by not catering to tens like ours
exidy · 19h ago
I love BuildKite. It might seem obvious now but I feel like BK had two key ideas -- fully declarative pipelines and a hybrid SaaS control plane / customer-managed workers concept that made it so much easier to deploy into large enterprises. That combined with a UI that was clear and a pleasure to work with.
I do wonder how BK will continue in a world that's increasingly dominated by GitHub and and other integrated solutions, but I hope as long as there's a market for quality tools, BK will survive and thrive.
kawsper · 10h ago
It also allowed us (a small startup) to run huge test suites, on cheap dedicated hardware from Hetzner, without sacrificing the developer experience.
It was the bill I was the happiest to pay.
We used Knapsack Pro to efficiently parallelise our Ruby test suite.
Today, I still use Buildkite, but now I build golden images (with packer) and deploy them with terraform.
Cyph0n · 17h ago
> In 2019 we raised a Series A of $28 million. The reason we did that was because I wanted to buy a house.
Haha, love it.
An inspirational story for sure!
apwell23 · 8h ago
It usually ' I wanted to buy a house for my mom'
stock_toaster · 16h ago
I used to really like buildkite, but their pricing has gotten kind of wild. Guess they are only chasing large cap orgs these days.
patapong · 10h ago
> The products I built with Claude are worse than without them because I use programming as a way to think and interact with the problem. When you're coding, you're deeply invested in the problem you're solving, getting intimate with the problem. With AI tools, it's surface level. It's a one-night stand with a problem versus a deep and meaningful relationship.
A very interesting insight about AI coding. It gets at the theory building part of programming, which is much harder to do when just supervising an AI in my experience. On the other hand, I am so much faster that it's hard not to use AI for coding. Interested to see what they come up with!
kannanvijayan · 8h ago
I'd been struggling to find good use cases for agentic things like Claude for this reason. My project is not a good fit for it as there's enough novelty to throw off the ML pattern systems. I was benefitting greatly from autocomplete, but not really leaning too much on code-writing tools.
But I actually found a use case where the agentic approach adds incredible value: internal tooling and visualization.
I was debugging some feature in the core, and had some code to jump a JSON diagnostic structure with a lot of info. Looking at this directly was getting to be a pain, so I wanted to write a UI for it.
Claude handled this task almost perfectly for <$5. I wrote up a description of the JSON schema, and a description of how that should map to a view, added some styling directions, and let er rip. In one afternoon, I go the UI built for me when I was doing dishes.
So I built the tool and went back to debugging and made a ton of progress using it. It's ok if I don't have a full internalization of the visualization architecture. It's basically a complex software "jig" that the AI built for me. I can build new ones as necessary.
A very interesting revelation.
sqs · 17h ago
Buildkite is awesome, by far the best CI product and with an amazing team.
1. Buildkite is probably the best commercial, off-the-shelf CI system right now, in terms of providing all the correct building blocks at the correct level of abstraction. 2. The impact of your CI system itself being good or bad is tiny in comparison to everything else in your end-to-end CI workflow. Far more important are your own CI scripts and what they run. A distant second is the observability tooling around your CI. 3. It's hard to justify the per-seat pricing of Buildkite, as a separate line item, when whatever CI offering your source control host bundles in will suffice.
I disagree here. A bad CI system makes it very, very easy to make the end to end workflow incredibly painful. Some small QOL features (buildkites input step was probably the reason it stuck for so long with us) are the difference between a tool being indistinguishable from others and being leaps and bounds ahead.
> it’s hard to justify the per seat pricing of buildkite
Buildkites pricing starts at 50% more than GitHub enterprise does. I couldn’t justify it as someone who loves buildkite and is in charge of making those decisions.
Its a pity because it shows that there’s just so much more money by not catering to tens like ours
I do wonder how BK will continue in a world that's increasingly dominated by GitHub and and other integrated solutions, but I hope as long as there's a market for quality tools, BK will survive and thrive.
It was the bill I was the happiest to pay.
We used Knapsack Pro to efficiently parallelise our Ruby test suite.
Today, I still use Buildkite, but now I build golden images (with packer) and deploy them with terraform.
Haha, love it.
An inspirational story for sure!
A very interesting insight about AI coding. It gets at the theory building part of programming, which is much harder to do when just supervising an AI in my experience. On the other hand, I am so much faster that it's hard not to use AI for coding. Interested to see what they come up with!
But I actually found a use case where the agentic approach adds incredible value: internal tooling and visualization.
I was debugging some feature in the core, and had some code to jump a JSON diagnostic structure with a lot of info. Looking at this directly was getting to be a pain, so I wanted to write a UI for it.
Claude handled this task almost perfectly for <$5. I wrote up a description of the JSON schema, and a description of how that should map to a view, added some styling directions, and let er rip. In one afternoon, I go the UI built for me when I was doing dishes.
So I built the tool and went back to debugging and made a ton of progress using it. It's ok if I don't have a full internalization of the visualization architecture. It's basically a complex software "jig" that the AI built for me. I can build new ones as necessary.
A very interesting revelation.