As hourly paid freelancers, should we make things take as long as possible?

Question

I recently accepted a large project which was basically making a lot of CRUD (create, read, update, delete) pages for the database of a company. The reason the project was large was, there were a lot of tables, and there were a lot of fields in each table.

Envisioning that the project will take at least 10 days of work, I quoted appropriately to the client and got the job. When I got started, I had 2 options:

• Write the add, edit, validate, pagination, etc for each database table (customers, contracts, etc) seperately, which will just be the same code all over but different fields.

• Or write a class which handles all of the repetitive tasks, you just tell it the name of the table and the field names, and any other options.

So I took option # 2. The resulting classes took a bit less time than doing it the conventional way would have, but rather than having 10 files with their own edit(), add(), validate(), etc functions which were basically the same thing all over, I had code like this:

<?php
require_once(APPPATH.'/crud/Crud.php');
class Customers extends CrudController
{
    function Customers()
    {
        parent::Controller();

        $this->entityName='Customer';
        $this->model='customer';
        $this->url='admin/customers';

        $this->setDefaults();

        $this->addGridField('business');
        $this->addGridField('lessor_name');
        $this->addGridField('contact_name');
        $this->addGridField('email');
        $this->addGridField('phone');
        $this->addGridField('mobile');        

        $this->addTextbox('business');
        $this->addTextbox('lessor_name');
        $this->addTextbox('contact_name');
        $this->addTextbox('phone');
        $this->addTextbox('mobile');
        $this->addTextbox('email', '', '', 'valid_email');
        $this->addTextarea('comments', '', '', '', '', 7, 50);
    }

}
?>

For each table, I built a file like the one above and bingo, I had CRUD pages for all of these!

But the prob was when I told the client the job was done. Although they did pay me, and did pay me on time (they're an old client, I often work with them), they sent me this email:

<snip>

Just querying your quote - Did this really take 45 hours to develop?? That
crud system you have looks like it's very simple to do
mate.......................


Hopefully will be able to pay later today...

--
John doe | IT Manager
</snip>

So my question really is, if we notice an obvious flaw in how we work, eliminating which will decrease the time spent on a job a lot, should we try to correct it and get the job done faster? Or should we continue to make it take long because then we will take the longest time, and hence get paid the most???

Or, how can we convince our clients to pay for value rather than time spent? That even if on the surface something takes us 15 mins to do, there was a lot of time and thought that went into optimizing it, and we should be compensated for it?

Answer 1

One reasonable solution is that you request payment for time spent on a task but not less than some period defined in advance at the time of taking the job (say one day).

This way if you solve the problem in 20 minutes you are still compensated well and the customer sees that you're a person actually taking care of his problem and not taking advantage of him by billing hourly for solving a trivial task months and months. They will have other problems next week and will have to decide whom to hire to solve them.

Answer 2

If you quote by the hour, you should bill for the time you worked -- no more, no less. If you quote a fixed fee, you should get the job done and bill the fee you quoted. In this case, it seems you quoted an hourly rate. If you did not work 45 hours, then you should not bill 45 hours. It's dishonest, no matter what you perceive the "value" of what you did do be.

Per comment: It's an issue if your customer is confused about how they are to be billed. But, again, if it's a fixed price bid, that should be clear up front. Plus, if this is a good, annuity customer, you should be willing to say "you know, you're right, I found a quick way to do it, so I'm billing you less." That's money out of your pocket, but may pay dividends in customer relationship.

It's a matter of risk. If you bid fixed price and you have a poor estimate, you have to take the risk on making it right. So, again, I don't think it's a question of getting a customer to pay for value. I think it's a question of well known billing practices, correct estimates and assumptions of the risk.

The only real way I see around that is to sell something you've already packaged and own yourself (i.e. didn't develop for someone else.) Then you can say something like "this will generally take 100 hours to build, I am selling it to you for $X which comes out to a savings of $Y at a reasonable rate."

I'll give you a story from personal experience. My wife and I both did freelance work for a number of years. He specialty is a fairly niche market of learning and compliance courses for law firms. She goes in, does an analysis of their training and builds elearning courses for the various systems that they use (law firms use highly specialized document management systems, big word template libraries, etc.) To go along with their courses, she would resell a learning management system that would allow tracing of scores, reporting and stuff like that.

The LMS was expensive and difficult to deal with. So, I worked with her to understand what her clients actually needed (not this huge all-things-to-all-people product) and spent my own time developing a very lightwight LMS that was easy for her to integrate with her courses.

I went out and got a lawyer. He charged me $1,500 to give me a license agreement. Then, my wife went out and sold our LMS to her clients. We would offer our system as a perpetual license, with installation and support for a year for $5,000. They were paying $20,000 for the other LMS and using about 5% of the features.

It's a very niche market, so I only sold 4 or 5, but that's the process. If you have a CRDU data access layer that you think you can package and sell to your customers, then you ought to get a license agreement, set a price and make the sale. Then you can package and resell all the great work you've done.

Either that or you could just go get CodeSmith and be done with all the CRUD DAL writing. :)

Answer 3

I usually quote a fixed price for something like that, and I don't mention how many hours it will take, just how long it will take before I can deliver.

It gives you some flexibility in planning your work, and there is never an issue with billing later on.

Answer 4

Read this. Send it to your customers.

A tale of two programmers

It depends on the client. Many clients can understand that the quote must take into account all eventualities, and will be fine as long as they know you to be fair. Your answer to his mail is that you feel the quote to be fair - don't address the time.

