11 ms·

What’s wrong with billable hours

125 points by nickwritesit 3y ago

louwrentius 3y ago
I have to scroll pages and pages to discover the answer: take risk and sell fixed price because that’s what customers want and differentiate you from the rest of the freelancers. The whole article feels like asking GPT to add filler for the first 3 pages.
- teucris 3y ago
  I think the opening sections were necessary to define terms and clarify why an extremely well established system (hourly billing) might not be a good thing. It’s a nuanced argument and requires some verbiage. Maybe it could have been cut down a bit but I think it was important to include.
- ilamont 3y ago
  Standard SEO playbook - 1,000 words frontloaded with keyword-laded filler. It's particularly banal when it comes to recipes. "What is a cheeseburger receipe? Why would you want to cook a cheeseburger? What's the best approach to planning the best cheeseburger recipe? What cheeseburger equipment is required for the best cheeseburger? Oh, and here's the best cheeseburger recipe you were searching for."
dappermanneke 3y ago
[flagged]
PaulWaldman 3y ago
It's incredibly important to have a clearly defined scope prior to entertaining fixed pricing. If expectations are not established with the client, they will make assumptions and they won't be in your favor.
- CuriousCosmic 3y ago
  Also have pre-established policy for revisions. Like 2 minor revisions included in the cost but then have further revisions priced by how complex they are.
  - PaulWaldman 3y ago
    It's best to shy away from explicitly including things like "2 minor revisions". Who determines if the change is minor or not? The client will always assume minimal effort is required. If the change is in fact minor, then just implement it. If the change is significant, then provide a price for its implementation. Specifying that minor revisions are included in the agreement provides too much ambiguity.
  - swader999 3y ago
    Then your interacting with your client in a rigid contractual way instead of a collaborative creative nature. Not nearly as fun and you spend a lot of time being very careful with your written words and your sign offs.
- Goronmon 3y ago
  If expectations are not established with the client, they will make assumptions and they won't be in your favor. I think you can shorten this statement even more. Clients will make assumptions and they won't be in your favor. The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started.
  - PaulWaldman 3y ago
    >The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started. These need to be handled as separate change orders. Following the model, price the scope changes appropriately based on clearly defined requirements. This part takes some finesse. Many clients may not realize how they can achieve their goals in the most cost-effective manner.
the_af 3y ago
Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows). I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for very specific cases), so either your customers will try to do feature creep or they'll accept the initial specs and be disappointed, and probably blame this on you.
- atoav 3y ago
  As a freelancer I always told my customers how many hours I plan to work for them, including a rough overview of how much time we use at which phase of the project and what is expected of them. And I do that before I agree to work for them.
  - the_af 3y ago
    Interesting. Wouldn't that require a firm understanding of the project scope and a steady hand at rejecting any attempts at feature creep or redefining the scope (with the politeness required for not losing them as customers)? In other words, wouldn't this scoping and pre-planning go against the latest findings of lowercase agile?
    - atoav 3y ago
      That depends entirely on the type of projects you are known for (read: are willing to take). Some software projects agreeably will be next to impossible to estimate, others not so much. That being said I always bill per day of work, rarely ever a fixed sum (in fact only for good friends that are poor artists). So if the scope changes and there are more days, they know my rate and it will be their decision if they want to pay for that. Also they will have the insecurity of me not having time because I work on other things — risks that I clearly communicate before they agree to have me. I expect a certain amount of changes and feiction that is included in my original estimate, so this "extension" period is rarely ever needed and when I am faster the customer has to pay less than they expected which typically makes them happy. It doesn't always work that flawlessly, but it was never catastrophic and my customers value the up-front clarity.
Closi 3y ago
Entirely disagree with this post. I do a combination of fixed price and time and material work. Sometimes fixed price is a good model, sometimes time and material is a good model. Fixed price works when you know the scope, and are confident that there won’t be roadblocks and rabbit holes. If a project takes longer than you think, you are eating the difference. There’s nothing wrong with charging per hour if you know the value of your hours. Charging by hours gives you a level of certainty regardless of scope change. IMO the smart consultant/contractor will use both models, then pick the right one for the project and client.
- ghaff 3y ago
  To give a specific example with respect to writing. Want an article, blog post, or somewhat longer customer-facing material. So long as I know something about the topic and know where to go to get more information (maybe from you!) I'm happy to quote a fixed rate (+/- word count requirements). I have a very well-calibrated sense for how long this sort of thing takes and I'll put in some language about review cycles, etc. If you're a law firm that needs an expert witness report, I'll almost certainly charge an hourly rate (which is what the law firm likely expects anyway).
davedx 3y ago
Very long winded opinion piece with little substance. As an hourly billing freelancer, my only reply to this article can only be “so what?”
ddkto 3y ago
Professional business people are familiar with different business models, and when to apply them. For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk. Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. Being a professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation. (edit: spelling)
- sanderjd 3y ago
  On the flat rate model: I like to tell the story that the highest hourly rate I've ever earned to date was as a college student when I took on a fixed rate project to fix some department's "we have a web form that is critical to our work and backed by this perl cgi script that used to work but doesn't do anything anymore" problem. Turned out someone had uploaded the perl script to a Linux server using dreamweaver on a Mac, and the line endings were wrong. So I ran dos2unix on it and added a blurb to some documentation on what not to do and how to fix it again if necessary. Made $1000 for less than 15 minutes of work! But of course I also could have spent two weeks bashing my head against an awful perl script, never figured it out, and made nothing. It's a risk/reward trade-off.
- fallat 3y ago
  > when the client has a specific, measurable problem that they don’t know how to fix (but you do) Then the client tells you that wasn't their problem in the first place. In the 10 years of contracting I've never done fixed rate for the reason the client never knows what they exactly want. It's not like installing a tiled floor or drop ceiling. Being a professional means a lot of things, but fixed rate contracting is amateur hour truly. Every software dev learns this eventually.
  - r00fus 3y ago
    Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).
