> Paying for a working front end at a project price (can't take day-rate risk at this time) doesn't seem to incentivise writing maintainable code which my team will be able to look after for years to come.

This is a curious statement because time and materials arrangements don't guarantee maintainable code either. Poorly managed, T&M is more likely to incentivize billing than it is quality work product.

The keys to a successful outcome here, regardless of engagement structure, are:

1. Contract with an experienced freelancer with whom you've discussed the importance of code quality and maintainability. Screen out candidates who can't speak intelligently about these topics and can't point to real-world examples of quality, maintainable code they've delivered.

2. Establish clear requirements before the engagement begins and incorporate them into your contract. A fixed-price contract can actually provide you with more leverage in this regard, as you can tie milestone payments to code reviews. Of course, you must perform these code reviews and take them seriously.

I will certainly action these points - reviewed milestones seem like a solid approach.

Many thanks!

From my experience doing freelance, many clients simply don't care about maintainable code. In fact, it requires effort on my part in trying to convince them that it's worth their while to pay the extra time for me to clean up the spaghetti mess I inherited or otherwise to write something with the future in mind. I would imagine that any experienced, self-respecting developer would naturally want to develop sustainable code. Hence, I recommend (a) finding experienced, self-respecting developers and (b) letting them know that taking extra time to make sustainable code is okay. Aside from that, experience in working on or managing larger, long-term projects probably helps. A developer who has never maintained a project for 5+ years may lack awareness of how sustainability mistakes can happen.

If you keep requirement changes to a minimum during the project then that should help get you maintainable code from your freelancer, assuming they are competent enough to provide it.

I’m always eager to offer this to clients and I sleep better knowing I’m not going to piss off the next developer who has to look at my work. But with startups in particular, where requirements change every few hours, this really gets in the way of the planning and execution needed to write maintainable and scalable code.

Budget time for clean up after you get the deliverables. If you're bringing on the right person, hopefully they won't leave you with pile of messy code. But even if it's mostly clear and organized, giving them paid time to increase the maintainability and DRY it up will pay dividends in the long run. Obviously the trade off here is that it costs more, but that's something you'll have to consider for yourself.

There are some metrics that you can certainly require. For instance, a maximum threshold on cyclomatic complexity.

A less rigorous option is that you could require regular drops at which point you look at the code and only agree to buy the next drop if the existing drop meets your need.

if you dont want to incent them to work as maintainers, make it clear the project is one off, and calibrate a portion of the pay on how maintainable the code is.

if you assess maintainability when you see the code, make what you pay them depend on how maintainable you assess it.

if you assess maintainability over the lifetime of the code pay the freelancer a small retainer over that lifetime based on how few problems maintaining it there were.