Hacker News new | past | comments | ask | show | jobs | submit login
Why I bill hourly (orestis.gr)
229 points by cwan on Nov 7, 2010 | hide | past | favorite | 57 comments



Why you should never quote prices in hours: because it provides prospects with a frame of reference for price negotiation in which (a) you always sound very expensive, and (b) price movements that seem reasonable to the prospect can end up being very painful for you.

If you're going to end up haggling over your price, far better for you to be doing it over numbers like $15,250 which are tied to the specific project than over numbers like $125/hour which are affixed to you for the rest of your relationship with the client. You should never, ever be budging on your rate anyways. Give an inch on your rate and you will never get it back; companies hire whole departments to ensure that rate concessions, once taken, are never surrendered. Negotiate over project scope, not rate.

The question of whether you should go fixed price or time-and-materials is a reasonable one (and it's a negotiating point), but if you're going to bid time-and-materials, price in billable weeks, and estimate the number of weeks up front. Save the details about billable phone call minutes (and, seriously?) for your S.O.W.


Thomas gave me this advice several months ago, and it made my life as a consultant less stressful and more lucrative. It worked particularly well with a menu proposal: here are three different engagement lengths with expected project details for what we can accomplish, which one works best? Instead of them quibbling about my rate, they just said "The difference between B and C doesn't matter too much to us, so we'll drop the last week and pay you the B rate. Cool?". Worked perfectly for both sides, and I got a week with family.


You are absolutely correct about this. People at all ends of the market spectrum have a very strange psychology about hourly rates; for some reason, if you hand them a quote that foresees 10 hours at 175/hr and is expressed that way, that strikes them as an eye-poppingly high number. They start comparing your services to the prices to those of high-end attorneys and accountants and so on, exercising prejudices about how programmers should be paid less than that because they are more like plumbers or electricians than litigators, and general wheel-dealing, bargaining, nickel-and-diming, etc.

In addition to that, the large-scale body shops serving the enterprise market, the ones we all know about that darken the skies with individually-billed people and squeeze as many hours as they can without the impression of efficiency, have left such a bad taste in the mouths of many people who no longer work in enterprise that you invariably have to fight against it every time you sell your services.

But if you hand them a quote for 1750, even with the 10 hour estimate baked in for their mental math to operate on (but especially if it's not, and once you quote an aggregate price itemising the time apart from overall delivery time frames for the most part ceases to be necessary), some switch flips in their brain. I cannot say what it is, or why -- it just does. Somehow, the combination of shifting the risk for overages onto you and the more opaque number causes them to start evaluating the overall sum more in terms of business value and less in terms of whether anyone should be making "that kind of money." It's really odd, but it has been overwhelmingly the norm in my line of consulting trade.


I wonder how much of it is that if you bill $175 an hour, they instantly compare it to their own salary.

If it is someone in purchasing, it is higher than them. If you bill someone at an executive level it is equal to them (and they will think of this as below them), if you bill an engineer they will think it is higher than them.

Now, I'd argue that is a fair rate if you are that much more productive than the average developer, but it instantly makes people offended.

I still like the idea of billing by the hour though.


Perhaps, but the idea that a comparison of a contract hourly rate for a short-term project vs. a salary is in any way, shape or form apples-to-apples is absurd. That doesn't stop some people with no elementary business sense from failing to realise it, though.


If you quote the rate, and the project takes more time, it becomes their problem; they have to pay more now.

If you quote the overall price, and the project takes more time, it's not much of a problem for them; they won't end up paying any more than they would have otherwise.


Stop! There is no reason why you have to assume the project risk just because you chose a more sensible metric to quote the price with.

Provide a top-line project cost number as an estimate, and then add an "additional time can be added to this project as needed at a rate of $XXX per day" clause.

The question of who assumes project risk is orthogonal to the question of how you choose to break out project cost.


I'd rather that part of my service is to give my client a sort of guarantee on the cost, given the requirements[1]. How many hours I work? What technologies I use? What OS do I work on? What's my text editor? What version control system do I use? These are things they shouldn't have to concern themselves with -- I'm a black box.

Do you ask Apple how much it cost them to make that iPhone? No!

[1] If the requirements change, then of course, my price will change (most likely increase).


Well, yes. Exactly. :)


I think you both make good points. I'm more in agreement with you than the author, but I voted up the article for this line which is a gem:

> Any client will have grand dreams of his product. He will constantly ask for new things, and think those were naturally implied from his vague sketches. If you have quoted a fixed price, and you were smart enough to have a detailed contract, you will need to fight him on every step, saying "we didn't spec that". Whereas, with an hourly rate, you can say "sure, let me estimate how much will this be". The client can then decide if it's worth the money.

Perhaps his method is better for projects with unclear scopes or first time buyers, and yours for clear scopes and veteran buyers? I see merit and potential uses for doing it either way, depending on the circumstances.


I'm not 100% in agreement. I think you should quote prices according to the project or client in question. Some big long projects call for billing by the week or month, many work well with days, but sometimes you have someone who just needs something quick, and you can't reasonably charge them for a full day because they realize full well it's not going to take you that long. They're going to be happier with a high hourly rate and feel that you're being very careful to only charge them for the hours worked. This is, after all, how lawyers work, amongst other professionals.

IMO, at least - I think it depends a lot on what sort of clients and work you're doing.


I may be biased towards high-end consulting, but my response to this is "1 billable day, minimum". Flexibility is something that is valued by clients, which means it has a price.

Strong relationships are something that has value to me, so if I reasonably can, I'll tend to just do stuff that takes an hour or so for free. Every consulting proposal I write takes 2-4 hours from my life, minimally. The last one I wrote required a 3 person research project over several days. We'd never charge for a proposal, so I'm not going to freak out over 1-2 hours.

(Dave, Jeremy, and Cory might disagree with this assessment.)

If you're ever wondering why I have zero sympathy for designers complaining about "spec work", there you go.


This is typical, and is expected by enterprise customers. Additionally, it's expected that 1 billable day could end up meaning anything from 5 minutes telling a staff tech which wire is crossed, or 15 hours working an exceptionally challenging problem. ymmv, and it all evens out in the end. If you feel like you're getting the shaft over the course of several projects, that's when you know it's ok to raise your rate (or that you need to improve your skills).


It depends:

- With some customers with large budgets and long projects I found that hourly quotes gives me a quick way to increase the team instead of negotiating a whole price. Say you have a team of 1 project leader, two developers and one QA and you found that you need two more developers because requirements changed, some customers just say "yes" and you are billing without too much sales and negotiation overhead.

- With agressive negotiators it's better to go to the fixed price (adding % of risk to your total).

Also when we quote by hour (indeed by days) we set a minimum budget for the project, so the customer can't reduce the project to just... three weeks, small projects can be a pain.

Because many projects we did involve reverse engineering and research we bill for that if the time required to know if a solution exists is more than 3 days and can't be solved in the pre-sales stage.


All I'm really saying is that "hours" is the wrong unit to negotiate prices in:

* $400/hour sounds expensive to anybody. But $32,000 might be cheap as far as project budgets go.

* Conceding $400 -> $350 is, first of all, more expensive than it sounds, and second of all is a concession that will last endure across all your projects. On the other hand, there are many levers you can pull to get $32,000 to $27,500 if that's where the client's budget needs to be.

At the end of the day, your "hourly rate" doesn't mean anything. Clients don't buy "hours", they buy outcomes (or checkboxes). Thinking about things in terms of your hourly rate is a good way to box yourself into bad engagements.

We obviously do a lot of reversing work too, and of course we bill for it --- it's part of the "Discovery" phase of projects that require it. There've been a few times when I've had to bust out IDA or a debugger to write a proposal, but they are rare.


$400/hour sounds expensive to anybody. But $32,000 might be cheap as far as project budgets go.

I think the use cases you describe are very different from most of us. You said you could spend upto 3 days just working on a proposal. For some of us, 3 days of billed work with one client is the average size of a complete project. Can you see then how it may not be efficient to spend a day just working on a proposal and spec'ing things?

Like you, I always believed that as a client you pay me to achieve objectives--not hit keystrokes on my keyboard. In the past two months, I've refunded or canceled three fixed-price projects where it was simply cheaper for me to end it than proceed. One of them involved over 40 hours of work when my initial estimate was that it would be a 20 hour project. I refunded the guy's original deposit.

It's easy to say that I am just underquoting. But no matter what quote I give, I feel it's rather arbitrary given I cannot invest time like you to really delve deep into the project and get a real sense of the work involved. I have gone the whole "I am not going to underquote" route and after doing that for a sample set of projects, my post-martem revealed that I was either overbilling or underbilling clients. In essence I had some clients subsidizing the other clients.

This past week I've been working on my first "by the hour" gig. I've put in over 80 hours in the last 10 days. It's been a living hell for me work-wise. But at least I know I'll be compensated for it! And fairly! There was no way I could quote this client a flat fee and c


Additionally, if someone is hiring a contractor, that contractor may have a rate of $x/hr, but the customer is most likely going to pay them monthly because it's so much easier to work larger numbers into a fixed budget.


- With agressive negotiators it's better to go to the fixed price (adding % of risk to your total).

I tend to be very careful when dealing with aggressive negotiators. Yeah, they might negotiate aggressively up front, then be decent down the line, but I've had so many experiences with 'aggressive negotiators' attempting to change the deal later that I generally price in a lot more scope creep up front, and I make sure to charge them for things like phone calls or emails; things I might do for free for an easier to deal with client. I'm also much more aggressive about getting paid on time when I know I'm dealing with an aggressive negotiator than I am normally.

The thing is, good negotiators put a lot of effort into putting you into a situation where it's expensive for you to walk away, then they ask for more work before they pay you. I've seen guys who are several months late paying ask for another milestone before they send the cheque. The key when dealing with these sorts is to stay out of situations where it's expensive to walk away. Give the person a credit limit, (you are, after all, loaning them money when you do work post-paid) and if they exceed that credit limit, stop work until you get paid.

(I think one needs to be careful here; I don't think it's acceptable to threaten to break things if you aren't paid... but I think it's completely reasonable to just stop, and in my experience, stopping work is ridiculously effective. Every time I've tried it I've gotten a cheque overnight.)


I tend to bill on a daily basis. I will present my clients with my hourly rate and then explain to them that I bill per day instead. My daily rate is slightly slower than 8 times my hourly rate. The reason I do this is to prevent nitpicking on time sheets etc and to be accountable for every single hour of the day. The last thing I want to do is have a clock sitting next to me measuring my every single move. Some days I do some overtime (1 maybe to 2 hours max) and other days I find myself working slightly less. In the end it all works out fine. The estimates that I give my clients are based on days, not hours. If they want me to do a 4 hour job, cool, I still charge them for the entire day. Most clients are cool with that. Since most projects I do tend to have time-frames that go into weeks it's much easier that way for everyone involved.


Do you force yourself to work on only one customer's project on any given day?


No I don't and it depends whether I work on-site or from my own home office. To work as a contractor has both benefits and downsides, which are typically the reverse of being full-time employed. My hourly (daily) rates are based on the fact that I might not be able to fill 40 hours of work week after week. So, in a sense, my clients also sort of pay me for the time I'm not working. That's why my rates are set to a certain level, and it's also the reason contractors are more expensive than full-time employees. If I happen to be working from home and I do work for 2 clients and both jobs take me 4 hours, than in that single day I earn twice as much. However, the next two days I might not be able to bill anything. Pros and cons of contracting I guess.


Do you make this clear to your clients? If I was told I was being billed for "one day" of your time, I would expect that you were spending about 8 hours working on my task. To find out otherwise, I would feel that I had been lied to.


Yes. I make this perfectly clear to my clients. If they give me 4 hours worth of work I still charge them for 1 entire day. And to be quite frankly, what I do with those other 4 hours is none of their business.


A good point from the article is that estimating a single task at more than 4 hours is more or less saying "I have no idea how long this will take, actually." Do you find that when you estimate something to take "one day" your estimates are generally accurate?


I get paid by the day in my normal employment. It is fair enough on an 8 hour days, but when you fill 24 the hourly rate drops to shit.


If you let it come to that than you're doing something wrong. It either means you didn't estimate well enough or you didn't inquire about the project time-line. E.g. If you estimate a job to take 40 hours but the deadline is in 2 days then you have a problem. Getting paid for the 40 hours is not going to make you happy if you have to work 2 days around the clock. In other words: Estimating is one thing, but it also has to fit into an achievable time-line.


I sometimes would like to be able to bill hourly, but find it impossible:

1) When I'm thinking about the project in the shower (where all the real thinking is being done) shouldn't the meter run? Apparently from the original post, the only billable time is the typing time, which is a little bit funny.

