I love this channel. Since we as vibecoders are spending less time with code, we deal more and more not only with manager-type decision making, but also with the design of our apps. Hence we benefit from getting more knowledgeable in that area.

In this video, Saleh talks about how cramming ever more features, especially into our phones, has made more and more settings necessary to satisfy everyone’s needs.

Many of those settings simply stem from development teams not being able to make a hard decision, so it becomes a setting. Also, as with features, settings get added way faster than they get removed, if ever. So they accumulate.

Amongst other studies, Saleh cites one which investigates the usage of the text-file based configuration surface of webservers. Only 6-17% of features were used by most users, while half of all features were used by fewer than one in a hundred users. A good number of settings were used by no-one at all.

Now, what does that mean for a landscape in which building software has become cheap?

I think you can intuit the answer. It points to taking out complexity by building more bespoke software. Where complexity is not accidental, but essential, it ultimately stems from conditional statements: “In this situation, the app should behave like this, in that situation, it should behave like that”. In many cases, this branching is unavoidable - at most optimisable - because it is addressing different data shapes, i.e. it is related to modelling. The other part, however, comes from making software, for economic reasons, for a bunch of users, preferably as many as you can. The game thus eventually became hyperscaling. Now SaaS, as we’ve all heard, is supposedly dead. And while I personally would like to see things being crafted at a human scale, it seems some smart guys on the other side of that argument are already finding ways to adjust.

Back to my earlier point: bespoke, but for whom? This should look similar to the curve for actual feature usage, as indicated above for how administrators use the features of their webservers. Software for one person might not need any settings at all, whereas software deployed to 10,000 users needs many, involving a long tail of smaller and smaller subsets of users using certain features. A group of ten people (speaking metaphorically) might be the sweet spot. It represents a “culture” in a certain sense. People working in a similar way, using roughly the same set of features.

Until recently, producing for the masses was simply the cheaper option. Now there is an opportunity to build software for cultures. A culture makes decisions, mass culture needs settings.