Payment schedule in responsive projects

When working on RWD projects, the project usually has a number of goals that have to be met, including different devices, breakpoints, content display requirements, navigational requirement, UI/UX requirements, etc. I find working on goal-oriented projects allows me to set budgets for reaching each goal, and a client can decide how far to progress or can change their minds without drastically affecting the whole project. That also gives you a point at which you can hand over the project if you get out of your depth on some feature requirements, which also allows the client to have a product that can be picked up by more skilled developers and still have a good relationship with you going forwards. Balance is important.

The price you charge probably should reflect achieving these goals. If you're using your templates, you can charge by time, which makes you cheaper and probably gets you more work, but will probably also make you do more work to earn the same amount as other teams that overcharge for the work they do using similar templates. Getting a balance there is tricky and it can feel like overcharging for simple work. But, when you balance up the simple work you do against the very complicated work you'll get down the line, overall, you're probably better off charging on the value of the result to the business rather than on your time, which is often and repeatedly undervalued, when you start out.

I would often ask the customer to select a template that closely matches their desired result from a number of available options, if that's a route the customer is happy with and if you're comfortable editing those templates. If that's not a practical solution, then you can recommend one, based on their requirements or your own work in the past.

When you start providing advice, you can start charging and when you start providing deliverables, you should have already had a contract in place and a payment schedule agreed. You will be taken for granted if you work first and ask for money later.

From that point onwards you can decide what deliverables you will provide and what the criteria are for success/acceptance, and how long they have to give feedback and how many changes are permitted or within scope, etc.

Being a bit picky around those criteria will help you have an understanding of the process and help your client appreciate the value of going through a process properly. Time will help you refine what works best for you.

Within that, though, you can decide your payment schedule.

It's important to have a rough idea of what you can do and how long it will take and what it's worth before you get into too much detail with a client. As a minimum, you should consider asking about how the site will be used by customers, what does/doesn't work, etc before you even begin to design based on the customer's understanding of what is needed. Getting your background / context right at the start will save you a lot of hassle in smaller projects. For example, the customer wants a sign up button on every page. Should it be shown on the signup page? You should question everything that makes sense to question before accepting a project. The client isn't the designer or developer and you should sanity-check the project before moving forwards.

I would not have the client pay on selecting a template. I would have an upfront fee that can be fully refunded if the first deliverable is not returned to the required standard.

Delivering wireframes that get signed off would be a good way to set your first milestone and payment point.

I would not deliver a wireframe that can be used by another company, though, until I'd received written confirmation that the client has approved them, which is then binding on them in a contract (which you have, right?). There are a number of online tools that might make this more trackable and provide ways for the client to give direct feedback to your wireframes.

I hope some of that's helpful.