2) How do you know if you're fast or slow? Are you even consistent? Sometimes a stupid feature takes me half a day; sometimes something really complicated snaps together in an instant.

3) Even more so, the client has no clue of what time it takes to do something (and how could he, given that I haven't got many clues either, beforehand). If I tell him that it took me 3 hours to do X and 5 minutes to do Y he will be shocked! He will think I'm crazy, or bullshitting him, or that I'm trying to convey some other message that he'll spend the next week trying to decode.

4) What about warm-up time? When I get back to a project I left a week ago, it takes about an hour to get up to speed; how should this hour be billed?

Besides, every theory of pricing tells us that price should NEVER be based on costs. Price should be based on value because that's what it is: price == value. The problem of course is that the client won't tell you what the value is.

What I end up doing is:

- if I can get an idea of the client's budget, and I find this budget acceptable, then that's my price

- if not, my personal rule of thumb is (maybe counter-intuitively) to bid low on things that are new for me (and interesting), because I really want to learn the skills and get the reference on my portfolio; and to bid relatively high on things I know well, because I don't really care to get the project or not, and if I do get it I expect it to contribute financially to all the other stuff.

(So if you want to hire me cheap, make me do something I've never done).

Also, it's been my experience that clients care about the price before the project begins, but never after.


If you're finding yourself worried about being able to bill for phone calls, or for shower thinking, or ramp-up, your rates are too low. Stop trying to put price tags on tiny scraps of your time, and instead put an appropriate price on the value you're providing to clients.


> put an appropriate price on the value you're providing to clients

My point exactly...

Actually, my whole point was that I try to bill:

(value to client) div (my willingness to do this particular project)


"Also, it's been my experience that clients care about the price before the project begins, but never after."

I agree, and from both sides of the table. I've provided added services to projects where the total value of the added services were a multiple of the initial cost, without getting any complaints or requests to lower the budget. I've also paid many extra hours for additional work and never felt bad about paying for any of it; and I'm very cost conscious and drive a hard bargainer when I get an initial offer.

I think it's a trust thing, after the other person has shown that they're capable of providing high quality services, cost is not so important any more, while if you're just getting quotes from people, you have no way to find out the true qualities of the people you're asking (usually). Even references from people you know personally sometimes end up blowing up in your face, a guy may be having a bad day when he's working on your project, screw up and refuse to fix it. Relationship-breaker right there, while he may have done an (objectively) great job at your brother in law's project last year.


tptacek hit it dead on. Don't bill hourly; bid on a project basis. Why? First of all, you can end up doing work for a client and you know how you can save them $2,000/month by fixing something they can't. It only takes you five hours to complete the project, so what, you bill them 5 * hourly rate? You just saved him $24,000 year. That`s worth much more to him than an hourly rate. Know what you want per hour, ALWAYS get that, but quote what you're worth to your client and nothing less.

Secondly, tptacek is right again. Once you bid $125/hour, you're stuck at $125/hr. Even if you save your client that $2,000 month for 5 hours work, they`ll expect to pay you $625 and nothing more.

Be warned, this post is spot on if you always want to earn the same amount of money but you will never grow a company with this billing method.


> Be warned, this post is spot on if you always want to earn the same amount of money but you will never grow a company with this billing method.

OTOH, if you want to do fixed bids, you better have a really good idea of exactly how much time it's going to take you. This means that you should concentrate on doing only things you've already done, or that are very similar to them. Otherwise you'll run into something you didn't even know you didn't know and blow your estimate and eat the losses yourself.


There's a trade-off to be made here and it can be compensated for by knowing really good people.


I'm not necessarily against fixed bid work; I do a bit of both depending on the situation. However, fear of being stuck at a particular rate isn't a good reason to avoid hourly billing.

I've raised my rates at least a dozen times over the past decade, and not a single client has complained. It just requires clear communication and a reasonable ~month's warning.


The billing method has next to nothing to do with growing a company. High-end consultancy companies, law firms, financial services etc, very typically charge by the hour.

Also, who says you are stuck at your initial rate? Whenever you want, you can increase it. Many clients will have no problems with this, if you are worth it. Some will, but that's typically the kind of clients you can afford to loose anyway.


I have to agree with a lot of the posters here that fixed bids are better than hourly. I've been doing the freelance thing for a while, as well as working for another company, and have a very good understanding at how long it takes me to complete task X.

When looking at a new project, I can usually estimate the time it will take me to within a few hours and then I always add an additional 25%. I don't ever bill a client for phone calls or emails and even when the project is completed will answer emails/phone calls from them to assist. Yes, my prices are a bit higher than average but my clients don't mind paying it and don't mind passing my name along.

When dealing with a new project that I haven't a clue as to how long it will take me, I give an estimate about how many hours I believe it will take me and, if it gets close to that, the client is immediately told and we decided together how to move forward.

My contracts are also pretty detailed. I learned early on that specs that aren't spelled out in a contract have a way of coming back to bite you.


I find that billing hourly can make for a more pleasant relationship with the customer. Provided that you give good justifications for the hours you bill.

On fixed price contracts there is lots of haggling over the exact scope, requirements, changes and meaning of words in the contract.

Hourly billing lets me smile and say "sure thing" to more requests, something that I actually prefer doing.


Here's a faster loading coral cache link: http://orestis.gr.nyud.net/blog/2010/11/06/why-i-bill-hourly...

(The site took > 60 seconds when I first tried to load it.)


Fixed bid gives you a greater incentive to be efficient in my experience. If you're significantly quicker than your peers (e.g., have your own processes, frameworks, macros, etc.) then you can have large margins and happy clients if you can estimate decently. Another reason: you only have so many billable hours.


One reason why I think hourly works better than fixed price: might help getting priorities right. For example, suppose the budget is 20000$, and you have 2000$ left to spend on the almost finished software. With hourly, the money could be spent on useful enhancements, or on the most useful features still missing. With fixed price, you probably agreed up front on some stupid things like "all source code has to be documented", so you probably spend the remaining hours on writing crappy documentation everybody will hate to read anyway. Since you agreed on features x,y and z up front, you might end up doing a hush job on features x, y and z, rather than doing a good job on x and negotiating that y, z will better be scoped.


I find iterative fixed fee kinder to people hiring out their first few times. It gives them strictures on what they can do so they don't shoot themselves in the metaphorical foot.

However, hourly definitely has it's place as well. I find offering both a good compromise.


I agree whole-heartedly this is a great way to work if you're client is cool with it. In my experience that's a big if though.

If you can always afford to walk away then this could actually work.

I always give my client's the option of fixed or hourly and really emphasize the benefits of hourly. However I've only been taken up on the hourly offer a few times with recurring clients.

I think it's a great thing to strive for but my advice to freelancer's starting out is not to flat out refuse fixed quote unless you can afford to. Fixed, while not quite as accurate, is still workable once you get a feel for defining requirements on smaller projects. And any larger project can be broken down, so long as you're getting paid for the spec.

Whatever you do don't spend a riculous amount of time specing out a large project without being compensated. I've gotten so many RFPs that are obviously the product of spec work and I'm positive most were unpaid. In fact I guarantee there are forums dedicated to tactics and advice for getting spec work done for free.


I know it sounds trite, but if you can't afford to walk away from a project, you probably shouldn't be contracting to begin with.

I say this from hard experience, the jobs I've taken against my better instincts are the ones that have bitten me badly.

Another thing that's important is to know WHO you are pitching to. I charge predominantly T&M, and my ideal clients are existing dev teams that are looking for an extra pair of hands for a particular project. Matching your billing model with the kind of clients you want to work for greatly increases your chances for success.


I may not have been clear enough. When I say if you can always afford to walk away it's meant within the context of the post. Meaning that if you can always afford to walk away from clients who are only interested in fixed quotes, not just one job. Which in my experience anyways has been about 90% of the time (of actual contracts, not just leads). I can't afford to turn down 90% of my work... yet.

After reading some of the other comments I've decided to stop even giving them the option of an hourly rate. Works been very steady (too busy ATM) and like I said there's been very little uptake on the hourly option anyways.

I agree that it definitely makes sense to change your model to reflect the type of client.


I am doing hourly work. But this is for clients I have high level of trust. They believe me.

Most other clients are more concerned to know fixed amount of time and if project took less - they want to get it back, although I negotiate that successfully so far =)