tptacek 3y ago
Billing hourly is bad, but you don't have to give up time & materials billing altogether. Just charge a day rate, or a weekly rate.
- the_af 3y ago
  I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
  - Keyframe 3y ago
    Discount
  - MassiveBonk51 3y ago
    Less granular time tracking for both parties.
  - ozim 3y ago
    Mostly that you don’t have to haggle over hours or 30mins here or there. If you do daily or weekly you don’t register time in 15mins increments to later argue with the client.
    - the_af 3y ago
      So it's basically to avoid time micromanagement? A solid advantage, I'll admit, but I don't think that's the main thing TFA takes issue with.
  - tptacek 3y ago
    In one case, you bill for each hour you work; in another, you bill for any day in which you did work.
    - the_af 3y ago
      Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? It seems to me there's no fundamental difference for the context of this article; it's still flat rate vs unit-of-time based work, isn't it?
alxmng 3y ago
It depends. I do plenty of billable hours augmenting software teams. I'm delivering user stories every week. There's simply too much communication overhead in preparing weekly estimates for the same client. I don't share the perspective on hourly making someone a commodity. Fixed outcomes can also be commodities. Clients can and do shop around estimates for the best price. The race to the bottom exists whether you're billing by hour or by outcome. You avoid the race to the bottom by what you sell, not how you bill. Wordpress themes are mostly a race to the bottom, regardless of how you're billing.
- swagasaurus-rex 3y ago
  A large organization might prefer billable hours because they already have thousands of employees on a recurring accounting schedule
ChristopherM 3y ago
I charge by the hour and will never change. It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum. You see they are paying for my time, not results. If they choose to waste it... doesn't matter to me, it's all billable just the same. I will do my best to steer them in the right direction to save time and money, but you'd be amazed how often they need to learn the lesson the hard way. I also don't compete, I'm not on any "freelancing" websites, I don't apply or bid for work. My clients always come to me, I get an email, a phone call asking if I'm available. So this race to the bottom nonsense is utter crap. I'm a consultant NOT a freelancer. I've been doing this since 2011, that's the last time I had an employer. This year I'm on track to bill out between $360k and $400k. If that's "amateur" so bet it. Considering I have no debt, my house is paid for, my luxury SUV I paid cash for, my actual monthly bills are around $2,500 a month. I really couldn't care less what someone who writes an article like this thinks of me. The writer is advocating for the client, they aren't giving me advice that helps me. I also have no interest in scaling, on bringing on employees. I'm making bank, I left CA in 2013, currently live in Wyoming with a 40 minute drive to Park City UT and a 60 minute drive to Salt Lake City. To anyone reading this article and thinking they are offering you helpful advice, consider their motive. What are they trying to sell you? Are they trying to change the current consulting landscape to benefit themselves as a business owner?
- mmckelvy 3y ago
  What kind of work do you do?
- hello_moto 3y ago
  I see that your niche is in C/C++ world (with some Obj-C), low-level stuff. Mind if I ask how's the market and what kind of clients (companies?) that you worked with? If you don't feel comfortable sharing the list, would you be able to share some hints? Out of curiosity because my background in college is more towards System programming but life puts me as a full-stack and backend/cloud engineering. Gettin a bit tired with too many backend tech (too many different storage solutions, backend languages, etc)
PeterStuer 3y ago
I hear what he is saying, but he stops half way where he says 'take responsibility for outcomes'. You see. In business this is translated into fixed price projects. But in contrast to the name there is nothing fixed price about it. As a provider of such project deliveries, unless you truly are an 'amateur', you still are acounting cost plus if the project goes into overruns. The way you do this through 'change requests'. You see, you can't nail down a contract taking into account every possible interpretation of details on a bespoke software project. So the customer will always need to clarify and adapt. This will be translated by your sales team into additional costs until a margin is met. The only way out is using of the shelf product, and even then you will probably have an 'integration project'.
- mdgrech23 3y ago
  I think the lesson here is bespoke software is probably a bad idea for a lot of companies and you're better off buying off the shelf shit. I think this is particularly hard for a fortune 500 company though, especially for something like a website. You're too big for a Wix site but employing a team of developers is going to cost you an arm and a leg and it's really not in your wheelhouse. We'll probably see more software outsourced going forward.
more_corn 3y ago
Don’t feed the trolls
gatinsama 3y ago
I have been a fan of Erik for 6 years now. If you are happy about where you are in life and are making close to half a million dollars a year, like some on this thread, feel free to ignore his advice. If you are stuck in the race to the bottom and wonder why, for example, the company's management doesn't pay attention to anything you say, then read his blog.
jkaptur 3y ago
I tried this. A very large company reached out and asked for a custom version of diffdiff.net. They asked what my hourly rate was, and (thinking along the lines of this article) I offered to do it for a flat rate instead. They ghosted me! In retrospect, a "very large company" didn't reach out, a relatively junior person at the company did. I should have worked within their constraints. (Or just not taken the job, which, I guess, is effectively what I did).
d_sem 3y ago
To each their own I suppose. In my personal opinion, hourly billing is economically aligned to better product-stakeholder fit. Without economic cost, stakeholders seem to tend toward over requesting / flip flopping resulting in a worse product. I've experienced this in larger B2B projects where those customers who paid monthly where incentivized to filter out the things they don't need and focus on the high value functionality.
nico 3y ago
When first reading the title, I thought this was an article about consulting and legal firms About 90%+ of the work you get from these companies is done by their junior employees, even if the senior partner that sold you swears otherwise Especially if you are not one of their top clients For most companies, it’s better to get a small firm or an individual. You’ll get better communication, better work and sometimes even better price
mk_stjames 3y ago
One thing I've noticed more now that I read HN more than other places... Software people sure like to talk/write a lot of about their business. Like, a lot. I'm a mechanical/aerospace engineer, and I've done some short term consulting for startups (but now mostly retired). There is verrry little online in the form of blog posts like this mulling over how people work in that type of engineering (especially in the higher-end of the field, like what happens in automotive and military/commercial aerospace- it's all very closed-doors). Especially less in the methods/metas of the field and the business surrounding it. But software people? HN is flooded everyday with long form exposition just like this blog post. And it's honestly been pretty eye opening reading how much people pontificate in this area. Like, goddamn. I'm starting to think people talk about their ways of work more hours of the day than they actually.... you know... work. << Just an observation; don't kill me. >>
- NoboruWataya 3y ago
  I think it's startup people, rather than software people. You don't see as much of this kind of discussion in other software developer forums. Building and running a business is its own field of expertise. If you think software people talk a lot about it, you should hear your average MBA!
