TL;DR: David and I spent the last couple of weeks building our vision of what working together in web3 should feel like. You can check it out here! If you do — please let us know what you think.

Web2 has no idiomatic development environment. Developers love to build things, and they also tend to love building meta things to help them build other things, so web2 companies have infinite choice when deciding what their develop → test → prod pipeline looks like. 

This sounds great until it isn’t — devops and infra spending at tech companies balloons with headcount, and bad developer experience is an insidious driver of poor engineer retention. So the best tech companies tend to invest a ton of resources toward creating a seamless experience for writing and pushing code. Companies have dedicated teams focused on developer effectiveness, for build tools and testing infrastructure, and for production monitoring, as well as a host of external vendor software.

Coming from more than a decade of web2 development, David and I each had standing beliefs about the “best way” to do things. Some cursory research into web3 best practices showed us that smart contract practices were still coming out of their wild west adolescence — with new protocols and layer 1s and 2s coming online every week, the space was a primordial soup of tooling and opinions.

Where web2 came up with its development lifecycle over the course of 25 years, web3 tooling is just beginning, and its evolution will happen on a much more compact timeline now that we know what (doesn’t) work. However, some of the tools that worked well in web2 (containerization, replication of local environments, APIs defined in an IDL and run through codegen) have less established parallels in web3, and some tools that are specific to web3 (e.g. state management on a blockchain) have no parallels at all.

Here are the problems we’ve seen, either from our own experiences or by talking to other web3 developers and founders:

• No one is confident that their smart contract changes will Just Work — whether the problem is backwards compatibility, interface changes, or plain failed deployments due to gas management, everyone we’ve spoken to is scared to change their contract logic.
• Because of this fear, smart contract developers work in waterfall fashion. They wait on very clear specs about what changes are necessary, and make minimal improvements over long time periods. Most of the time is spent regression testing, waiting for audits, or statically debugging code.
• Environment setup is a pain. This will become more of an issue as web3 companies grow and the developer base becomes increasingly specialized — an engineer purely working on frontend works faster without the overhead of setting up a node, learning to read logs, or forking from a chain.
• Mirroring what you’ve built internally → what you want external developers to interact with is nontrivial. Especially important for companies with a priority of onboarding devs, the lack of a replicated, controlled test environment makes it difficult to interact with a protocol’s smart contracts.
• User testing isn’t the same as in web2. With the additional overhead of deploying to testnet, pointing a separate client to a test set of contracts, and uncontrolled global variables (test tokens, uptime, and performance), it’s difficult for non-developers to show prototypes to users for feedback.

We don’t have the answers, and our predictions might be wrong as web3 evolves and more best practices arise. But we’re convinced that there are improvements that could and should be made. To that end, we’re excited to show off Kontour to the world — we built this as a platform for developers to discover and integrate with protocols seamlessly. With Kontour, devs get a visual sandbox to play around in, beautiful documentation, and native tooling that lets them iterate on top of an existing protocol instantly.

[Twitter] 
[Medium]
[Discord]