Builder Experience: Why Teams Join or Leave Polkadot
The article was written by William, a Permanence DAO member.
This is a report summarizing the results of six interviews of builders who are either considering to join Polkadot or have left Polkadot in the past 18 months. The interviews were conducted over Q3-Q4 2024. Key findings are presented, along with recommendations for further research as well as the creation of a Builder Success Program.
Thank you to all the teams who chose to share their experience, as well as everyone who participated in providing feedback to help shape and refine the article: Christian and Mario from Polkabiz, Jashar and Natalie from So So Scaled, Alex from Parity and others from the Polkadot BD community.
Introduction
As the Web3 space keeps transitioning towards early mass market adoption, ecosystems are heavily competing for mindshare and marketshare. The lifeblood of any ecosystem is its builders and their applications, making it critical to understand what drives teams to choose and stay with a platform. This research aims to help Polkadot strengthen its ability to attract and retain builders.
This examination comes at an important time in Polkadot’s evolution. Just over a year into the decentralization, the ecosystem has seen community-led initiatives in marketing and business development, while embarking on ambitious technical transitions — from Polkadot 2.0 through developing an EVM-compatible L1 to JAM. It has been a time of churn — with burgeoning giants like Mythical entering, but on the other hand with existing builders and investors setting their sights on alternatives during the bear market.
This qualitative study presents findings from in-depth interviews with teams that are considering to join Polkadot, or have left Polkadot over the past year, and dives into the reasons behind their decisions. The findings highlight challenges faced by teams building on Polkadot in areas including operational support, investment and funding, economics and relationship management. Builder opinions of other ecosystems are discussed, and recommendations including further interviews and a “Builder Success Program” are presented that serve to enhance builder retention and accelerate growth in the ecosystem.
Methodology
This article draws from Q3-Q4 2024 interviews with six blockchain teams: five former Polkadot projects (parachains and solochains) that migrated or are considering to migrate to other platforms, and one project evaluating a deployment on Polkadot. Their experiences reveal real-world challenges that have led to gaps between Polkadot’s technical capabilities and market adoption.
To note, these were candid interviews conducted under the promise of anonymity, and the exits occurred over approximately an 18 month period, so circumstances that are referenced may have evolved.
Key Findings
Note: These are unfiltered opinions of individuals who have been interviewed. They have not been fact checked, or benchmarked against other ecosystems, and a recommendation is presented later for further investigation.
Operational and Maintenance Challenges
The technical superiority of Polkadot was universally acknowledged, but teams have had challenges running their blockchains in practice. Builders remarked “Polkadot is the best stack” and “Substrate is a beautiful framework,” yet, they encountered issues after deployment: “The system kept breaking. It required a full-time engineer to maintain the parachain... On EVM, we give the keys to deploy to governance, and the story ends there.”
Beyond that, operational and maintenance challenges included:
- Stability: “Even the RPC endpoint could change with upgrades. When we had to push an upgrade to the parachain… we had to… give them a month to update the client to add logic to tolerate both versions, the current and new.” This made it difficult to acquire and retain enterprise customers. Another team remarked, “The system kept breaking. It required a full time engineer to maintain the parachain.” “The benefit of EVM is that it’s EVM. The bytecode is standardized — you just deploy and forget. To us, this is enormously helpful, and maintenance is substantially less.”
- Lack of Support: Builders remarked, “After working in Polkadot for three years, I have no contacts at Parity” and “Never received a single answer from Polkadot.”
- Longevity: “The infrastructure is good, but it prevents us from being decentralized because the infrastructure will always need the core team to be here and pay for the lease or the coretime.” Note — this seems to be a commentary on the inability for projects deploying on Polkadot to inherit a core value of the protocol (e.g. resilience via decentralization).
- Pricing Model Change: The change from the parachain model has also impacted teams: “The switch to new pricing models with coretime(…) hit us more than other projects. If I have to pay the ecosystem instead of just staking, I might as well pay on other ecosystems.”
It should be noted that following the decentralization, Parity has strengthened its ecosystem support with pre-sales, post-sales, and an open line of communication with teams building in the ecosystem.
Investment and Funding Challenges
Teams mentioned the difficulty of finding investment due to building within Polkadot. Investors were uninterested in the ecosystem, would actively solicit teams to choose other ecosystems, and would offer lower valuations for staying in Polkadot, with one team mentioning the valuation for staying in Polkadot was 10x less than if they moved to Ethereum. Another team remarked: “Even before (6–9 months ago), investors were asking why we were still in Polkadot. It’s a ghost chain and nothing is happening. We didn’t have ‘pressure’ but it was very clear that if we wanted to get more funding, we had to do something.”
On valuations, one team mentioned: “Say I have a use case that brings in $100M TVL. Based on calculations, my ecosystem valuation is $3M. If I build on other ecosystems, I get $80M.”
This was coupled with the difficulty in obtaining grant funding and interacting with ecosystem funding initiatives in Polkadot:
- Confrontational Process: “In order to get money from Polkadot, you need to get endorsed by all these people in OpenGov, and they like to trash you in front of everyone” and “Gov drama results in a negative view externally.”
- Grant size / Accessibility: “The money is not that good anyways,” and “The DF fund… It’s not really reachable. There is a gap between giants and dwarfs”
- Non-builder Focus: “The drama resulted in a football sponsorship and F1 sponsorship. There is no focus on getting stuff used. You also see tons of spending for croissants — 6–7 figure total event spending. Polkadot is transparent, and it’s a double edged sword. Externally, it sounds amateurish, so people don’t want to touch it.”
Relationship Management & Community Challenges
One team reported: “Nobody in the ecosystem spent time with us. You are by yourself on the playground and nobody speaks to you.” This contrasted sharply with competitor experiences: “We met the founder of another ecosystem. He spent time with us… One day the cool kid from the other class comes and asks how you’re doing — we were so happy.”
Another team gave their story of reaching out to another ecosystem: “They didn’t have to sell to us or entice us. We got tech support, governance support. We have dedicated chat rooms where people actually reply and it’s useful. They have been helping us on the auditing side with free audits. We got feedback from the leadership team — that feels so much different than Polkadot. They ask what we need. They know we are customers of their technology. Ultimately builders are your customers. You need to treat them that way.”
There was a mixed reaction to the maturity of the community. One team remarked, “More than most groups, the ecosystem community is more ‘adults.’ Although not all, I feel like the ecosystem community cares a lot about stability.” Others found challenges: “On social media, people are just obnoxious, aggressive with each other. The ecosystem sucks at being inclusive,” and Polkadot is “one of the worst communities in terms of gatekeeping.”
Perspectives on other Ecosystems
Evaluations of alternative ecosystems provide valuable insights into the competitive space as experienced by a builder. While the perspectives captured here focus mostly on their target platforms rather than a comprehensive ecosystem analysis, their comparisons highlight key differences that influenced the decisions to migrate.
L1s
Solana came up as an example of an ecosystem with active community engagement and strong cultural appeal, with one team stating “Solana is so cool they don’t have to give grants.” There was a general perception that decentralization was not a strong point in the choice of platform: “Decentralization doesn’t matter to the end user; Solana is OK.”
Non-EVM blockchains such as TON, Aptos and Sui were mentioned as examples of ecosystems finding success with non-standard programming environments (e.g. Move on Sui, FunC on TON). “But look at the Ton virtual machine. On Telegram, everyone is 20 years old. My point is, if you are not cool, you need to be EVM. If you are cool, create culture, are upward leaning, then your stack can be the worst stack and no one cares.”
L2s
The primary L2 ecosystems cited as strong choices were the Optimism Superchain and the ZK Sync Elastic Chain. Polygon zkEVM was not regarded highly. Note: Arbitrum was likely not included due to selection bias in these conversations.
Optimism’s advantages include:
- US market presence: “Base is based there, and it’s almost like it’s guaranteed to win at this point.”
- Regulatory pathway: “Investors strongly suspect they will be the first regulated chain in the US.”
- Corporate backing: “Coinbase is set up to be the NYSE of crypto in the US.”
- Default choice: Has already been chosen by Base, Worldchain, Soneium.
ZKSync’s advantages include:
- Lower operational costs: “cheaper to run ZK infra, even if we did launch a rollup” and “You don’t need 3–5 collators minimum to sync state.”
- Technical innovation: “Account abstraction is Ethereum-centric. ZKSync made it native.”
- Better confirmation: “Near 1 second confirmation is good for 99.9% [of use cases]. Polkadot technically has faster finality, which is better for exchanges. But you have 12–20 second finality on parachains.”
- Native account abstraction: “Account abstraction is Ethereum-centric.” Some aspects of AA are available on Polkadot, “but ZKSync made it native. They are building non-web3 UX for web3.
EVM
The advantages of building on EVM include:
- Standardized bytecode: Ability to run unmodified in many ecosystems.
- Extensive tooling: “Etherscan for free, which is an order of magnitude better.”
- Rich analytics: “Dune Analytics, Token Terminal and Nansen” are all available.
- Large knowledge base: “if you search anything you will find an answer easily.”
- Liquidity: “There’s no volume today — it’s dwarfed by anything in any other ecosystem. If you launch a token, nothing will happen. That’s a tricky issue.
Recommendations & Next Steps
As a community, we should think through the onboarding experience for teams as a whole, beyond just technical support.
Further Investigation
Given this is just an initial survey of a handful of builders who have left Polkadot, we should validate and expand upon findings by continuing to do interviews. The scope can expand in a few ways by interviewing:
- Teams who are still in the ecosystem to understand their experience of what is going well and what could be improved.
- Developers of dApps or infrastructure rather than just blockchains
- Teams who are not at all in the ecosystem, to gather perspective about ecosystem choice in the industry as a whole.
Iteratively gathering, understanding, and acting on team feedback is necessary, especially as Polkadot’s success ultimately requires builders to join, have a great experience, and find success for their products in the ecosystem. It can also serve as competitive analysis, providing important insights that help BD teams.
Builder Success Program
In many businesses including a platform business like Polkadot, churn is more costly than new customer acquisition. Churn results in weakened network effects, lost ecosystem investment, market perception and opportunity costs. According to the interviews here, Polkadot has struggled with customer relationship management with builders.
There is a need for a team in the ecosystem dedicated to customer success, whose goal it is to attract and retain builders, that complements the more technical and development-focused programs such as the Polkadot Alpha Program or the technical sales support from Parity. The difficulties involved in understanding the ecosystem, finding resources, and communicating issues and questions directly lead to churn. Conversely, a great experience in the ecosystem creates a halo effect that attracts more builders.
The main recommendation is the implementation of a Builder Success Program that focuses on customer relationship management with builders and it should focus on ecosystem integration, retention and business success for the parties that are joining the ecosystem, with a focus on proactive engagement and communication rather than reactive support.
Conclusion
Polkadot’s success as a platform is fundamentally tied to the success of its builders, measured via user adoption, liquidity, transaction volume, funding, or other relevant metrics. While the technical aspect of the platform is solid, these interviews reveal that sustainable ecosystem growth requires a more comprehensive approach to builder support.
The ecosystem currently offers various technical resources to builders: Parity’s technical pre-and post-sales support, the Polkadot Alpha Program, and DF-funded initiatives for documentation and developer experience. However, we are missing a dedicated team focused on holistic builder success beyond development support. Conversations with teams that are considering Polkadot or have recently departed indicate that establishing a capability around Builder Success could positively influence the building experience in Polkadot.
Ideally this article will serve as the first step for the ecosystem to recognize that builder success and builder retention are incredibly important factors to consider to complement the new technical foundations being delivered in 2025 and beyond.