Client Concerns with Weekly Pricing

After my recent post about Projects that don’t launch I had one of my awesome, current, clients reach out to me with a comment, which I’ll summarize below.

As a client I get way less worried about scope/project creep leading to malaise than I do about coding creep leading to budget panic. My ideal would be a fixed price for features and design that was on spec to the provided design.

Knowing I may lose hundreds or thousands of dollars to a bug (which takes time) or something that is harder than originally thought is scary.

See, this is why I love my clients. First, they read my blog and still come back. Second, I get personal, thoughtful, emails about how I run my business and we can enter into genuine discussion about it so we can both understand each other and be happy.

Now, let’s start by laying a bit of ground work before I really dig into the response I sent to my client. We’ve talked about the things below during previous projects, so I didn’t include them in my response.

Bugs Happen

The fact is that bugs happen in programming. Someone misses a comma or there is really an underlying bug in part of the platform you’re leveraging.

Recently I got stuck for 20 minutes with a very minor bug in Easy Digital Downloads. I couldn’t leave it because this minor bug totally broke my project.

I had to spend time tracking it down then finding a fix to complete a client feature. Then spent a bit of my own time in the evening reporting it and passing the fix along to the main project so that the next version of EDD wouldn’t have the same bug.

If you don’t want to deal with bugs happening (and needing to pay for it) then you need to stop getting custom software built. Use something off the shelf and live with the ways it doesn’t exactly fit your needs.

When budgeting for custom development somewhere between 10 – 30% should be allotted to simply cover bugs.

Things may be harder

Sometimes you look at a feature and think it will be easy (or hard) to build. Most of what I do as a software developer is build things that I haven’t quite done before. I may have done similar projects, but all the pieces never quite match up.

On a recent project I needed to add a second image upload field to match the design. I’ve done image up-loaders in WordPress before and have some code around that I’ve easily adapted to this use on a number of projects.

I figured that I could use it again, then I really dug into the existing forms and realized that it simply wouldn’t work without epic rearrangement of the core plugin.

Bad idea.

Instead, I needed to extend the current plugin to have an extra image upload field. This was simply going to take longer than my original plan. Mainly because I needed to do some research on the core plugin code and how it added fields.

Unexpected technical challenges is also something that happens when building custom software. Expect some part of the project to need more development time than you originally planned.

If you don’t like that then you really just need to use some plugin off the shelf and live with the ways it doesn’t fit your original needs.

My Response (at least the guts of it arranged for a blog post)

I really do understand the client’s desire for a totally fixed price. It gives them a budget and they can decide to spend other funds on marketing or whatever else the project will need to get off the ground and be profitable. I respect that and want to stay as close to my weekly estimates as possible.

I want clients to have the extra needed to market their projects. If they have a solid running project then that ultimately means more work for me. It’s in my best interest to build something that makes my clients money.

I used to price everything flat rate and once I decided how much a project would cost I’d mark it up based on the risk I was taking. So I’d charge extra to cover things like bugs or unknown technical hurdles and hopefully cover them.

Sometimes I’d be marking up 30% to cover the unknown, maybe even more.

Now what if a project had no bugs and no technical hurdles? I didn’t just knock 30% off the cost.

See, some project later in the year would have more challenges than I marked up for and that meant I was dipping in to the markup from previous projects.

That always felt wrong to me.

Now with weekly pricing I do my best to provide accurate time/cost estimates just like before. If I think there are technical risks I tell the client we may need an extra week right up front. Kind of a best case 3 weeks but probably 4 weeks thing.

If we really take 3 weeks because no technical challenges were hit, then they only get charged for 3 weeks. I don’t have to charge them more to cover some other client overage.

When I hit a project that has unforeseen technical issues I charge for the extra time it takes to deal with it. It’s only the client that had a challenging project that pays more.

With getting close to a year of data now I see about the same profits per project but I’ve been able to deliver many projects at 30% less cost than I would have previously. We hit no challenges so the client didn’t pay for any.

Trust

This requires huge amounts of trust from your client. Really I could make up “bugs” and make more money for basically doing nothing. It’s likely that the client would never find out and I’d just bank extra.

Of course I think long term clients would get “that vibe” from me and my business would suffer. I love it when my clients trust me and I never want to violate that.

Back to…

Now back to the client I referenced above.

When he read that post he had just needed to pay for an extra half week to deal with some technical issues. I didn’t want him to see me as a “money pit” with delivery of the MVP in question so we targeted 3 remaining items to complete.

I said that if those three things were not completed with the time allotted it was my problem. I’m taking the risk (and maybe unpaid work) to make sure we can deliver the MVP for testing.

That’s how I work to gain client trust and share the risk with them. As I write this I have one day left to finish off the final item. When I left the project today there was a bug that I don’t have solved. It’s a blocker right now so it’s certainly possible that I will be putting in extra time to find and solve it outside of my estimate last Friday.

It’s worth that bit of extra work and effort to keep one of my great clients happy. So I’m totally fine with taking that risk.

What about you, how do you deal with unknown technical challenges? I mean we’re usually asked for a cost at the beginning of a project, when we know the least about how it’s all going to work. There is always chunks of a project that are a black box.

photo credit: Apojove via photopin cc

4 Comments

  1. Ashley Irving June 3, 2014 at 6:59 pm #

    Thanks for this post, Curtis. I’ve been lucky enough to not come across any real technical bugs in my work lately, but I did have a project about a year ago that had quite a number of issues. The first thing that happened was there was a miscommunication about who was actually doing what. I thought I was handling all of the content, but instead someone else was in the development site at the same time. I learned quickly from that and we started working better as a team. It’s actually beneficial for me to be overseas as when I work on development site or am doing a launch it’s in the middle of the night for most of my clients.

    Anyway, there were still some technical issues that were unforseen and had to do with outside plugins and such that were necessary for the project. The site was still functional as some of the issues didn’t arise until it was launched, so I decided to put it on myself and didn’t charge the customer for any time it took to fix the issues as well as redo some of the work we had already done.

    • Curtis McHale June 3, 2014 at 7:07 pm #

      There is certainly a time to take some of the cost on yourself but many freelancers default to that option which is wrong.

      • Ashley Irving June 3, 2014 at 7:12 pm #

        Agreed. In this particular time the project was already behind and I had made the mistake of agreeing to an hourly fee structure, which I’ll never do again.

    • Ashley Irving June 3, 2014 at 7:11 pm #

      Adding to my previous comment, the way I handle projects is quoting a range of prices upfront. Once the client oks the proposal I can look more deeply into the technical challenges of the project, lay out what is going to be new and therefore a higher risk and adjust the final fees appropriately. Generally if there’s a bug I’m covered as far as getting paid for my time, but if it’s a bug or similar due to additions to the scope then I have a discussion with the client and sort it out.

%d bloggers like this: