Prioritize internal developer experience.
As a startup, your number one priority is to build and distribute the best product experience possible while constrained by time and money.
A large chunk of the resources is spent on developers, as Web3 companies are technical.
As a result, spending time considering how tooling and infrastructure can improve developer experience internally is a high-leverage task.
There are tradeoffs when making decisions, and it is essential to fully grasp the immediate and future consequences.
Some of the ways this can be done:
Leverage simple, well-maintained tooling that is effortless to set up, use, and maintain for non-core parts of the product. There is no need to recreate the wheel. Also, the wrangling with the tooling should be minimal. If you decide to write custom code, you must maintain this.
If you are a leader or manager, listen to your IC (independent contributors) opinions. They will have the best feel for any friction points.
If you are an individual, suggest alternative solutions to your manager. If you believe you’ve found a better one-do your best to grasp the tradeoffs and make sure your case is well presented.
Internal developer experience tends to bleed out and impact downstream integrations. If the core of your product isn't frictionless to use (smart contracts in Web3), this tends to bleed to downstream tooling-you have to build more peripheral contracts, which add complexity and maintenance costs.
An environment with excellent DX allows devs to focus their energy on solving challenging problems, leading to less buggy code, happier devs, and lower maintenance costs.
This will save time and money, as dev hours are money. There will also be a probabilistic reduction in bugs and maintainability, which means everyone in the org can focus more on building than maintaining, thus 10xing productivity.
