Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community!
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.Start your free trial
Payment schedule in responsive projects
I'm wondering which might be the best payment schedule for little to mid-sized projects in responsive web design. (RWD).
How would you implement a payment schedule in projects that follow the approach on responsive web design as Stephen Hay describes it. (designing a responsive page from scratch)
How would you implement a payment schedule in projects that make use of templates.
Somewhere I read something about 30-50-20 (which seemed to be related to the waterfall model). Now that we are developing agile in RWD implementing this kind of schedule does not seem to fit anymore.
Do you have any experience regarding this issue? What I'm most unsure about are the exact points to implement a payment rate.
- For 1) Should the customer pay the first rate after the content reference wireframe?
- For 2) Should the customer pay the first rate after he decided on a html-template? and so on...
For smaller projects we would like to stick preferably with 2 payments,
Andrew Whitfield5,239 Points
Andrew Whitfield5,239 Points
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.