The worst case is - estimate in hours. =)


We would love to bill hourly. We tend to work for large companies, and they need to figure out how much to budget, so we then end up saying, "this will take between 10 and 12 hours," and then being forced to swallow the costs when it takes us 14. And of course, if it takes 8, they win. If anyone has suggestions other than "just tell them it will take what it takes," we'd really appreciate hearing them.

Edit: Usually, just stopping when the hours run out isn't a good choice either, because most of the projects we have won't provide a partial solution. It's all or nothing. Example: converting data between two formats. We discover a quality issue when we've run out of time, so the converted data is unusable.


In that case they are asking you take all the risk, so you need to factor that into the cost. You need detailed specs up front in order for this to be at all sane (developing the specs could be an independent project without obligations on either side). Depending on the uncertainty left in the spec, you need to have a multiplier on the expected costs. 5x, 10x, or even 50x would not be out of the question if there is sufficient uncertainty.

Yes this costs the company more, but if they expect you to take on their budgetary risk, then you are providing insurance, and that is potentially worth a lot more than the actual development.


How are you "forced" to swallow costs, unless you're contractually bound to deliver in 10-12 hours? If your client wants an estimate, by all means, give them a non-binding estimate. If you find yourself over-running your estimates, then it's either your fault or the client's fault - why should you have to bear the cost in both cases?