- jzb 3y ago
  Corollary: Take a generalist observation about any type of creative work, stick "developer" somewhere in there, and act as if developers are unique and/or the observation is new. Example: Not long ago I kept seeing some variation of articles about how meetings are bad for developers. Specifically developers. Guess what? This is true for pretty much any creative type work like writing, design, or any type of work that involves deep thinking. But it was treated like a revelation because it was about developers and made no case for all the other workers in the same boat. This piece? I could've written this 20 years ago as a freelance writer. Generally I refused to stick an hourly rate when dealing with clients for lots of reasons, not least of which that when I know a topic and it's in my wheelhouse I write very fast. (And if I struggle with a topic, it isn't on the client to pay for extra time...) My dad could've written it 45 years ago as a sign painter and pinstriper. He charged by the job / value of the work delivered, not by how long it took to do. (Insert Picasso anecdote about "but that only took you 30 seconds," "yes, but it took me a lifetime to learn...") At the time his craft was highly valued, hard to learn, and the difference between a good sign painter or pinstriper and a bad one was enormous. If there'd been a Hacker News for his field, maybe we'd have seen the same thing. Then came vinyl signs...
m3kw9 3y ago
Is this the equivalent of pointing out people eating alone at restaurants because he thinks it’s weird? Contracting can be good and the downward pressure stuff is false because of trust issues and networking effects.
deleted 3y ago
[deleted]
swader999 3y ago
This is nonsense. The same assertions can be said for, I'm an engineer, level 2, so here's the yearly salary.
shireboy 3y ago
I've been a consultant for 15+ years and have often come to this conclusion that hourly billing is not ideal for various reasons. I haven't found a great alternative, and the problem is I'd want a great alternative I could enthusiastically sell to my clients. "Always do fixed price" doesn't seem feasible when scope is not fixed, fixing it would necessitate time-consuming research and waterfall style project management, and clients often don't know scope until they have tangibles in hand. (ie "this looks great, but can you do this "little" thing we invision in scope, but you invision out-of-scope-but-not-worth-arguing-about"") I feel like a retainer of sorts may make sense, but that seems a hard sell for some projects. "Make us this 5 page app that does XYZ". "Ok, pay me X/mo forever". Both consultant and client would need an exit that I'm not clear on. Also, to be honest about it, the consultant should limit their clients to some reasonable number so that they can serve them in reasonable time.
TuringNYC 3y ago
Some clients are absolute pains with flat costs. They argue over scope, then argue over the definition of done, then they argue over features that were not in scope and refuse to pay you until you do them (for free.) For these "special" clients, I found the best model to be a pre-paid declining balance retainer. Nothing gives more focus to clients than a slowly ticking meter. Further, i'd set the rate to be something that is worth even bothering with such clients.
dalore 3y ago
This doesn't account that software is (relatively) easy to change, vs say building a house (to use a cliche). The client will want to see it as it progresses, and then change based on what they have learned is possible. This is the agile way. How would one account for a fixed cost then? Do you say ok it's a fixed cost, and you get 6months base on our estimate (but if the 6months has finished the contract ends, and isn't that just a time based project). Or do you tell the client no changes after the initial requirements (which doesn't sound flexible and you end up building something the client doesn't want)?
addisonj 3y ago
Heh, it seems like this article could easy be called "hourly billing considered harmful" and I would basically have the same critiques of it as most "<popular tech> consider harmful" posts. I won't pretend I have years of experience in the freelancing world... I am fairly new to it myself. But I do know as engineer who also has done some stints in product, sales, and business side, that, just like in software, there is no one "right way" and that one of the most consistent challenges business face is choosing the best of many reasonable options, especially when one of those choices is viewed as a "best practice" but the team lacks the direct experience to answer the question of "best practice for who and when?" I fully agree with the author that there are some real market forces that can make hourly work not the ideal for many situations... but I also think it massively over simplifies the different types of work that are done as "freelancing". Whole new products, new features in existing products, taking over projects, rescuing projects, consulting with less experienced teams, embedding in teams, integrations of external tools, is probably only 25% of the type of engagements a single consultant may come across and probably only 1% of the type of engagements that exist. Combine that with the huge range of attitudes of companies and very quickly we are in a space where no single solution exists. It seems like the author's true point is in the conclusion, that you should focus on driving value and results for your customer and you should structure work to align with that, which is absolutely true. The general take of "hey engineer guy who isn't as business savvy, that value might not be best delivered via hourly billing!" is not bad advice. If you do hourly billing because it is the most straight forward, you should probably think about it... but you also shouldn't move to project based billing because of some people calling it a best practice either. My advice to any engineer looking to freelance (but really to almost anyone everywhere in this industry) is to not take the easy way out when facing decisions outside your domain. I think so often work seen outside of code is seen as "lesser value", and because of that, shortcuts are made by just taking the easiest or "best practice" answer to a problem and running with it, and not gaining any understanding of the problem space. No one can be an expert in everything, but when you can't make this decision someone else's job, like when a business doesn't have some expertise (which in freelance is always the case) then you can't afford to not put in the time to learn enough to at least be informed. If you then do decide to do the easiest / best-practice thing, at least you know why you choose that option and can later evaluate how it is working for you. In summary, there is no simple answer, be thoughtful and keep trying new things. What works for one gig may not work for another.
leepowers 3y ago
When you bill by the hour, what you’re really saying is “I have no idea if what I’m doing will have any value, and I honestly don’t care — all that matters is that I am not exposed to risk for even a single minute of my time working for you. I get paid for every minute.” Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise. Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities. The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes. Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000". The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses. The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity. Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity. In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.
dusted 3y ago
Interesting read. My freelance work has never been by the hour, and for reasons that align with those mentioned in the article. Clients don't care about hours I spend, my hours bring no value to them. They desire a certain result, and they know how much that result is worth to them. For my freelance tasks, I've put forth a rather steep one-time price for the solution of the specific problem at hand. The condition: The price is paid when the problem is solved, if not, the service was not delivered, they don't pay. This works out beautifully for the client, they run no risk (except the delay in waiting for me to fail so they can try someone else), and they know exactly what they pay. It works out nice for me, since I have a reasonable idea whether I can solve the problem or not. Hourly rates for those tasks have been close to $1000, including failed tasks where I spent some days not solving the problem. In the end, it's also very fair to both parties.. It's reasonable to expect the agreed-upon result when paying someone to do something. It's also unreasonable to expect to get paid for not doing what was agreed upon. A concrete example I can talk about was a client whose database had started "acting up a lot" and they had no idea what was wrong, they were very friendly and told me they had contacted another company too who had quoted an hourly price around $200 but were unwilling to estimate how much time they would need, since they didn't know what the problem was. So I said, "I'll try and fix it, if I succeed it'll be $4000", that's a fair amount of money, sure, but it was pretty good value to them to get their inventory database back up. It turned out to be an unhandled edge-case that only showed up years after when they introduced a new kind of item into the database. I had to learn a little bit of VBA(!) to fix it, but in the end, it took about 2 hours, and you might argue that price is too much for those two hours, but they didn't pay me to spend 2 hours, they paid me to get their database working again.
exclusiv 3y ago
This is nonsense. If you bill fixed, then you're doing it wrong if you estimate so lean that you put yourself at risk. And it's a disservice to the client if you are really conservative and they pay a lot more than T&M would have been. And if you are spot on with your fixed estimate, then that's the same outcome as T&M lol. If you are an honest person and do business the right way, T&M is the way to go. If you want a higher effective hourly, then you would pad fixed. That doesn't make you professional though; it makes you dishonest if you purposely inflate. If the company needs it to be fixed to compare apples to apples or their finance dept requires it, then submit your fixed scopes and run your business. It's professional to be flexible. And to not fight client processes and procedures. You will not win a lot of great business if you have only 1 way to run your projects. Some larger companies will take a vendor that costs way more but offers better terms like net 45 or net 90. I'm a professional. I run a business with employees that's grown every year. We do both, but it's better T&M. All time is logged with descriptions of what was done. We bill based on seniority. We still do time estimates on items that are T&M so my team is accountable, thinks about their approach and time, and so the client can have an idea of what they are committing to. They don't care if it goes over, it just can't get out of control. And they need this information to triage and approve requests. T&M with time estimates is a professional way to go. Some of your estimates will be off, some will be under. Just make sure clients understand that and traffic your wins and losses. And if you find out your 24 hr task is going to take 60 hours, notify the client as soon as you discover that to avoid surprises. I'm experimenting with a more traditional contingency budget which is explicit in the estimate. In that manner, a fixed bid would be done but the client would be aware that there could be unknowns that result in tapping the contingency budget. And if it's not tapped - they don't pay it. So rather than try to bake the unknowns into the fixed which the client would pay regardless, I can have the contingency reserved if needed but be more palatable against a competing bid that wraps it into their fixed. So say, 100k fixed bid, separate 20% contingency for unknowns for my bid. Versus another company's 120k fixed bid, no contingency. Both possible 120k spend. One may not use contingency and thus be 20k cheaper. The other - 120k is paid no matter what. Anyone do that on their larger projects? How is that received?
nico 3y ago
Most legal firms do something in between, you pay a retainer or a minimum package, and then they bill you hourly They get the money upfront, before they do any work So, from the get go they know the minimum they are going to make, and they never get stiffed (also because most people don’t want to get into legal issues with a lawyer)
felixarba 3y ago
I found this article helpful. Most comments on here seem to suggest that hourly is best done when clients don't know what they want, and I think that actually misses the point of the article, in my understanding. Working with a few customers as a freelancer, I agree, a lot of time they can't express what they actually want. They know it when they see it, but they can't express it correctly so you end up building a product, and having a thousand change requests - basically the customer uses you as a prototyping machine until you build what they want. Obviously this can't work with fixed pricing, BUT this is where the point of the article comes in. If the only thing you can offer to your customer is writing code based on a requirement - you're racing to the bottom because thousands can write code based on a requirement. BUT, if you focus on outcome - I will build you what you want, AND I'll help you figure out what that is!! That service will include asking the right questions, helping the client figure out what they want, and you can put all of that in your fixed price offer. At this point you aren't just writing code for them, you are their business partner, you want them to succeed, and you will use your experience to offer advice. If you become good at this, you are much more than just a programmer, or what the article calls "technician". So, thanks for the article, I found it interesting and have some food for thought.
iainctduncan 3y ago
This article is amateur hour. And by that I mean "amateur" in the sense of "lacks the business experience to see past their own narrow experiences". I work for a consultancy that works for some of the biggest investment funds in the world. We do some flat rate and we do some hourly. Sometimes hourly is exactly what the customer wants and is aligned with our interests. Sometimes it's not. I have also freelanced successfully with the same experience, and as a customer there are things I absolutely want hourly. For example, discovery should always be hourly, or you screw it up by making discovery that leads to a no-go conclusion unlikely, even if no-go is the Right Thing. One of the best things I ever learned for consulting was how to do this - clients who have paid you a reasonable fee to discover that they are not ready to go ahead will be talking about your honestly and credibility to anyone who will listen. Managing when things should be hourly or not is a huge part of what builds credibility. Blanket statements about how one should never be trying to do hourly work reveal nothing but business ignorance.
jjk166 3y ago
If the scope is fixed, you're selling a product. That product might be a one off, and it might be purely a service product, but it's still a thing to be sold at a price. Generally consultants are not selling a product. They are hired to bring knowledge and experience to a team, to be there when needed, and to offer flexibility for which it would be time and cost prohibitive to develop an internal employee.

125 points by nickwritesit 3y ago

I have to scroll pages and pages to discover the answer: take risk and sell fixed price because that’s what customers want and differentiate you from the rest of the freelancers. The whole article feels like asking GPT to add filler for the first 3 pages.

teucris 3y ago
I think the opening sections were necessary to define terms and clarify why an extremely well established system (hourly billing) might not be a good thing. It’s a nuanced argument and requires some verbiage. Maybe it could have been cut down a bit but I think it was important to include.
ilamont 3y ago
Standard SEO playbook - 1,000 words frontloaded with keyword-laded filler. It's particularly banal when it comes to recipes. "What is a cheeseburger receipe? Why would you want to cook a cheeseburger? What's the best approach to planning the best cheeseburger recipe? What cheeseburger equipment is required for the best cheeseburger? Oh, and here's the best cheeseburger recipe you were searching for."

dappermanneke 3y ago

[flagged]

PaulWaldman 3y ago

It's incredibly important to have a clearly defined scope prior to entertaining fixed pricing. If expectations are not established with the client, they will make assumptions and they won't be in your favor.

CuriousCosmic 3y ago
Also have pre-established policy for revisions. Like 2 minor revisions included in the cost but then have further revisions priced by how complex they are.
- PaulWaldman 3y ago
  It's best to shy away from explicitly including things like "2 minor revisions". Who determines if the change is minor or not? The client will always assume minimal effort is required. If the change is in fact minor, then just implement it. If the change is significant, then provide a price for its implementation. Specifying that minor revisions are included in the agreement provides too much ambiguity.
- swader999 3y ago
  Then your interacting with your client in a rigid contractual way instead of a collaborative creative nature. Not nearly as fun and you spend a lot of time being very careful with your written words and your sign offs.
Goronmon 3y ago
If expectations are not established with the client, they will make assumptions and they won't be in your favor. I think you can shorten this statement even more. Clients will make assumptions and they won't be in your favor. The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started.
- PaulWaldman 3y ago
  >The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started. These need to be handled as separate change orders. Following the model, price the scope changes appropriately based on clearly defined requirements. This part takes some finesse. Many clients may not realize how they can achieve their goals in the most cost-effective manner.

the_af 3y ago

Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows). I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for very specific cases), so either your customers will try to do feature creep or they'll accept the initial specs and be disappointed, and probably blame this on you.

