Secret Shopper, Angies List, Yelp reviews, and more. Many people claim to be expert raters, but their ratings are not objective, reliable sources for what to pay. The biggest source of conflict is whether to trust your own gut instinct, do some research on the Internet, and/or use services like Hipmunk, Orbitz, and the booking.com price estimator. ~~~ jacalata You didn't mention any of those, except bookings.com, which is just a more rigorous way of asking "what should I charge on my site" ------ bignoggins > A number of other variables might have something to do with the varying > outcomes, but it’s hard to find too many variables that reliably go up or > down when airfares do. Maybe I am looking for a needle in a haystack but it seems to me that there is a fairly good correlation between temperature and flight delay times and pricing. I live in the U.S. and I've noticed that summer peak pricing is more predictable than winter peak pricing. But I'm willing to accept my own anec data as evidence. ~~~ s3nnyy This: "Maybe I am looking for a needle in a haystack but it seems to me that there is a fairly good correlation between temperature and flight delay times and pricing." points out that all prices are correlated with temperature. If you know what I mean. ~~~ bignoggins Your points is not at all related to what I am saying. My point is that temperature isn't the only factor that affects prices. Things like time of day and day of week can all influence prices and cause volatility. ------ chiph One thing I've learned, and it's a hard-earned lesson from years of freelancing - is that the client won't pay for what they don't see. My rule: if it takes more than 3 days to deliver, just don't do it. Or find someone else who needs to get the thing done - who's got plenty of funds to pay for it - and who doesn't have a deadline looming (which is, coincidentally also a good indication they won't pay you anything). Once the client sees it on your machine, he's got an idea how long it will take you to get it out there. If it's going to take you a week, he's not going to think he'll get it back in 5 days. And that may be true because it's been 1.5 years since you sent the last version. So be realistic, and if something else comes up that's more interesting, take the time you saved and go do that. (It's going to happen). If you need to keep the customer happy, then you're back to writing the speedy-but-not-much-of-a-workhorse code. I hate that, because it gets very time-consuming. But if you work for a customer you like, and can avoid having to do it again, then it's ok. ~~~ x1798DE This is a really important point that is a big reason why I prefer small projects rather than large projects - when I have a 1 week deadline, it is mostly a one-time investment, since the worst case is that I don't find anyone else to take over the project. If I have a 12 week deadline and my client does not have budget for multiple people on the project, it is unlikely that I will find someone who will put in the time and effort necessary to finish in a week and keep the project on time. ~~~ chrisabrams This happened to me during my second year of college. I had a friend who was the top guy at a large tech company. One of his clients wanted a feature implemented in a week. It was one of the first things I ever developed, so I implemented it as requested (only took me about 1 hour since I was only 15 at the time and the client had to review). Six weeks later they asked for a slight modification, which only took me an hour to complete. Six months later they came back with something completely different, which only took me about a week, but they still needed me to do other jobs. From then on out they treated me like crap, and I eventually went back to school. I don't regret doing this because it made me see how things can change, but I'm glad I didn't start off my career the same way. ------ zhte415 I have yet to see any large development project finished. In all its guises: from simple database migration, to a complex CMS/website, I've had no projects complete and workable. Even the simplest projects, take 6x as long as promised or more, overrun, or fail. I know it's just one customer. I've seen more than one project go wrong. But this is always the pattern. Even my small apps take too long. It's been many many projects. All of them run into the most complex issues. Every project has at least one. Perhaps there is a point to all this, but I cannot even begin to fathom it. ~~~ nathan_f77 "This is why we don’t write tests." This is why we don't develop apps by following the steps on an article like this. We write tests so that we don't run into those issues and that means we make less mistakes. (And no, unit tests don't slow things down, they make them faster.) One of the big problems in our industry is that most things that seem like a good idea don't actually work. I've been developing software since around 1999 and I've only been successful a few times. I'd love to share the secrets, but the secret is the things that really work. I can probably think of a few cases where the things I've done work for small projects, but when I get larger projects, my advice doesn't usually work well. ------ chrisabrams The most important takeaway from this article is the importance of setting a goal for your team - a minimum goal that is realistic, yet challenging. My team (I run a web app company) is working on a product that we haven't yet developed, so we can get a better feel for what the right price is. We've got a few features that we know are "good", but we don't know if they're "good enough" to charge for. So we're estimating, and making goals. We already know our initial goal is too low because we can do everything for free. So we make it one step higher. Doing this actually seems to drive us all to do better work. Our estimates are more accurate now because it's more realistic. Also, it's good to see that we're getting more jobs done. The price you can charge doesn't go up until you've put in the work. I'm sure this isn't true of all the freelancers out there, but it's the same at my company. We have customers who are willing to pay more, but they'd rather use a competitor because of price. So we just busting our ass to make things that will appeal to them. I can definitely agree with the article - that having a goal, and using estimates are great. However, I do wonder if in some cases, we're over estimating because we want to be careful. It's a risk vs reward - we're willing to work harder, but if you don't succeed, it's going to be a lot harder for you to charge. I've noticed that when we've had a product decommissioned, the team morale tanks and it's hard to get anything done. I'm sure that's the feeling around the entire company. ------ alexpopescu There are so many factors that go into the final cost of an application: personnel, tools, time (coding + debug), hosting, physical location of the developers (in case of remote). I've been working for a few years now with small clients and I have a simple rule: \- _Never_ tell a client how much I have worked or the time spent. Because time is a very subjective variable and if we start using it to communicate cost, we're going to get angry and frustrated. The client will use this as an excuse to pay less. \- Always ask for a reasonable amount of time (and keep saying this _ad nauseum_ to the client). You might have to take into consideration the time needed for them to think about it, time needed for them to consult a third party for a quote, etc. \- Always tell clients the price. Then negotiate. When you sell to big companies, they have no idea what they are actually getting, especially if they're dealing with an inexperienced contractor. They trust their lawyer (lawyer: "The devil you know is better than the devil you don't" [1]). And keep in mind that what they believe is an expensive project for you