We do have a "non-binding" estimate, but they can't turn the wheels in their large organization to get payment for more than the high end of our non-binding estimate. And no one takes us seriously if we say "probably 10 to 12 hours, but this kind of work occasionally has problems that will balloon the costs to 20 hours."


Why would you not just say 10-20 hours then? If you know that you're going to wear any overrun costs, you owe it to yourself to give the estimate based on the worst case, NOT the average case.

Edit: If you think that 20 is a real outlier, and 12 is your average case, use something like the PERT formula: ( [Optimistic] + [4* Realistic] + [Pessimistic] ) / 6

If O=10, R=12 and P=20, that would give you an estimate of 13 hours.


For larger projects and clients, I recommend you look into agile contracts: http://www.bestbrains.dk/Blog/2009/06/03/CollaborativeAgileC...


Well, there's two sides to that coin. By having the client pay hourly you put the "risk" of the project on his shoulders, but you also limit yourself to earning only a hourly rate. Why is that bad? An experienced programmer might accomplish a task/project quickly due to having done similar projects and have an arsenal of code/examples/tools at his disposal. An experienced programmer might be able to get 20%-30% markup on his hourly fee but he might finish the project five times as fast as another less experienced programmer might.

You won't be able to leverage your gray hairs and the time they save you as efficiently with an hourly fee.

