It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.
Should one build their own database? Probably not. That introduces more complexity.
What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency.
Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria.
So seems like we're in agreement :)
We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We use Postgres instead of a custom
We are minimalist in the sense that we minimize the code we have to maintain in house.