>This is just another blogger to piss on Spotify for some strange reason to the point where they make up stuff.
Actually he discusses his reason, right there in the post. Spotify used a lot of his bandwidth with no way to throttle (as others on this thread have discussed), in a way that he didn't feel was disclosed up-front.
It's great that you love Spotify and get value from it, but don't jump on this board calling someone a liar and questioning their integrity because they don't get the same value from it.
I agree with you, I was way out of line when I called him a lier. The fanboy-ism may be a little to strong in me.
But, to the point, he never said how much traffic he was seeing, so in his case /any/ traffic could be deemed "a lot". All services these days use your network connection to some extent, but I'm finding it hard to believe that it actually may end up congesting your networking connection, without seeing some serious proof.
I can to some extent see his point where this should've been clear from the start of, that Spotify will make use of your upstream network connection. Hopefully Spotify will make changes so that at least the US-market get notified that they might end up paying their service provider a premium, just for using Spotify.
I've had clients with only a vague idea of what they actually needed, meaning that we essentially needed to design the product before we could quote it. We charged a nominal fee, which was discounted from the project if the proposal was accepted.
It doesn't depend on the case; it's a question of how you frame the project.
If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation.
Or, you can quote the project "blind" but structure it so that the client bears the risk; for instance, by quoting a fixed number of billable weeks with a "if you tell us by week N, you can get more contiguous weeks at this rate" clause.
Or, if the client is really worth having and the project is good, you can do enough design work to do a realistic proposal gratis, which is what we invariably end up doing, because we don't do projects that aren't worth doing that for.
But in no circumstances should your proposal itself be perceived as having a price tag. One consultant did that with us once and I had to talk my parters down off the wall against ending communications with them right there.
> If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation.
I guess this is ultimately what we did (had they turned us down on the main project, they would have walked away with the design spec). That's the standard policy now.
Yeah; I think I sounded pretty pedantic back there, so let me just say I don't think you're suggesting anything wrong. I'm just saying, I've seen fledgling consultants accidentally let themselves be perceived as billing for the proposal work, and I'm pretty sure that's a big mistake, worth calling out.