If the project is well-defined you might be tempted to accept a fixed price and crank it out quickly which will net you more money per hour. I'd advice holding of atleast a week even if you do it in a day or two or the customer will start questioning your price ;)

If the project/customer is fast and loose with the spec and functionality (as most projects are) you're in dangerous terroritory where constant changes keeps eating away at your time.

If you can get a high hourly fee and the project is fuzzy, go for it, meetings and stuff like that will earn you a bunch anyways.

Another strategy is to split the project into discrete parts and charge a fixed price for each (negotiating each one), that way it's easier to define the scope of the project and it eliminates risk both ways. It also gives you and the customer have a chance to get to know each other before committing to the project and helps avoid being in the clutches of a psychopath customer.


For those that bill hourly, do you go off of a monthly retainer and sort of use that as a budget for hours? If I am starting to outsource (not off shore, just with partners, specific tasks), I'm just struggling about how to approach that from a billing perspective. I would like to make a small margin.


For active projects/customers, I bill 1 hour minimum per week. I also bill a minimum of 15 minutes a day if I do any work at all. This is fair since there is some "context switch" cost for me, even when I just answer an email or take a short call.


What about using Scrum and billing by the story point?


I find that using acunote to lay down the estimate (then remaining work with burndown) and freckle to track the hours and remaining budget works nicely.


I've done both hourly and fixed price contract work and found that fixed price works better for me.

In an industry that is known for software taking 10 times longer than estimated, clients have good reason to try and protect themselves with upfront pricing. The fixed pricing forces me to become better at planning ahead and giving good estimates. The trick is to document every detail of what they get for $XX and agree that any changes to that will cost extra.

Software development depends largely on inspiration. Sometimes I'll crank out a weeks worth of code in one day. Others I'll stare at a screen all day and produce very little. In the end it all averages out, but I do feel bad billing for the unproductive hours even if I know it's fair in the end.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: