I have certainly seen ridiculously high estimates that indicate either incompetence on the part of the developers, or the developers preying on and defrauding the customer.

An ethical freelancer should not play these kinds of games, using the customer's trust and ignorance to get more money out of them.

In too many real contracts, when the developer discovers they grossly underestimated and have run out of money on their fixed-fee budget, they ask the customer to spend more. The customer now has a terrible choice. They are "pot committed" as poker players say. Can they enforce the original contract and estimate, losing any velocity and good will by calling in lawyers (and wasting money and time on that)? Does the work done so far have any value to them? I've seen developers hold their customer for ransom when this happens. And I've seen project budgets double through the use of "change orders," like the customer reviewing work in progress and asking for changes that the developer should have anticipated.

I once got a call from an attorney friend who told me his firm got an estimate for $20,000 to upgrade the law office to high-speed internet and set up every PC (15 in all) and two printers on a new LAN. Then $1,500 month for a maintenance contract. That number seemed high to my friend, not crazy high, but he had no point of reference so he asked me. I quickly found that Comcast had business cable service to that building for less than $200/month. The printers already had ethernet, some of the PCs did, the rest would need $20 ethernet cards. Then some cable and a router and few hours to install and set it up. I told him I would do it for $2,500 plus materials, no monthly maintenance fee, and just the monthly Comcast bill. That was in the pre-wifi days. I have seen stuff like this happen many times and to me it just looks deceptive and predatory.

> This is further clarified in the rest of the comment, but I wanted to call attention to this. Be really careful with this line of thinking. It's not an apples-to-apples comparison, especially given higher costs and potential downtime between contracts. I recommend billing about 30% more than you'd expect out of a salaried position.

I agree with most of that. 130% of base salary is a good guideline. Employers use the same napkin math to factor in payroll taxes and benefits. As a self-employed contractor you have to pay for all of your taxes (you will get some more deductions) and your health insurance (which you can usually deduct, though that particular deduction is a political hot potato). But yes, you need to consider the additional costs of freelancing when determining your rate.

As for downtime between contracts, I think it's obvious that's the freelancer's problem. You can't overcharge your customers to make up for downtime. If you establish trust and long-term relationships and get referrals you won't have a lot of downtime between projects unless you want to take time off. I had full-time hours as a freelancer just a few months after I started, entirely due to building some good relationships and getting referrals from satisfied customers.

If you intend to scour the freelancer marketplaces like Upwork, you will have both downtime and significant non-billable time spent on getting projects, negotiating and going through that process. Rather than thinking about finding the next project all the time, I looked for customers that needed steady work, either system admin or programming, or both, because they couldn't afford a f/t person or couldn't find/attract/hire. Lots of smaller businesses don't have resources in-house and couldn't find and keep a competent person even if they could pay a f/t salary. You only need a few customers like that. Leave the big green-fields fixed-fee projects to the larger outsourcing firms. I found cleaning up the mess they left was itself a lucrative niche.

To make a living freelancing you have to both eliminate unwanted downtime and reduce non-billable time, which mainly goes into finding the next project. I know some freelancers have effective "sales funnels" so they always have new work coming in. That can work. My approach was less sales and more building relationships that led to more work with a small number of steady customers, and solid referrals that I didn't need to find or sell myself to or bid on against other freelancers.

I have written before that you know you're succeeding as a freelancer when the customer didn't consider anyone else for the job. Winning 10% of the jobs you bid on means you wasted a lot of time on jobs you didn't get.

Big fixed-fee projects -- tens or hundreds of thousands of dollars and schedules that run for months -- open up too many opportunities for misunderstandings, and leave both parties exposed to owing or expecting amounts large enough to lead to lawsuits and arbitration. Instead I propose a more agile (in the original sense of the term) process, where the freelancer and the customer first break the project down into smaller pieces, in order, that have clear deliverables and price tags. That gives some advantages:

- More frequent review and feedback from the customer, which keeps expectations aligned.

- Less money at stake at any time for both sides.

- Customer sees constant and measurable progress, which will either make them feel better about the schedule and budget, or support discussions about a possibly unrealistic schedule and budget.

- Project has more velocity and more feedback loops. The customer develops trust in the developer for delivering, and the developer learns more about the business domain and the actual requirements.

I have seen many freelancing projects written up as fixed-fee that then go sideways. A couple of years ago a customer came to me after losing $65,000 on a web site rewrite that dragged out for eight months, and at the end what they got was not usable. Not a huge amount of money but that represented the customer's entire budget for the project. So we reviewed how that happened. The contract was typical: $65,000 total, half up-front to start, with vague requirements (a single page) and a schedule that seemed realistic before any work started. The developers staged exactly one demo site in eight months for review, got some feedback, then started billing for "change orders" based on their opinion that the customer was changing the requirements mid-project. Once the entire budget got spent the developers stopped work, demanding more money. Lawyers got involved, arbitration scheduled (mandatory in their state), that's still dragging on. No web site to show for it.

In hindsight it seems obvious the customer should have required the developers to maintain a staging site and push changes at least weekly, with a process for the customer to give feedback and change direction. If the project was broken out into iterations, with clear deliverables, the customer could have seen much sooner that the developer was off-track or not producing, and the developer would have known about requirements changes much earlier in the process. If they had decided to call it off at any time neither side would owe or expect tens of thousands of dollars.

Writing complete and unambiguous requirements for non-trivial software projects remains a holy grail of programming. Almost no experienced developers can do it, and in my experience customers can't even start -- they think in terms of how their business works but may not even know how to describe that in sufficient detail. Knowing this well-documented fact of software development that every professional should understand (since we've known about it since at least the 1960s), agile as described in The Agile Manifesto outlines an alternative approach based on frequent small releases, review and feedback, iteration, measurement. I think that approach has a higher probability of success, or at least lower probability of massive and contentious failure, than the usual price tag with vague specs as a one or two page exhibit on a boilerplate contract.

Focusing on deliverables forces both parties to define what they expect. Developers have a better chance of giving good binding estimates if they have clear specifications and bite-sized tasks with clearly-defined criteria for "done." The bigger and more vague the specs the more chance for misunderstanding, and those misunderstandings multiply and compound the longer the project goes on.

Programmers should expect requirements to change and details to emerge during development -- that is the norm when writing software, not an exception you submit a "change order" for. We're not assembling Legos -- we're writing new code from scratch and refining it until the customer agrees it's done.

"We need a new web site that lets our members list their talents in a directory. It should let new members join and pay online, choose their directory categories, upload photos and videos. We have several membership models and prices. We also want to show ads on the site." That was more or less the original spec in the contract for the project I described above. It had a little more detail but not much. The developers responded with mostly technical jargon: "AWS EC2 medium instance, Python/Django and Postgres back-end. Client will pay for all graphics, fonts, assets and provide full copy for web pages." I think it's obvious that combining the specs and the development plan, if you can even call it that, does not produce requirements anyone can estimate, schedule, or code from. It's just a recipe for conflict and disappointment.