"Worse is better" is a good principle when thinking adding to the Farcaster protocol. 

Too often, the discussions veers to making the feature more generic to support hypothetical use cases. What often happens is: 

1. The extra feature gets low usage
2. Every developer building a client now has a tax 
3. Some developers don't pay the tax, and ignore the feature

The feature isn't well supported, and no one uses it, and just creates a bunch of ongoing debt for everyone. 

The goal for every feature should be adoption - if no one can guarantee that the feature will be adopted after it is implemented, we probably shouldn't ship it.

"Worse is better" is a good principle when thinking adding to the Farcaster protocol. 

Too often, the discussions veers to making the feature more generic to support hypothetical use cases. What often happens is: 

1. The extra feature gets low usage
2. Every developer building a client now has a tax 
3. Some developers don't pay the tax, and ignore the feature

The feature isn't well supported, and no one uses it, and just creates a bunch of ongoing debt for everyone. 

The goal for every feature should be adoption - if no one can guarantee that the feature will be adopted after it is implemented, we probably shouldn't ship it. 

https://en.wikipedia.org/wiki/Worse_is_better

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

There are some cases where the generic costs just as much as the specific. 

Frames and mini-apps are good examples where it was a better tradeoff to make the building block as flexible as possible. 

But these tend to be the except. Many features get significantly more expensive to integrate with as they become generic.

It has to somehow play into the overall growth strategy!

I.e. Retention, acquisition, monetization