atoav 3y ago
As a freelancer I always told my customers how many hours I plan to work for them, including a rough overview of how much time we use at which phase of the project and what is expected of them. And I do that before I agree to work for them.
- the_af 3y ago
  Interesting. Wouldn't that require a firm understanding of the project scope and a steady hand at rejecting any attempts at feature creep or redefining the scope (with the politeness required for not losing them as customers)? In other words, wouldn't this scoping and pre-planning go against the latest findings of lowercase agile?
  - atoav 3y ago
    That depends entirely on the type of projects you are known for (read: are willing to take). Some software projects agreeably will be next to impossible to estimate, others not so much. That being said I always bill per day of work, rarely ever a fixed sum (in fact only for good friends that are poor artists). So if the scope changes and there are more days, they know my rate and it will be their decision if they want to pay for that. Also they will have the insecurity of me not having time because I work on other things — risks that I clearly communicate before they agree to have me. I expect a certain amount of changes and feiction that is included in my original estimate, so this "extension" period is rarely ever needed and when I am faster the customer has to pay less than they expected which typically makes them happy. It doesn't always work that flawlessly, but it was never catastrophic and my customers value the up-front clarity.

Closi 3y ago

Entirely disagree with this post. I do a combination of fixed price and time and material work. Sometimes fixed price is a good model, sometimes time and material is a good model. Fixed price works when you know the scope, and are confident that there won’t be roadblocks and rabbit holes. If a project takes longer than you think, you are eating the difference. There’s nothing wrong with charging per hour if you know the value of your hours. Charging by hours gives you a level of certainty regardless of scope change. IMO the smart consultant/contractor will use both models, then pick the right one for the project and client.

