Manually running a CSS preprocessor and a JS minifier by hand before every deploy had gone on long enough, a genuinely embarrassing amount of time into a year where automated build tools had clearly become standard practice elsewhere. We finally sat down and compared Grunt against Gulp on an actual client project rather than a toy example, since a real project's edge cases, a Sass file importing a dozen partials, several third-party JS files needing concatenation in a specific order, tend to surface differences a five-minute tutorial example never would.
Grunt's configuration-over-code approach was easier to read on day one, a JSON-like config object describing each task's inputs and outputs, which felt approachable coming from years of writing config files for other tools. But Gulp's streaming, code-based pipelines felt faster in practice and easier to extend once we understood the pattern, piping a stream of files through a chain of transformations rather than writing each task's file-reading and file-writing steps out explicitly the way Grunt's plugin model tends to.
The concrete tipping point was watching how each handled our Sass compilation plus autoprefixing plus minification chain. In Grunt, this meant configuring three separate tasks and making sure they ran in the correct order via task dependencies. In Gulp, it was one pipe chain, Sass, then autoprefixer, then a minifier, read top to bottom in the order the transformations actually happen, which matched how we already thought about the process conceptually and made the whole chain easier to reason about at a glance.
We landed on Gulp for new projects, keeping Grunt on the couple of older ones already configured with it rather than migrating for its own sake, a decision that came down to a simple cost question, is the marginal benefit of consistency worth the hours of re-testing a working build pipeline on a project that isn't otherwise changing. For actively developed projects the answer was clearly yes eventually, but not urgently enough to interrupt other client work just to make two build configs match.
Either would have been a step up from what we were doing before, which was nothing, or more precisely, a personal collection of half-remembered terminal commands run in roughly the same order each time and occasionally forgotten. The bigger win was just having any automated, documented build step at all, one that a new contractor or a future version of either of us could run with a single command rather than reconstructing from memory.
We also asked around briefly among a couple of other small agencies we know before finalizing this, partly to sanity-check that we weren't about to invest in a tool that was already on its way out. The informal consensus we got back leaned toward Gulp as well, for roughly the same reasons, code-based configuration felt more approachable to people already comfortable writing JavaScript, which describes basically everyone we build things with. That external nudge wasn't the deciding factor, our own hands-on comparison was, but it was a reassuring confirmation that we weren't picking the less-supported option out of the two.