I don't believe contracting of any type us needed for a feature factory. It is more when product and project managers hijack the roadmap (or even create a roadmap at all) and then March along adding things for the sake of delivering story points, and the "it was _my_ team and _my_ vision that built this", rather than building on others work.

I think a good D&D analogy is your group needs a fighter. Instead of leveling up your decent level 6 fighter to level 7,8 and 9, instead you start multi classing, picking up some droid abilities cause, hey, surely it's cool

Regardless, here is something that describes feature factory in more detail: https://www.productplan.com/glossary/feature-factory/

A huge part of feature factory, worth mentioning, is any lack of checking (let alone measuring), did we build the right thing?

I believe you had the luck of never taking part on the extremely demoralizing exercise that is somebody deciding on the next steps for the software, writing it down and passing alone to somebody that will manage the development of that written thing; at the same side, some developers come, get the written down, non-negotiable decisions, and make their best on creating that stuff, fully aware that their continuing employment depends on satisfying the letter of those acceptance conditions, and the salary amount must be justified every time by delivering that in a market-competitive time.

In a feature factory, the developers do not get to know if there is a roadmap or not. It's not of their concern, and the competitive nature of the bids ensures that they won't have time to think about it anyway.

I don't think that this arrangement is even possible for hired developers.

You just expanded my mind with that today. Well, so we can raise above the status quo, how else would development be contracted?

Any delegation of work from one person to another involves a loss of context and distorts incentives. The only way out entirely is to build your own software to solve your own problems.

See the principal agent problem in economics.

Unfortunately subsistence software engineering isn’t a viable profession because the productive capacity of a single engineer is limited. And we occasionally need physical stuff like food/water.

Include in the contract "non-functional" requirements (the distinction can be fuzzy with a good case to put some requirement in both categories, but it's a useful distinction nonetheless). These are things like how stable it is (uptime requirements, perhaps), how secure it is. How quickly can a new feature be delivered? This lets you require an organizational capability, but not a system feature capability. If it takes your contractor 6 months to deliver an update with a color change to a page background, something is wrong. Require more responsiveness, but also offer more responsiveness on your side (like if you have a QA/test team responsible for final sign-off or to answer clarification questions, etc.).

You don't want to mandate their internal processes, at that point they're not contractors they're your employees and you are essentially taking over their management.

EDIT: Grammar

I am wary of formal offshoring of development at all. Contractors can solve a few problems for small companies when they are also small and you have a trusting long term relationship. On any other context, contracting seems to always fail.

But the specific format of specifying the software, contract it away, and pay for feature size leads to the specific kind of failure that we call "feature factory".