Here’s the fundamental question.
When will the client think they’re done?
If they think they’ll be done by June, then you put an Agile team in place. That’s 4-6 people for 6 months. That’s the budget. Essentially, you do the multiplication for them. team * rate * 6 months.
If they think they’ll be mostly done by June, but there will be more work after that, then you’re possibly looking at 9 months of work. Again, you’re just doing a multiply that they could do for themselves. team * rate * 9 months.
If they think that you’ll be their development team for the foreseeable future, give them a price that will get the project through to the end of the year. team * rate * 12 months.
Since each release is an opportunity to reprioritize, you should be pricing each release as as separate piece of work based on the things you will get done in that release. Since it’s their priority scheme, they control what you build, they control the budget, phase by phase.
Often your client really wants to know how much a particular feature set will cost. Instead of ask that, they ask about overall budget (which is silly). Spend a lot of time on the first release showing what they get and how much that first release will cost.
Eventually, they’ll see the fundamental truth.
They’re buying the features from most important to least important. If they prioritize correctly, they can stop spending money at any time and have something useful.
Done is a relative term. Some projects are “done” because there’s no more money. Others are done because there’s no more time. Rarely (at least in software development) is a project ever done because we ran out of things to do.