For some clients [esp. non technical ones] you should package in a few extra classes that don't do anything. They will be impressed by the volume, but the code will still remain as short and efficient as before. If you or someone else need to edit the code, you will appreciate how it was written correctly. Anyone who can recognize that the extra classes are extra, can appreciate that short code takes longer to write.

Aslo, sometimes you should tell the client that it took less time than expected and offer a small discount - that alone can lead to further jobs, and the discount can be smaller than the difference, it won't be challenged.

Never do extra work just to be able to bill the customer.

Answer 5

But you agreed the quote in advance with the client, which is the time for them to decide what price they put on the value they get from you.

Consider shrink wrapped software: the "hard work" done to produce a copy of it for an individual customer is practically zero. The more customers engaged, the more profit is made. If you took the approach that each customer should only pay their share of the original development cost plus ongoing maintenance costs, you'd have to start giving your early customers almost total refunds if you became too successful.

And this is totally unnecessary anyway. From a customer's perspective, they want to use your software to save costs elsewhere. By adopting your solution, they will be able to spend less, waste less time, thanks to increased automation, as captured in your software. This means that they can make a very simple decision on the price they'd be willing to pay, based on their estimate of how much effort they'd save if they bought your software.

By convention, this price is expressed in hours x hourly rate, but no sane customer actually makes a decision based on that. They look at what they currently have to spend per month to run some aspect of their business, compare that with what they will have to spend if they had a software solution in place, and the difference is the value to them of your software, per month.

And when they look at how simple the result is, you can say "Yeah, it took a while to come up with the simplicity. First it was a mess, but I tidied it up a lot for you, so it will be easier to maintain."

In a comment elsewhere the OP says:

The thing that's bugging me is, about 75% of my business is CRUD apps. Now that I've made this system, that 75% is now pretty much automated, what used to take me hours will now be done in 15 mins. Should I tell all my other clients about it and get the already-set prices of their projects reduced because they will take me less time now? How will i be profitable in the future if 75% of each project will be done for free for each customer?

This is close to being an economics/marketing question, rather than a programming one - although you are talking about the life-cycle of a software product, so it is probably just about on-topic.

What you have here is a potential product. You've invested your time in producing it. You'll probably invest further time in refining it. Now you are able to sell it to multiple customers. You could continue to set the price at the highest level customers will pay (which will be somewhere just below the price where they would be better off without your product). By making the price lower than that, you give your customers a very good bargain - but you will also be able to attract more customers. And as what you've done may not be serious rocket science, you will have competitors, so you will have to compete on price.

To work in "product" mode, you will probably need help from other people to manage the much greater number of customer relationships (there's still that 25% of the work to do each time), so you have to factor the cost of hiring employees, or you could take on partners you really trust, and share the profits. But on the whole, it pays to scale up in this way (read Adam Smith!)

(Another factor to consider in pricing is that some customers will not take a solution seriously unless it is expensive. That is, the judge the value of the product by examining the price tag; this is common in all markets - think of designer jeans, etc.)

Answer 6

I think we as developers should always try to make the best solution, also concerning maintaining the code as well as speed of execution of cause. Now if you are able to make code very fast, you could or should raise your rates some. It's only fair that if you are able to make twice the work, you'll also get twice the pay. Your rates should also reflect the level of skill involved, as quality of code is also something worth the penny. Every one can make something work, but to make it work in a simple and fast way is often the hardest thing.

Answer 7

I think you are a naughty and have been caught out!

If it took 3 days to make a really nice piece of code you should have billed for 3 days, but if you spent a lot of time looking at other solutions to decide which is going to the best solution for the custom that is going to be maintainable then you have done a good job.

If the customer is not totally happy, I would suggest that this is the first ever solution like this you have done and you have spent a lot of time researching this system to get them the best solution. I would offer them 10-20 hours off the bill if they are not happy with the solution but is sounds like you still have to support this solution and figure out what the downfalls are.

Good Luck.

Answer 8

The customer hired you for your experience. He guessed you would apply that experience to produce a result better and faster than a less-experienced competitor. That's why your rate is higher - right?

Also, what if you hopelessly under-estimated a project? Who pays then? Would you not want to go back to the client and try to get some more cash out of them for the extra work? I know I would.

Honesty and transparency pay off.

Answer 9

When I start a new project with a client, I always try to get as clear an image of his schedule. Since, in the case of customers who have little experience with working with programmers, they won't know how to set you a schedule. Doing so I accomplish 2 things:

1. I define small bonuses for finishing the job well ahead of the agreed schedule.
2. I get a notion of why the customer set the initial schedule he told me. Because sometimes the customer is working on something with an already tight schedule, and he wants to think the task he gives you takes less time than it should.

I set an initial hourly rate for the project, and the bonuses for finishing quickly are relatively not large. It helps me keep my work interesting by not tarrying with it too long, and in the case I did find a fast solution, the bonus gives a feeling that your hour is worth more.

But it's important to remember that the bonuses are 2 sided. They serve as a motivation for the programmer, and as the value to the customer in receiving his work ahead of schedule. It doesn't work in all cases. And it's important not to abuse it.

Answer 10

Just querying your quote - Did this really take 45 hours to develop?? That crud system you have looks like it's very simple to do mate.......................

He is wondering if it really took you 45 hours to develop because it's a small amount of code. I don't believe in writing more code simply to satisfy the customer, instead account for how your hours were spent. Include time spent researching, time spent testing, debugging and refactoring. With this additional information the customer should be happier that it actually did take you the quoted amount of time to develop.