I worked in web development for a few years (2010-2015) and then left to start a company with a friend (mid 2015). We decided to build audio reactive visualization software written in C/C++/glsl, way different from where web development was and is (still do web stuff but primarily backend services for our app and React for the sites).
The industry we're in focuses primarily on international music festivals (burning man, boom) and specialized art installations/exhibits. We were successful and now we have employees, a vibrant community, ambitions plans for new products, and aggressive deadlines.
I say that only to point out that work is work. Whether you're working for someone or working for yourself, you can always find things to stress about and reasons to push yourself to the brink of burnout.
As corny as it sounds, Handmade hero has been a reminder of the reason I quit my job 5 years ago to do something technologically and emotionally challenging. It keeps me in touch with the younger me that that just wanted to learn everything I could about programming, web/native/embedded whatever.
To your point, though, it definitely is not for everyone. If you see software as simply a means to an end, then there is nothing wrong with focusing on components that make products viable. I enjoy the craft but I also understand you can't have success by being precious about every little technical detail.
Just wanted to share my experience. I wish I would have come across something like handmade sooner in my dev journey.
That being said, arriving afterwards with a message of "we're like X,but faster" could be a good marketing catch, but probably not for any kind of enterprise app. (The only good marketing catch in this case would be "we're like X, but cheaper.")
No idea how such an hypothesis could be tested. We would need records of user switching from an app to another.
SQLite is just one piece of a broader argument that C's inherent risks aren't completely unmanageable. All it takes is an incredible amount of diligence, tooling, expertise, and money.
Which is great ! I just don't know how to transfer that to building software as a team with multiple skillsets, unknown feature set (because market feet is still searched for) aggressive schedule, (We don't know what we want to build , but we need it in six months), large target audience ("what do you mean they have to install stuff ? Where is the link I can paste in an email so they open it in IE6 ?") , and,let's be honest, less knowledgable and more lazy developers.
(To be clear : I'm not criticizing the network or project. I just find it interesting that they had a goal - making fast software - and that, to the ebest of my knowledge and without a rigorous analysis - it seems that most projects converged on a very particular kind of software. Which just happens not to be the kind most of us will ever be working on, but it does not matter. Go them !)