Blockchain development entails a unique challenge: How do you deploy immutable contracts to create a product, when you can't see that far into the future?

Operate too leanly in product and engineering, and you can find yourself in chaos. In this environment, it's better to develop with conviction and a concrete understanding of what the product does. This is how Compound and Uniswap were successful; they did roll out out multiple versions, but each was a well-considered, best-in-class product for the given market. They did not launch a "kinda working" model to riff on. Mistakes on-chain are costly and sometimes impossible to undo.

Related to this, our challenge at Mirror has been thinking through how to on-board new users, amid the fog of unexplored terrain.

One feature we want is for publications to allow multiple contributors. For example, imagine we onboarded The New York Times. In order to have multiple contributors, a good strategy would be to deploy a Publication Contract that stores a list of the contributors, and we could use that to validate authenticity of posts.

The publication contract could represent The New York Times on-chain, and I think it would make sense to allow people to invest in that publication through a token. See Platforms with Tokens.

However, we must balance complexity vs execution at our early stage. Thinking through the right features for this contract (even a first version of it), and building out multiple-contributor UI, could take weeks, and probably isn't the right priority. We already have launched a successful crowdfunding campaign, and should quickly roll that out to more users.

So we must ask ourselves whether we can achieve both outcomes in sequence - productizing what we know already works, and delaying more complex operations that haven't been validated yet. I believe we can.

Note: There are patterns of Ethereum development that allow for contracts to be upgraded. But these are complex to coordinate, and you still need to have some idea how things will eventually be structured.

In our case, we will start out with the user simply owning the ENS domain for their publication, with the ability to launch crowdfunding campaigns from their Ethereum wallet. We can do this by launching the $WRITE token to mainnet, and using the "burn-to-register" model in signup that we've proven to work so far on testnet. Then, we allow user to upgrade into a deployed publication contract later, by transferring the ENS ownership to that contract. Once the ENS has been transferred, multiple contributors can be added to the contract, and the blog proceeds as a multi-contributor publication, which ostensibly would be able to mint tokens as well.

What happens to previous posts, you ask? I think those posts are all still valid, as long as the contributor who wrote them gets added to the list of contributors in the Publication Contract.

So this seems neat and will work. Our next step then should be to push to get the $WRITE token on mainnet sooner rather than later, and have it not deploy a Publication contract, but instead just assign ownership of the ENS address to the individual contributor. Following that, we can commoditize crowdfunding, and then we can look into upgrading into fully fledged multi-user, investible Publications.

I will use this post as a summary of the ideas, and share with the team for feedback.