I think I understand your point. A little bit of domain expertise might be worse than none at all -- pretending to be a mediocre trader or banker, for example.

The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities.

My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution.

I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code.

I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements.

Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.