While we were still at our full-time jobs, David and I got into hackathons. We did this because most of our free time was on weekends, we both enjoyed building things nonstop, and we love having a goal (especially when that goal involves some money). During these hackathons, I’d write the smart contracts and backend data layer, and David would leverage the APIs to build a cohesive UX and put together a great interface.

We did this twice over the course of a month, and we managed to win twice, for different ideas but using the same workflow. This by no means proved to us that our workflow was the winning formula, because it wasn’t. Compared to the development cycle at web2 companies, tooling in web3 left a lot to be desired.

When David and I built our first dapps and protocols, we hacked together a process that worked for us. It had its pain points and overhead, and there were many times where the answer to a bug was “idk it works for me locally”, but it let us iterate quickly enough to put out a finished prototype in 2 or 3 days. Here’s what we ended up with:

• Our stack was NextJS/React on the client, a nodeJS server, and Solidity deployed on Polygon. Locally, the server and dependencies ran in with Docker Compose and the client ran its own Next server.
• I’d develop smart contracts using Truffle and mocha unit tests. This contract repository was a submodule of our main repo.
• When ready, I’d compile my Truffle submodule and run a homegrown script that copied the ABI output to a shared folder in the main repo.
• I’d migrate my contracts to testnet (sometimes having to wait for a faucet), and manually copy the addresses to a file and commit.
• David would pull our main repo, ignoring the submodule, and refresh the server running in Docker + reload the client.
• David would use the contract functions from testnet in his client (sometimes having to wait for a faucet) and tell me if any end to end bugs were happening.
• Rinse and repeat.

There were a couple of friction points with this setup:

1. David had no visibility into the contracts and could only go as far as exploring testnet transactions on Etherscan — we weren’t in control of the testnet environment, so there were no “admin backdoors” even for our local testing.
2. We relied solely on a series of unit tests against a test node and manual integration tests, where any number of edge cases in interaction between the client, server, and contracts, weren’t tried at all due to time constraints.
3. It was painful to iterate. Pushing any change to the smart contracts felt like a heavy action even between just 2 developers, so we tried hard to stuff many fixes into one contract deploy instead of moving fast and committing early.
4. Additionally, some of our contracts had owners, so we had to share the private key that deployed the contract in our local environments. This was a burner key, but being forced to share real data in order to run local tests was undesirable.

Currently, web3 teams are small. It only takes a few developers to build a protocol, and building on top of existing blockchains pushes scalability problems into the future. Smart contract developers work solo, and contract state is rarely shared in development, leading to long iteration cycles and high risk deploys. As more web2 developers move to web3, collaboration and visibility during development will become increasingly painful, and the companies that solve these problems well will be rewarded exponentially by beating the competition with faster development velocity, better collaboration, and increased security.

David and I are excited to help create these solutions — we’ve recently joined the South Park Commons & Script Capital fellowship to kickstart our web3 founder journey. Follow along on our journey by keeping up with this blog (bi-weekly reflections) or on other platforms below!

[Twitter] 
[Medium]
[Discord]