ghaff 3y ago
To give a specific example with respect to writing. Want an article, blog post, or somewhat longer customer-facing material. So long as I know something about the topic and know where to go to get more information (maybe from you!) I'm happy to quote a fixed rate (+/- word count requirements). I have a very well-calibrated sense for how long this sort of thing takes and I'll put in some language about review cycles, etc. If you're a law firm that needs an expert witness report, I'll almost certainly charge an hourly rate (which is what the law firm likely expects anyway).

davedx 3y ago

Very long winded opinion piece with little substance. As an hourly billing freelancer, my only reply to this article can only be “so what?”

ddkto 3y ago

Professional business people are familiar with different business models, and when to apply them. For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk. Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. Being a professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation. (edit: spelling)

sanderjd 3y ago
On the flat rate model: I like to tell the story that the highest hourly rate I've ever earned to date was as a college student when I took on a fixed rate project to fix some department's "we have a web form that is critical to our work and backed by this perl cgi script that used to work but doesn't do anything anymore" problem. Turned out someone had uploaded the perl script to a Linux server using dreamweaver on a Mac, and the line endings were wrong. So I ran dos2unix on it and added a blurb to some documentation on what not to do and how to fix it again if necessary. Made $1000 for less than 15 minutes of work! But of course I also could have spent two weeks bashing my head against an awful perl script, never figured it out, and made nothing. It's a risk/reward trade-off.
fallat 3y ago
> when the client has a specific, measurable problem that they don’t know how to fix (but you do) Then the client tells you that wasn't their problem in the first place. In the 10 years of contracting I've never done fixed rate for the reason the client never knows what they exactly want. It's not like installing a tiled floor or drop ceiling. Being a professional means a lot of things, but fixed rate contracting is amateur hour truly. Every software dev learns this eventually.
- r00fus 3y ago
  Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).

tptacek 3y ago

Billing hourly is bad, but you don't have to give up time & materials billing altogether. Just charge a day rate, or a weekly rate.

