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.
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".
