Live data from Hacker News

How I Earned A Lot More on Projects by Changing My Pricing Strategy

sixrevisions.com

21–30 of 70 posts

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#21

What do you guys think of pay by milestone? Client and seller both agree to a milestone with a checklist that, when complete, signifies the milestone is complete. This provides clarity, transparency, and predictability. As a buyer, I prefer milestones.

That's sort of difficult to compare, because you're paying by milestones, but you probably didn't get estimated by milestone, e.g. "if we make it to the 3rd milestone you owe us this much." Your vendor is probably assuming you want all milestones completed.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#22
post #8
post #4

Earlier quoted context omitted.

I would venture into guessing that the client wasn't told about this. If I was in a similar situation and I'd be told the company I'm paying to work on my project is outsourcing it, I'd think they're either a) they're too busy for me/I'm too small of a client for them, b) money is money so they're taking my project, but I shouldn't bet on spectacular results. Also, there'd be some broken trust involved. There would a…

Most boilerplate consulting contracts require you to notify clients of subcontracting arrangements, and many BigCo client boilerplates forbid subcontracting altogether. But so what? You talk to your client about a prospective engagement, then you build a "dream team" proposal that puts you on the hook for the performance of the whole project and makes you the single point of contact for all project matters, but then…

Nothing wrong with that so long the client knows, regardless of how it's phrased. I agree that a 'dream team' sounds much better, good point.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#23

What do you guys think of pay by milestone? Client and seller both agree to a milestone with a checklist that, when complete, signifies the milestone is complete. This provides clarity, transparency, and predictability. As a buyer, I prefer milestones.

That's sort of difficult to compare, because you're paying by milestones, but you probably didn't get estimated by milestone, e.g. "if we make it to the 3rd milestone you owe us this much." Your vendor is probably assuming you want all milestones completed.

Not sure what you mean? I'm saying the buyer has a project, and either the buyer or freelancer chops it up into milestones (in my case, I'm an engineer as well as a buyer so I can do this). Each milestone has a set price paid after completion. If the freelancer completes 3 milestones, he gets paid for each. If he completes 4, he gets paid for each. etc.

Not sure what you're saying?

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#24

Earlier quoted context omitted.

That's sort of difficult to compare, because you're paying by milestones, but you probably didn't get estimated by milestone, e.g. "if we make it to the 3rd milestone you owe us this much." Your vendor is probably assuming you want all milestones completed.

Not sure what you mean? I'm saying the buyer has a project, and either the buyer or freelancer chops it up into milestones (in my case, I'm an engineer as well as a buyer so I can do this). Each milestone has a set price paid after completion. If the freelancer completes 3 milestones, he gets paid for each. If he completes 4, he gets paid for each. etc. Not sure what you're saying?

Depends whether your milestones are measured in time, features, business outcomes. First would still be t&m - just be a larger unit than days; second would be classic fixed price billing (which incentivises low quality hackily bolted together solutions which will be a pain to maintain and extend); third would be value-based consultancy.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#25
post #13
post #10

Earlier quoted context omitted.

I'm completely on board with the "bill by the day, not the hour" idea. Having implemented it in our own consultancy, it's done wonders. But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable…

Yep, that's exactly what I'm trying to say. Thanks!

What I would suggest though is to bill by the day and find a way to measure what you have delivered against changes to a business goal

This is the next step after bill-by-day/week - linking your work to something they care about - using evidence collected by software.

To be fair this works even as an employee, a permie / contractor or a actual, gone next week contractor.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#26

An alternate pricing strategy that's worked well for me: charge by the "sprint" (roughly 80 hours) and peg it to an hourly rate. Now hire developers to help you with implementing the brilliant strategies you help come up with and make a reliable spread on the cost of your junior developers. Key: don't hire people to do things you can't do yourself, hire them to do things so you don't have to do them yourself. When I…

My plumber estimates and doubles for fixed price work. This is to cover the cost of e.g. discovering rotten floorboards under the bath halfway through replacing it. Paying a fixed price is on average a worse deal for the buyer, but most buyers think that paying by time incentivises low productivity.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#27
post #16
post #7

Yes! Note that you can get halfway to the place McDerment (and Patrick McKenzie) were at simply by not charging by the hour . Simply moving your pricing increment from hours to days or (ideally) weeks changes the conversation you're having with your client. McDerment had to develop serious sales skills to pivot inbound requests for website paint jobs to strategic marketing engagements. But you don't need sales skills…

Why is hour Also, since an hourly rate is standard and job postings say how much they pay by the hour, isn't it common to be rejected when you ask for a daily/weekly rate?

1. You aren't billing for time - you are billing for a deliverable that will be done during the day / week (or part thereof) billed.

2. This is not the same as contracting for BigCorp on a 6 month java position at 600 usd pday. That's close but basically an employee without benefits

3. If you move from 100 dollars an hour to 4000 dollars a week (8000 seems to be more norm - you won't work every week) then the high price is to get then to focus on deliverables and not think o you as a person on a seat for six months but as someone who proved the last project did well

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#28
post #10
post #7

Yes! Note that you can get halfway to the place McDerment (and Patrick McKenzie) were at simply by not charging by the hour . Simply moving your pricing increment from hours to days or (ideally) weeks changes the conversation you're having with your client. McDerment had to develop serious sales skills to pivot inbound requests for website paint jobs to strategic marketing engagements. But you don't need sales skills…

I'm completely on board with the "bill by the day, not the hour" idea. Having implemented it in our own consultancy, it's done wonders. But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable…

What didn't you like with fixed price billing?

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#29

What do you guys think of pay by milestone? Client and seller both agree to a milestone with a checklist that, when complete, signifies the milestone is complete. This provides clarity, transparency, and predictability. As a buyer, I prefer milestones.

Try a fixed amount per week with milestone bonuses. An agreed hourly rate for ad hoc work and changes wouldn't hurt either.

Re: How I Earned A Lot More on Projects by Changing My Pricing Strategy

#30

What do you guys think of pay by milestone? Client and seller both agree to a milestone with a checklist that, when complete, signifies the milestone is complete. This provides clarity, transparency, and predictability. As a buyer, I prefer milestones.

As a contractor, I avoid milestones like the plague. They're appealing to buyers because, on average, buyers use them to extort additional work out of the contractor or as an excuse to defer payment (because the contractor's only recourse is court). I used to make an exception and do milestone projects for clients I trusted, but I even got screwed by them. It's just too hard to estimate software projects for both sides to come out of a milestone project on top.

EDIT: Note that I'm not claiming that people who use milestones are evil. The problem is that milestone billing for software creates lots of incentives on the client side to underestimate and underspecify work, because the contractor eats most (if not all) of the cost of identifying those problems and negotiating to get the milestone revised to include them.

Post reply on HN