Hey @owocki thanks for the question. We had originally prioritized matching estimates for GG18 as we responded to top pieces of user feedback from the beta round. It was the 3rd-ranked piece of user feedback so third in the sequence of what we built for the round (1: gas fees → PGN support, 2: checkout fragmentation → multiround checkout.) Unfortunately, our work on PGN support and multiround checkout has run over the estimated time to complete, so we don’t have the capacity to also build matching estimates before GG18 donations kick off next week.
NB: Why did our estimates run over? 1: We’ve significantly changed team capacity over the last 6 weeks through parental leave/RIF/performance-related layoff, 2: multi-round checkout and PGN both required substantial coordination with other teams 3: multi-round checkout is a massive project that we likely underscoped – retro forthcoming ![]()
We’ve dropped it from the roadmap entirely instead of delivering after GG18 because we want to focus on delivering features that help us hit our self-serve QF + direct grants goals. We’ve already knocked Gitcoin Grants Round QF goals out of the park! (Link to budget post for updates on those goals.) Matching estimates are not applicable to direct grants, and feedback so far around self-serve adoption indicates our feature efforts would be better focused on the Grants Manager experience vs the donor experience.
Re: could supermodular or another 3rd party build this. We’ve tried two projects with external teams building on the Grants Stack front end (Supermodular- collections, Bootnode- direct grants) and didn’t find that either of them were effective. The Supermodular project was a great 0 → almost 1 but wasn’t able to incorporate styling and UX improvements and never shipped. The Bootnode project required really heavy coordination with our internal teams and the amount of adaptations and merge conflicts from that project were very substantial.
Hope this helps, always happy to discuss further!