It is never really for "One". If it is open source and published, It may be use by others... not to mention coding AI ML (Machine Learing), then for many.

I have written so much software for one... I cannot recall everything. I use some of it daily:

- I have my custom elf(glibc)/linux distro

- I use my own ffmpeg based x11 media player (will have an update for wayland).

- Since the "geniuses" at gogol blocked all accounts not using whatwg cartel web engines and blocked all self-hosted SMTP servers (I do not pay the DNS mob, then IP literals, which is stronger than SPF) to exchange with gmail.com users (now prisoners), I have my very own simple noscript/basic HTML servers (messaging, file transfer, openstreetmap browsing, etc). Unfortunately, most are C written from linux instead of assembly (at least, I removed most of the time the libc dependency with direct syscall programming). IPv6 is making everything internet software muuuuuuch easier to implement: I am lurking at an IPv6 only, super idiotic and real time voice/video/text/file transfer protocol, probably based on SIP (the main issue are randomly generated IPv6 addresses from mobile internet, which may require a mini-server for IPv6 address exchange, BAAAAAAAD!).

- Ofc, I still have my own minimal SMTP server (and a SMTP client to send emails), because there are still honnest people on internet. mutt forever.

- I am trying to build a RCS for linux, aka a Reduced Command Set with near direct hardwiring to linux syscalls. I lose comfort, but knowing that I removed giga tons of bloat feels so much satisfying it is worth it by light years. I will have to code my own command shell one day.

I still have C code since I currently need portability on IP-LOCKED ISAs (arm and x86-64). But I wish for RISC-V to be a success, namely as a modern, very often hitting the 'sweet spot' in technical design compromises, NON-IP-LOCKED ISA. I am writting much software in RISC-V assembly now... which I run on x86-64 with a small interpreter (written in x86-64 assembly)... trying to fix the bloat and kludge from corpo-like open source software (including the SDK).

Right now, I am writting my own wayland compositor using that framework. I was not expecting window management to be a bazillion of little things to do everywhere. And even if a wayland compositor is several orders of magnitude smaller and leaner than a x11 server, it ain't that a small project (ofc, I implemented myself the wayland wire protocol, no external libs here).

In my 'trying to fix the bloat and kludge' from corpo-like open source, I force myself to use my own exe/dynamic lib format for modern hardware (so lean, a simple RFC will be enough, and no more loader bloat/kludge). But I am scared at the abominations which are all the requirements of classic computer languages to run: I would like a mesa vulkan driver, but there is still c++ (super BAD) in there which makes porting to an alternative dynamic lib format a living hell, non trivial C won't be that easy neither (for instance the abomination of the ISO __thread keyword, amazing bright minds there). Taking perspective from that, I wonder why anybody sane would add on top of that a big runtime requirement??

And what people doing that have to keep in mind: IRL can put a violent stop to all of this.