One of them stands out, due to being super-productive, over years, and then decades.
A large system that was originally written by only two super-productive engineers (I mean real engineers, both with PhDs in an area of Engineering). And a comparably capable and essential IT person.
The reasons for the super-productivity include one of the developers choosing great technology and using it really well, to build a foundation with "force multiplier" effects, and the other developer able to build out bulk with that, while understanding the application domain.
Another reason was understanding and being pretty fully in control of the code base, so that, as needs grew and changed, over years, someone could figure out how to do whatever was needed.
One of the costs was that most things had to be built from scratch. Over time that also proved to be an advantage, because whenever they needed (put loosely) a "framework" to something it couldn't do, they effectively owned the framework, and could make dramatic changes.
When I said "costs", I mean things like, many times they needed to make a component from scratch that would be an off-the-shelf component in some other ecosystem. So if someone looked closely at how time was sometimes spent, without really understanding it or knowing how that panned out, it would look like a cost that they could optimize away. But if they looked at the bigger picture, they'd see a few people consistently, again and again, accomplishing what you'd think would take a lot more people to do.
It helped that the first programmer also became the director for that area of business, and made sure that smart engineering kept happening.
Someone might look for a reason this couldn't work, and think of bus factor. What I think helped there was the fact that the work involved one of those niche languages that attract way more super programmers than there are jobs. "Gosh, if only we had access to a secret hiring pool of super programmers who were capable of figuring out how to take up where the other person left off, and we had a way to get them to talk with us...")
It was easy to imagine a competitor with 100 developers, not able to keep up, and at many points getting stuck with a problem that none of them were able to solve.
It started as a bespoke structured data and Web architecture, which did somewhat complex things that would've been a huge headache to build and maintain in the dominant languages of the time, but were viable for one person to figure out and implement in Scheme and PostgreSQL.
That bespoke architecture and implementation language lent itself to a lot of rapid domain-specific functionality, as well as doable architecture changes over time.
There's actually a bespoke object metamodel mapping atop the RDBMS, and it permits customers who want to use SQL direct to the database to do so.
And, IMHO, PostgreSQL is the default choice for most storage backend purposes, unless one has figured out a good reason something else is better. :)
There were also multiple kinds of large blob storage needs, and changing architecture needs over time (e.g., multi-tenant, changing authn implications of things like browser plugins, scalability, move to cloud), so systems programming skills and controlling your framework comes in handy, for not getting stuck or blocking on vendors, but just solving the problem.
Scheme, Common Lisp, Haskell, [edit] Smalltalk, probably more obscure ones...
Also, Erlang, Rust, and Clojure, though those have been rumored to be employable, so no longer get as much of the filter as you get when it was just people caring strongly enough to want to use a particular language despite the unemployability.
Whether that caring happened because of skill (to identify something good), or skill happened because of caring (to invest the time in exploration and thinking and practice), these communities seem to get more than their share of great programmers.
And so you know where to look for them, and you have a reason that they might want to talk to you.
A large system that was originally written by only two super-productive engineers (I mean real engineers, both with PhDs in an area of Engineering). And a comparably capable and essential IT person.
The reasons for the super-productivity include one of the developers choosing great technology and using it really well, to build a foundation with "force multiplier" effects, and the other developer able to build out bulk with that, while understanding the application domain.
Another reason was understanding and being pretty fully in control of the code base, so that, as needs grew and changed, over years, someone could figure out how to do whatever was needed.
One of the costs was that most things had to be built from scratch. Over time that also proved to be an advantage, because whenever they needed (put loosely) a "framework" to something it couldn't do, they effectively owned the framework, and could make dramatic changes.
When I said "costs", I mean things like, many times they needed to make a component from scratch that would be an off-the-shelf component in some other ecosystem. So if someone looked closely at how time was sometimes spent, without really understanding it or knowing how that panned out, it would look like a cost that they could optimize away. But if they looked at the bigger picture, they'd see a few people consistently, again and again, accomplishing what you'd think would take a lot more people to do.
It helped that the first programmer also became the director for that area of business, and made sure that smart engineering kept happening.
Someone might look for a reason this couldn't work, and think of bus factor. What I think helped there was the fact that the work involved one of those niche languages that attract way more super programmers than there are jobs. "Gosh, if only we had access to a secret hiring pool of super programmers who were capable of figuring out how to take up where the other person left off, and we had a way to get them to talk with us...")
It was easy to imagine a competitor with 100 developers, not able to keep up, and at many points getting stuck with a problem that none of them were able to solve.