the_af 3y ago
I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
- Keyframe 3y ago
  Discount
- MassiveBonk51 3y ago
  Less granular time tracking for both parties.
- ozim 3y ago
  Mostly that you don’t have to haggle over hours or 30mins here or there. If you do daily or weekly you don’t register time in 15mins increments to later argue with the client.
  - the_af 3y ago
    So it's basically to avoid time micromanagement? A solid advantage, I'll admit, but I don't think that's the main thing TFA takes issue with.
- tptacek 3y ago
  In one case, you bill for each hour you work; in another, you bill for any day in which you did work.
  - the_af 3y ago
    Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? It seems to me there's no fundamental difference for the context of this article; it's still flat rate vs unit-of-time based work, isn't it?

alxmng 3y ago

It depends. I do plenty of billable hours augmenting software teams. I'm delivering user stories every week. There's simply too much communication overhead in preparing weekly estimates for the same client. I don't share the perspective on hourly making someone a commodity. Fixed outcomes can also be commodities. Clients can and do shop around estimates for the best price. The race to the bottom exists whether you're billing by hour or by outcome. You avoid the race to the bottom by what you sell, not how you bill. Wordpress themes are mostly a race to the bottom, regardless of how you're billing.

swagasaurus-rex 3y ago
A large organization might prefer billable hours because they already have thousands of employees on a recurring accounting schedule

ChristopherM 3y ago

I charge by the hour and will never change. It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum. You see they are paying for my time, not results. If they choose to waste it... doesn't matter to me, it's all billable just the same. I will do my best to steer them in the right direction to save time and money, but you'd be amazed how often they need to learn the lesson the hard way. I also don't compete, I'm not on any "freelancing" websites, I don't apply or bid for work. My clients always come to me, I get an email, a phone call asking if I'm available. So this race to the bottom nonsense is utter crap. I'm a consultant NOT a freelancer. I've been doing this since 2011, that's the last time I had an employer. This year I'm on track to bill out between $360k and $400k. If that's "amateur" so bet it. Considering I have no debt, my house is paid for, my luxury SUV I paid cash for, my actual monthly bills are around $2,500 a month. I really couldn't care less what someone who writes an article like this thinks of me. The writer is advocating for the client, they aren't giving me advice that helps me. I also have no interest in scaling, on bringing on employees. I'm making bank, I left CA in 2013, currently live in Wyoming with a 40 minute drive to Park City UT and a 60 minute drive to Salt Lake City. To anyone reading this article and thinking they are offering you helpful advice, consider their motive. What are they trying to sell you? Are they trying to change the current consulting landscape to benefit themselves as a business owner?

mmckelvy 3y ago
What kind of work do you do?
hello_moto 3y ago
I see that your niche is in C/C++ world (with some Obj-C), low-level stuff. Mind if I ask how's the market and what kind of clients (companies?) that you worked with? If you don't feel comfortable sharing the list, would you be able to share some hints? Out of curiosity because my background in college is more towards System programming but life puts me as a full-stack and backend/cloud engineering. Gettin a bit tired with too many backend tech (too many different storage solutions, backend languages, etc)

PeterStuer 3y ago

I hear what he is saying, but he stops half way where he says 'take responsibility for outcomes'. You see. In business this is translated into fixed price projects. But in contrast to the name there is nothing fixed price about it. As a provider of such project deliveries, unless you truly are an 'amateur', you still are acounting cost plus if the project goes into overruns. The way you do this through 'change requests'. You see, you can't nail down a contract taking into account every possible interpretation of details on a bespoke software project. So the customer will always need to clarify and adapt. This will be translated by your sales team into additional costs until a margin is met. The only way out is using of the shelf product, and even then you will probably have an 'integration project'.

mdgrech23 3y ago
I think the lesson here is bespoke software is probably a bad idea for a lot of companies and you're better off buying off the shelf shit. I think this is particularly hard for a fortune 500 company though, especially for something like a website. You're too big for a Wix site but employing a team of developers is going to cost you an arm and a leg and it's really not in your wheelhouse. We'll probably see more software outsourced going forward.

more_corn 3y ago

Don’t feed the trolls

gatinsama 3y ago

I have been a fan of Erik for 6 years now. If you are happy about where you are in life and are making close to half a million dollars a year, like some on this thread, feel free to ignore his advice. If you are stuck in the race to the bottom and wonder why, for example, the company's management doesn't pay attention to anything you say, then read his blog.

jkaptur 3y ago

I tried this. A very large company reached out and asked for a custom version of diffdiff.net. They asked what my hourly rate was, and (thinking along the lines of this article) I offered to do it for a flat rate instead. They ghosted me! In retrospect, a "very large company" didn't reach out, a relatively junior person at the company did. I should have worked within their constraints. (Or just not taken the job, which, I guess, is effectively what I did).

d_sem 3y ago

To each their own I suppose. In my personal opinion, hourly billing is economically aligned to better product-stakeholder fit. Without economic cost, stakeholders seem to tend toward over requesting / flip flopping resulting in a worse product. I've experienced this in larger B2B projects where those customers who paid monthly where incentivized to filter out the things they don't need and focus on the high value functionality.

nico 3y ago

When first reading the title, I thought this was an article about consulting and legal firms About 90%+ of the work you get from these companies is done by their junior employees, even if the senior partner that sold you swears otherwise Especially if you are not one of their top clients For most companies, it’s better to get a small firm or an individual. You’ll get better communication, better work and sometimes even better price

mk_stjames 3y ago

One thing I've noticed more now that I read HN more than other places... Software people sure like to talk/write a lot of about their business. Like, a lot. I'm a mechanical/aerospace engineer, and I've done some short term consulting for startups (but now mostly retired). There is verrry little online in the form of blog posts like this mulling over how people work in that type of engineering (especially in the higher-end of the field, like what happens in automotive and military/commercial aerospace- it's all very closed-doors). Especially less in the methods/metas of the field and the business surrounding it. But software people? HN is flooded everyday with long form exposition just like this blog post. And it's honestly been pretty eye opening reading how much people pontificate in this area. Like, goddamn. I'm starting to think people talk about their ways of work more hours of the day than they actually.... you know... work. << Just an observation; don't kill me. >>

