Guidelines for Small Project Pricing

Guidelines for Small Project Pricing

Our collection of rules and red flags which help us navigate through every small project.

Intro

Over the past few years, I’ve had the pleasure of working on a lot of small gigs as a result of my plugin, Supersized, and our company, One Mighty Roar. I currently average about 3-4 small projects a week, most of them with new clients. Through these experiences, I’ve learned quite a bit about how to run through this process as smoothly as possible.

Our Rules

Projects under $1,000 are paid in full before work begins

Hourly rates are preferred to project pricing

If the project was misrepresented, refund and reapproach

Negotiate scope, not price

Save time by including a next step in every email

Projects under $1,000 are paid in full before work begins

This is a great way to avoid being held hostage by scope creep.

While it may be different for you, this number represents a little over a days work, which means it should be a relatively quick and painless project. I used to do a 50% deposit and 50% on delivery, but I found myself running into a lot of “Oh, I forgot to mention…” scenarios where additional features are requested and the final payment was withheld as a result. By taking the full deposit initially, you can re-approach any additional requests at a fairly valued rate, rather than have to cram them into an existing budget.

Projects over $1,000 would require a contract, and are a different story entirely.

Hourly rates are preferred to project pricing

There is some debate in terms of hourly rates vs project pricing, but for small projects, there are very few situations where I would feel comfortable with a fixed project price.

All quotes are hourly, this avoids being stuck with hours of unexpected QA beyond what was intended. If you are on a project price and their site code is a mess, you risk facing the “you touched it last, I hired you to make this work on my site, so you need to handle it” moment.

When integrating with their existing site, there is a risk being presented with unusable code which could add to time needed â€" or worse, be viewed as a problem you caused. For this reason, I always keep original copies of the pages I edit in case they need to be referenced later in the project, regardless of whether or not the client has their own backups.

If the project was misrepresented, refund and reapproach

This should happen the moment you realize you are not looking at what you expected, before you do any work. I have had scenarios where I was expecting to integrate with a static website, only to find it is WordPress and the expectation is that I create a custom plugin to work with an existing format. In most cases, thorough questioning and a clear scope could avoid this scenario, but you can never account for what clients view as”standard” and therefore fail to mention in your email exchanges.

When this happens, I alert the client and offer a refund, unless they wish to allocate additional hours. I typically get a “thank you for being up front with me” or a “there’s no way I’m paying for that, it’s not what we talked about”.

You win some, you lose some, but the important part is that it’s not your job to make the original hour estimate if it requires more work than anticipated.

Negotiate scope, not price

“I’m a startup with limited funding and am not looking for anything fancy â€" I just need this one simple thing…”

This line really only serves one purpose, it communicates that they are budget-minded, which means if the costs exceed what they were hoping for, it’s time to negotiate scope. It’s your job to inform them of the costs for the project, and if you’re so inclined, potential options within their budget.

Your hourly rate and time spent do not get discounted as a result â€" wanting more than you can afford is not a problem that falls onto the vendor. Outside the world of service based companies, it would be laughable if a BMW salesman was faced with a person would really “needed” a BMW, but could only afford a Kia. These debates should not happen and are a waste of time, if you have a simpler alternative, offer it, otherwise give yourself the luxury of declining the project.

Save time by including next steps in every email

Whenever possible I try to include as many questions and actionable items in the initial exchange with a new contact. Often I’ll receive a vague scope, which requires some clarification, but I still make an attempt to quote if possible. If I have a simpler or alternate way of approaching a project, I am sure to include that as an option as well â€" part of your job is to educate.

“If you meant the following… then it would be X hours. If this is not what you are aiming to do, then could you clarify…”

Giving the potential client a sample of your rates early on helps you avoid a series of project scope emails, only to find out they aren’t on the same page cost-wise.

Red Flags

We have a few red flags that that cause us to disengage with a contact and cut off future work. Every item on this list is backed with multiple personal experiences that could have been avoided â€" simply put, they are not worth the headache.

In-depth questions regarding refund policy.

Insisting on a project price with ambiguous scope

The promise of a donation if you add functionality specific to their project.

Hostility and feeling of entitlement

In-depth questions regarding refund policy

If you’re working at an hourly rate in a service based business, there is no refund policy. Extensive questioning regarding refunding should make you more uncomfortable than a person being a little too curious about your local bank’s security system. If someone has an odd number of questions concerning refunds, don’t engage with that person.

Clients need to respect that they are buying your time, and the results within that timeframe are a byproduct. If they run out of funding or become too ambitious for their budget, they can’t be allowed to view their project as incomplete and therefore demand to refund.

Insisting on a project price with ambiguous scope

Accurate project scope is a must. You wouldn’t expect an accurate quote from a contractor if you said “I want a house with a kitchen, bathroom, and living room â€" how much will that cost me?” (thank you to our Director of Business Development, Chandler Quintin for this one). The same is true when it comes to websites â€" I always clarify incoming projects with a simple bullet point list, to ensure nothing is overlooked.

Secondly, I am wary anytime a person requires a fixed price for a small project. While I can appreciate the need to allocate a budget, there is a certain amount of realization that comes with any project. I’ve walked into scenarios where the site code was unusable and would require hours of reworking to get where it needed to be. Even though the scope was clear, I couldn’t have factored in the state of disrepair of the site â€" something that is easily solved by explicitly stating projects are on an hourly basis.

Hostility and feeling of entitlement

When a potential client becomes abrasive upon hearing your hourly rate or estimate, even if they accept, it will not be a fruitful relationship. If they are greeting your initial estimates with hostility, imagine the reaction if additional QA or hours resulting from scope creep are needed. This is not a parking ticket, they can choose whether or not they want to agree to your rates â€" and if they do, it should not be a continued point of contention. Almost every time this has happened, the client escalates their expectations beyond what you arranged, based on the fact they are paying more than they anticipated.

“Well fine, if I’m paying that price I expect this to be done within the next 24 hours and you will provide a warranty if there are any problems with my site.”

We have something called the “headache tax”, which is reserved for folks that complicate the process by adjusting timelines, changing project scope, or being high maintenance in general. If you’re spending a good chunk of time fielding emails and phone calls regarding the project, be sure to factor that into your estimate â€" project management time is not free.

Promise of a donation in exchange for work

I will speak to this only in the context of custom work for an open source project, as it has been covered more than adequately for web design as a whole.

I frequently receive emails that go something to the tune of this:

“Hello,

If you add in this [insert project specific feature here] to Supersized, I would be happy to donate”.

Thanks.

As a general rule for Supersized, when time allows, I add in features that would benefit everyone, based on number of requests I receive for certain functionality. This is free for two reasons: 1) I dictate when I am able to work on it and 2) the features benefit everyone. As soon as either of those criteria are removed, it becomes a paid project.

If you do a few hours of work in exchange for the promise of an unspecified amount of money, you’re setting yourself up for disappointment. Donations are fantastic, but are not leverage to have discounted labor done. You wouldn’t do a job for free in exchange for the promise of future work, and prospective donations are no different.

What Are Your Rules?

While this list is entirely based on my own experiences, I’m curious what sorts of rules you have established for small projects. I’ll look forward to hearing what you folks have as guiding principles in the wonderful world of client work.

Powered By WizardRSS.com | Full Text RSS Feed | Amazon Plugin | Settlement Statement | WordPress Tutorials

I'm reading: Guidelines for Small Project Pricing