For me, it depends on the type of problem I'm trying to solve. Specifically, I ask is it hard work or a difficult problem? (see also [1], [2], and HN commentary at [3] from a short time ago).

Hard work is something that a big corp can solve by throwing bodies at the problem. A proprietary data format or protocol but with an available, thorough specification (eg. a giant PDF from an international standard, an industrial protocol, and associated XML schema with a bunch of separate devices to talk to by just reading through thousands of pages of PDFs...). Another example of hard work is handling a high volume of support requests, just communicating to individual users might involve more hours in a single day than are available to a single user, and it might require supporting 3 shifts or 7 days a week, which a solo dev just can't do. These are tasks that a solo dev is likely to burn out on and which I would not entrust them with.

On the other hand, a difficult problem is something that can be solved by a single contributor, but which often cannot be solved by throwing bodies at it. The output may be something as tiny as a few hundred lines of code that realize a single critical insight. That insight might synthesize a lot of complicated and inaccessible concepts available only to someone who is an expert in multiple fields and who has experience gained over many consecutive years of work in a single field. A company that can put 20 people with 1 year experience and 4 year degrees on the problem may not ever come to that synthesis. For example, I've had the opportunity to work on some complicated coordinate systems and GD&T mathematics for multi-axis CNC equipment; just communicating the requirements to even highly competent engineers unfamiliar with the problem is difficult, much less actually implementing the mathematics and software required to accomplish the task.

Big organizations often make progress by, as the author of the linked post describes, following "Effective strategies [that] often consist of converting difficult problems into something that can be solved through hard work." But sometimes this analogy just doesn't exist. And often, the conversion process introduces leaky abstractions and waste. Really good big organizations realize this, and will farm out these tasks to solo contractors/entrepeneurs, work with research institutions, or (less popular lately) build internal 'think tanks' and R&D departments that can make progress on difficult problems, which the rest of the company can scale out with hard work.

Conversely, solo entrepeneurs need to understand when and how to transition from working on difficult problems to scaling out and delegating hard work. I'm currently waiting on a support request with a guy who is really, really smart, and really productive, but as his company scaled out from building one really innovative machine that solved a difficult problem, to building and supporting 20 of them at locations throughout the state, to now when they have lots of sales engineers, a manufacturing department, some traveling technicians, and some 600 units at locations all over the world... he never managed to transition out of his keystone roll at the top of the software department. He's got an ever-growing backlog of engineering change orders that all fall back on him, and while highly successful and valued, he's really unhappy because he's just completely swamped.

My advice is to carefully select what your product is and does. Is it something for which people would want to call in an expert? You'll be fine. Is it something for which they'd want frequent changes, extended hours of support, many years of operation, and that can be done by anyone with a modicum of competency? I'd rather find a bigger, more reliable company.

[1] https://drmaciver.substack.com/p/difficult-problems-and-hard...

[2] https://benjamincongdon.me/blog/2022/06/22/Mental-Model-Diff...

[3] https://news.ycombinator.com/item?id=31845144