// PATCH №045 · TOOLING
Speed benchmarks are seductive. A build tool that takes 800ms instead of 3.2 seconds feels life-changing for the first week. Then you start finding the rough edges — incompatible plugins, opaque error messages, undocumented config fields. By month three you’ve spent more time debugging the tool than the savings will ever recoup.
What actually matters in a build tool
- Error messages that point at the offending file and line
- Plugin ecosystem that doesn’t lag the framework you use
- Configuration that’s grep-able (i.e., one config file, not eight)
- Caching behavior that’s predictable enough to debug
Speed is rank five at best. A 4× faster build that fails opaquely once a week is slower in human time than a 1× build that always works.
The migration math
If you’re considering switching, multiply the per-build savings by your daily build count by your team size. Then subtract the migration cost (config, plugin replacements, CI updates) and the ongoing cost of being on a less-mature tool. The number is almost always negative for teams under 50. It only goes positive at the size where you have a dedicated build-tooling engineer — which is also when you can fork and patch the tool you already have.