05/25/2023
3LL #3 (go here to start at the beginning: http://ow.ly/2EAj50OsFPQ)
Project: build a web3 solution to create limit orders on Uniswap (v1, before this functionality was native to Uniswap)
3LL:
- don’t build a product that is fundamentally a single feature for someone else’s product unless you’re certain they will never implement that feature.
- we had trouble managing budget and scope on this project. The requirements were loosely-defined when we signed the contract (as is often the case), but we didn’t do a good job controlling scope and expectations as the project progressed. As a result, we ended up with a “balloon payment” of scope as we neared the delivery deadline. This resulted in long days and nights, burning out our resources unnecessarily. Make sure to checkpoint on both delivered code and upcoming expectations and don’t be afraid to push back as the project progresses.
- accepting payment (even a portion) in anything other than cash is a riskier proposition than you may think and may introduce unforeseen dynamics. We accepted a portion of payment for this project in the project’s token, which seemed great when the price increased. However, dev teams are often subject to a lockup period when they cannot sell. Even if you’re not, you don’t want to be dumping your client’s token, lowering the price and signaling a lack of faith in the project. Thus, you’re in for the long haul and this has historically been a bad position to be in, in both crypto and startup equity. Make sure you’ve covered both your costs and a reasonable margin *in cash* before assigning any value to the token/equity.
3 Lessons Learned (“3LL”) from building custom software for clients #1 This is the first in a series of bite-sized, bulleted posts that I hope will help my…
