iktorn

It seems like HN might need to think about subHNs

Nobody really calls me anymore. Even my wife knows I'm more likely to reply to her email than pickup the phone ;)

not really - there is a subtle difference

fair enough but I'm fairly sure that if you traveled in time from 5y ago with a decent developer from that time he would have hard time landing a job today

I'm testing http://launchlist.net/ right now. Looks solid

I think that's a bit different. Checklists are reusable and shared. It's not a one-time todolist

Colin,

which browser are you using? Looks good here.

good point. Weekly & daily rates are probably better as few commenters suggested.

It's not about the lack of skill on the supplier side. It's usually the client that is not sure how exactly the project should look like. And that's ok - he does not need to scope out every detail - it can be worked out along the way.

Our "response" to this is radical transparency. Client should be able to track the progress in almost realtime.

The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.

But than you are introducing overhead of deciding this. For obvious reasons this is something that needs to be negotiated with a client and documented.

"build only the features that customers can't live without" - who makes this call? What if you disagree on this? What if the customer learns something new after 2 weeks and needs to change the scope?

Very good points. One thing I don't really get though: "2. [...] If something can be done in a few hours, then it should be free."

Why so?

Mentioned it before in another thread here: This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting with a new product/service.

1) That is a big problem. Really hard to convince people you are more than 3x as good as the 3x cheaper alternative. But than again lawyers manage to do it. Why would web developers not figure it out? ;)

2) Yes. It does not scale in a way "startup people" are used to. It's just part of the deal :(

This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting.

One of the points in the article is that it's impossible (and impractical) to scope out everything before you start.

The problem with no 3 is that not every job can be measured in $$$. Especially when you are building an MVP and/or experimenting with features.

I think your approach is definitely valid for "traditional consulting" but a bit less so for more plain webdev work.

http://www.playdiplomacy.com/ :)

Great addition. Maybe even: quick decision-making based on a limited amount of information