Metro is the proudest work of my career. Ever since starting it on vacation in November 2024, building it has been an incredible journey and the community reception has been nothing short of wonderful. It sits at the intersection of several fields I've come to specialize in, ranging from metaprogramming to compilers to static analysis to dependency injection itself. I've learned a lot along the way as it's allowed me to really dig into compilers and algorithms subjects I haven't touched since university.
As of version 0.10.0, Metro supports most of its initial goals. It's stable for use, production-ready, and delivering real-world results. Now, I’m opening up GitHub sponsors for the project.
Metro's Value Prop
Metro is ultimately a developer productivity multiplier. It's consistently delivering double-digit percentage build performance gains simply by swapping out your dependency injection framework. Entire developer experience (DevXP) teams are staffed to achieve goals below that.
Metro’s own public build benchmarks consistently show it outperforming source-generation tools (like Dagger) by ~50-80% while maintaining runtime performance parity.
On top of this, Metro has an extensive compatibility system built in. This allows it to support a much wider range of Kotlin and Kotlin IDE versions than a typical (third party) compiler plugin, and use of it doesn't require specific 1:1 version locking.
Real World Impact
With its extensive interop, large teams have been able to adopt it with minimal code changes and minimal work. Metro is already used in production by engineering teams at Block, OpenAI, Dropbox, and more.
Cash App migrated their Android monorepo to Metro and wrote about their adoption. The results were immediate: a nearly 60% reduction in incremental build times.
Napkin Math
Let’s use the ROI using Cash App's real-world timestamps on a hypothetical mid-sized Android team. Even on a highly optimized code base, the savings add up fast.
- Team: 15 Android Engineers
- Volume: 40 builds per engineer/day
- Savings per build: ~17 seconds (29s down to 12s)
Translates to...
- 17s saved × 40 builds = ~11.3 mins saved per dev/day
- 11.3 mins × 15 devs = ~3 engineering hours saved every single day
- ~786 developer hours per year.
If we take the average cost of a mobile engineer in the US at ~$100/hr, that's ~$75,000 in recovered productivity per year.
Cash App's baseline (29s) is already fast for a large app. For large teams with typical 1-2 minute build times, these savings could be significantly higher.
Beyond the Spreadsheet
DevXP isn't purely measured in raw minutes saved.
- Context Switching/Flow State: A 30-second pause is just enough time to check a notification and lose focus. A 12-second build keeps you in the editor and in the flow state.
- CI Time: Faster builds mean faster feedback loops on PRs, allowing engineers to iterate and merge code more frequently as well as reduce CI compute costs.
- IDE Integration: Metro integrates with the Kotlin compiler directly, meaning errors can be reported inline as you type in the IDE (just like standard Kotlin code) rather than waiting for a failed build task.
- Better Error Messaging: Metro's compiler goes to great lengths to give meaningful error messages that not only explain what went wrong, but also:
- Why it's an issue
- What you can do about it
- (If possible) What you probably intended instead
What does sponsorship mean?
Sponsorship doesn't mean it's becoming a paid product. Metro will always be free and open source. This new sponsorship setup is purely a support and gratitude avenue.
I am currently funemployed (left Slack in August 2025 after nearly 6 years) and enjoying the freedom to work on open source full-time. In the near term, I just want to just support my extended break and continue building out Metro toward a 1.0.0 release. Feature-complete does not mean maintenance-free, though. While many projects have the luxury of eventually reaching "done", Metro integrates deeply with the constantly-evolving Kotlin compiler and language. Supporting new language features and compiler versions requires ongoing, complex work. Metro has a built-in compatibility system specifically designed to shield you from this churn, but maintaining that is an evergreen project. It's work I'm committed to because I think it's valuable, and I hope you'll agree.
In the long term, eventually I will return to a full-time role. I'd love to reach a sponsorship level that allows me to potentially work part time and continue dedicating this much time to Metro and my other OSS projects.
Regardless of what the future holds, Metro and my attention to it isn't going anywhere. On top of my own maintenance, there's already a healthy and growing community behind it ranging from regular contributors to technical content about it like talks, blogs, etc.
Tiers
- Individual ($5/10 mo): A personal gratitude sponsorship. You're an individual using this in your project and wanna sponsor a coffee or two/month as thanks.
- Company ($250/500 mo): For medium to large size companies that are getting a lot of value out of Metro and want to support the project.
- If you're that 15 person team saving nearly $100k/year, $250/month is just $3k/year going back to the OSS community.
There are also one-off donations if you just wanna buy me a coffee!
Expectation-setting
Sponsorship is to generally support continued development and maintenance of Metro and my other open source work. It does not come with private support or prioritization. I am casually open to consulting or contracting (feel free to contact me!), but that is separate from sponsorship.
Thank you to everyone who has used, tested, shared, given feedback (positive or negative!), and contributed to Metro so far.
👉 Sponsor Metro on GitHub
(I'm also set up on thanks.dev if that's easier!)