NoboruWataya 3y ago
I think it's startup people, rather than software people. You don't see as much of this kind of discussion in other software developer forums. Building and running a business is its own field of expertise. If you think software people talk a lot about it, you should hear your average MBA!
jzb 3y ago
Corollary: Take a generalist observation about any type of creative work, stick "developer" somewhere in there, and act as if developers are unique and/or the observation is new. Example: Not long ago I kept seeing some variation of articles about how meetings are bad for developers. Specifically developers. Guess what? This is true for pretty much any creative type work like writing, design, or any type of work that involves deep thinking. But it was treated like a revelation because it was about developers and made no case for all the other workers in the same boat. This piece? I could've written this 20 years ago as a freelance writer. Generally I refused to stick an hourly rate when dealing with clients for lots of reasons, not least of which that when I know a topic and it's in my wheelhouse I write very fast. (And if I struggle with a topic, it isn't on the client to pay for extra time...) My dad could've written it 45 years ago as a sign painter and pinstriper. He charged by the job / value of the work delivered, not by how long it took to do. (Insert Picasso anecdote about "but that only took you 30 seconds," "yes, but it took me a lifetime to learn...") At the time his craft was highly valued, hard to learn, and the difference between a good sign painter or pinstriper and a bad one was enormous. If there'd been a Hacker News for his field, maybe we'd have seen the same thing. Then came vinyl signs...

m3kw9 3y ago

Is this the equivalent of pointing out people eating alone at restaurants because he thinks it’s weird? Contracting can be good and the downward pressure stuff is false because of trust issues and networking effects.

deleted 3y ago

[deleted]

swader999 3y ago

This is nonsense. The same assertions can be said for, I'm an engineer, level 2, so here's the yearly salary.

shireboy 3y ago

I've been a consultant for 15+ years and have often come to this conclusion that hourly billing is not ideal for various reasons. I haven't found a great alternative, and the problem is I'd want a great alternative I could enthusiastically sell to my clients. "Always do fixed price" doesn't seem feasible when scope is not fixed, fixing it would necessitate time-consuming research and waterfall style project management, and clients often don't know scope until they have tangibles in hand. (ie "this looks great, but can you do this "little" thing we invision in scope, but you invision out-of-scope-but-not-worth-arguing-about"") I feel like a retainer of sorts may make sense, but that seems a hard sell for some projects. "Make us this 5 page app that does XYZ". "Ok, pay me X/mo forever". Both consultant and client would need an exit that I'm not clear on. Also, to be honest about it, the consultant should limit their clients to some reasonable number so that they can serve them in reasonable time.

TuringNYC 3y ago

Some clients are absolute pains with flat costs. They argue over scope, then argue over the definition of done, then they argue over features that were not in scope and refuse to pay you until you do them (for free.) For these "special" clients, I found the best model to be a pre-paid declining balance retainer. Nothing gives more focus to clients than a slowly ticking meter. Further, i'd set the rate to be something that is worth even bothering with such clients.

dalore 3y ago

This doesn't account that software is (relatively) easy to change, vs say building a house (to use a cliche). The client will want to see it as it progresses, and then change based on what they have learned is possible. This is the agile way. How would one account for a fixed cost then? Do you say ok it's a fixed cost, and you get 6months base on our estimate (but if the 6months has finished the contract ends, and isn't that just a time based project). Or do you tell the client no changes after the initial requirements (which doesn't sound flexible and you end up building something the client doesn't want)?

addisonj 3y ago

Heh, it seems like this article could easy be called "hourly billing considered harmful" and I would basically have the same critiques of it as most "<popular tech> consider harmful" posts. I won't pretend I have years of experience in the freelancing world... I am fairly new to it myself. But I do know as engineer who also has done some stints in product, sales, and business side, that, just like in software, there is no one "right way" and that one of the most consistent challenges business face is choosing the best of many reasonable options, especially when one of those choices is viewed as a "best practice" but the team lacks the direct experience to answer the question of "best practice for who and when?" I fully agree with the author that there are some real market forces that can make hourly work not the ideal for many situations... but I also think it massively over simplifies the different types of work that are done as "freelancing". Whole new products, new features in existing products, taking over projects, rescuing projects, consulting with less experienced teams, embedding in teams, integrations of external tools, is probably only 25% of the type of engagements a single consultant may come across and probably only 1% of the type of engagements that exist. Combine that with the huge range of attitudes of companies and very quickly we are in a space where no single solution exists. It seems like the author's true point is in the conclusion, that you should focus on driving value and results for your customer and you should structure work to align with that, which is absolutely true. The general take of "hey engineer guy who isn't as business savvy, that value might not be best delivered via hourly billing!" is not bad advice. If you do hourly billing because it is the most straight forward, you should probably think about it... but you also shouldn't move to project based billing because of some people calling it a best practice either. My advice to any engineer looking to freelance (but really to almost anyone everywhere in this industry) is to not take the easy way out when facing decisions outside your domain. I think so often work seen outside of code is seen as "lesser value", and because of that, shortcuts are made by just taking the easiest or "best practice" answer to a problem and running with it, and not gaining any understanding of the problem space. No one can be an expert in everything, but when you can't make this decision someone else's job, like when a business doesn't have some expertise (which in freelance is always the case) then you can't afford to not put in the time to learn enough to at least be informed. If you then do decide to do the easiest / best-practice thing, at least you know why you choose that option and can later evaluate how it is working for you. In summary, there is no simple answer, be thoughtful and keep trying new things. What works for one gig may not work for another.

leepowers 3y ago

When you bill by the hour, what you’re really saying is “I have no idea if what I’m doing will have any value, and I honestly don’t care — all that matters is that I am not exposed to risk for even a single minute of my time working for you. I get paid for every minute.” Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise. Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities. The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes. Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000". The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses. The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity. Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity. In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.

dusted 3y ago

Interesting read. My freelance work has never been by the hour, and for reasons that align with those mentioned in the article. Clients don't care about hours I spend, my hours bring no value to them. They desire a certain result, and they know how much that result is worth to them. For my freelance tasks, I've put forth a rather steep one-time price for the solution of the specific problem at hand. The condition: The price is paid when the problem is solved, if not, the service was not delivered, they don't pay. This works out beautifully for the client, they run no risk (except the delay in waiting for me to fail so they can try someone else), and they know exactly what they pay. It works out nice for me, since I have a reasonable idea whether I can solve the problem or not. Hourly rates for those tasks have been close to $1000, including failed tasks where I spent some days not solving the problem. In the end, it's also very fair to both parties.. It's reasonable to expect the agreed-upon result when paying someone to do something. It's also unreasonable to expect to get paid for not doing what was agreed upon. A concrete example I can talk about was a client whose database had started "acting up a lot" and they had no idea what was wrong, they were very friendly and told me they had contacted another company too who had quoted an hourly price around $200 but were unwilling to estimate how much time they would need, since they didn't know what the problem was. So I said, "I'll try and fix it, if I succeed it'll be $4000", that's a fair amount of money, sure, but it was pretty good value to them to get their inventory database back up. It turned out to be an unhandled edge-case that only showed up years after when they introduced a new kind of item into the database. I had to learn a little bit of VBA(!) to fix it, but in the end, it took about 2 hours, and you might argue that price is too much for those two hours, but they didn't pay me to spend 2 hours, they paid me to get their database working again.

exclusiv 3y ago

This is nonsense. If you bill fixed, then you're doing it wrong if you estimate so lean that you put yourself at risk. And it's a disservice to the client if you are really conservative and they pay a lot more than T&M would have been. And if you are spot on with your fixed estimate, then that's the same outcome as T&M lol. If you are an honest person and do business the right way, T&M is the way to go. If you want a higher effective hourly, then you would pad fixed. That doesn't make you professional though; it makes you dishonest if you purposely inflate. If the company needs it to be fixed to compare apples to apples or their finance dept requires it, then submit your fixed scopes and run your business. It's professional to be flexible. And to not fight client processes and procedures. You will not win a lot of great business if you have only 1 way to run your projects. Some larger companies will take a vendor that costs way more but offers better terms like net 45 or net 90. I'm a professional. I run a business with employees that's grown every year. We do both, but it's better T&M. All time is logged with descriptions of what was done. We bill based on seniority. We still do time estimates on items that are T&M so my team is accountable, thinks about their approach and time, and so the client can have an idea of what they are committing to. They don't care if it goes over, it just can't get out of control. And they need this information to triage and approve requests. T&M with time estimates is a professional way to go. Some of your estimates will be off, some will be under. Just make sure clients understand that and traffic your wins and losses. And if you find out your 24 hr task is going to take 60 hours, notify the client as soon as you discover that to avoid surprises. I'm experimenting with a more traditional contingency budget which is explicit in the estimate. In that manner, a fixed bid would be done but the client would be aware that there could be unknowns that result in tapping the contingency budget. And if it's not tapped - they don't pay it. So rather than try to bake the unknowns into the fixed which the client would pay regardless, I can have the contingency reserved if needed but be more palatable against a competing bid that wraps it into their fixed. So say, 100k fixed bid, separate 20% contingency for unknowns for my bid. Versus another company's 120k fixed bid, no contingency. Both possible 120k spend. One may not use contingency and thus be 20k cheaper. The other - 120k is paid no matter what. Anyone do that on their larger projects? How is that received?

nico 3y ago

Most legal firms do something in between, you pay a retainer or a minimum package, and then they bill you hourly They get the money upfront, before they do any work So, from the get go they know the minimum they are going to make, and they never get stiffed (also because most people don’t want to get into legal issues with a lawyer)

felixarba 3y ago

I found this article helpful. Most comments on here seem to suggest that hourly is best done when clients don't know what they want, and I think that actually misses the point of the article, in my understanding. Working with a few customers as a freelancer, I agree, a lot of time they can't express what they actually want. They know it when they see it, but they can't express it correctly so you end up building a product, and having a thousand change requests - basically the customer uses you as a prototyping machine until you build what they want. Obviously this can't work with fixed pricing, BUT this is where the point of the article comes in. If the only thing you can offer to your customer is writing code based on a requirement - you're racing to the bottom because thousands can write code based on a requirement. BUT, if you focus on outcome - I will build you what you want, AND I'll help you figure out what that is!! That service will include asking the right questions, helping the client figure out what they want, and you can put all of that in your fixed price offer. At this point you aren't just writing code for them, you are their business partner, you want them to succeed, and you will use your experience to offer advice. If you become good at this, you are much more than just a programmer, or what the article calls "technician". So, thanks for the article, I found it interesting and have some food for thought.

iainctduncan 3y ago

This article is amateur hour. And by that I mean "amateur" in the sense of "lacks the business experience to see past their own narrow experiences". I work for a consultancy that works for some of the biggest investment funds in the world. We do some flat rate and we do some hourly. Sometimes hourly is exactly what the customer wants and is aligned with our interests. Sometimes it's not. I have also freelanced successfully with the same experience, and as a customer there are things I absolutely want hourly. For example, discovery should always be hourly, or you screw it up by making discovery that leads to a no-go conclusion unlikely, even if no-go is the Right Thing. One of the best things I ever learned for consulting was how to do this - clients who have paid you a reasonable fee to discover that they are not ready to go ahead will be talking about your honestly and credibility to anyone who will listen. Managing when things should be hourly or not is a huge part of what builds credibility. Blanket statements about how one should never be trying to do hourly work reveal nothing but business ignorance.

jjk166 3y ago

If the scope is fixed, you're selling a product. That product might be a one off, and it might be purely a service product, but it's still a thing to be sold at a price. Generally consultants are not selling a product. They are hired to bring knowledge and experience to a team, to be there when needed, and to offer flexibility for which it would be time and cost prohibitive to develop an internal employee.