4

I did create for customer webcrawler application. It's running fine on my local server, although customer asking me to debug application on his server, because there is exception thrown on product server.

This is a fixed price job and the point was not discussed previously. Should I do it?

4
  • 1
    why wouldn't you?
    – user152
    Jan 1, 2015 at 10:45
  • This point was not discussed previously. So I'm thinking - is it extra job or not? Jan 1, 2015 at 11:09
  • Is the job fixed price or hourly?
    – user152
    Jan 1, 2015 at 11:42
  • That's fixed price job. Jan 1, 2015 at 11:56

4 Answers 4

7

I would have to say that this is an opinion based question and there is no right or wrong answer. My answer is based on my desire to do the right thing for my clients.

I would say yes, but to a point.

Perhaps this is a bug that was in your application? Whether the project was fixed bid or hourly, it is your responsibility to deliver a working application.

If you didn't account for issues and the resolution of those issues in your quote then chalk this up to a learning experience and factor those items into your next project.

Now, once you investigate the issue you will learn if this is a bug with the application that you provided or if the client has done something to affect it.

If it was a bug, then fix it.

If it was something caused by the client, then quote them a price to fix it.

0
2

The client is paying you to develop software for them that they expect to just work. They are probably not sophisticated enough to understand that their environment might be an issue, and they probably assumed you - the professional programmer - considered the circumstances before you gave a price. If you ask for more money to debug it they are going to feel like you deliberately tricked them with your pricing.

I would debug it on their system. If it turns out there is something on their system that shouldn't be that is causing the problem that will cost you a lot of hours then you might say "This is extra because ____" but only if it takes a lot of time.

Use this as a learning experience and next time you bid on a project be sure to include minimum system requirements that the software will work on, and maybe give a price for the main project plus an optional extra item for more $ to "debugging on your system". Then if they don't take that you are covered. (I'd keep the price separate in case you're bidding against people who don't include debugging and come in with a lower price.)

As you bid on more and more projects you will start to learn the things you need to protect yourself from. Some things I cover in my proposal are:

  • The environment, when I have clients with multiple computers I say it's guaranteed to run on ONE system setup (their firm standard). IF it doesn't work on another computer, I'll trouble shoot but charge.

  • System changes - once I have it running on their system, if they change anything, (new OS, computers, new software that interferes, etc. that will be extra to troubleshoot. I can't control how their system might change!

  • Limited time for them to test. If they find a bug 2 years from now, even if it's due to my mistake, it's not reasonable for them to expect me to drop everything and fix it for free. (I will if I have time, but there are some people will not use the software for the longest time then start finding little things. You can't become their programming slave!

  • limited liability - if they think my software damaged something they can't get more $ from me than they paid for the software.

I offer an annual maintenance agreement, and if they turn it down, then they need to pay T&M for any fixes/updates, and I have a minimum X-hours for that type of work. Ironically, The type of people who turn down the maintenance agreement are usually the needy ones and you have to make them pay or they will suck you dry with requests/changes. But that is after you delivered a working product for them.

If you have to eat some hours on this, just know you've learned for next time. I think most of us have probably eaten a LOT of hours in the early days, not realizing all that would be involved.

1

Yes, you should debug your application, it is an essential part of making software. You don't get paid extra for it, but debugging is just to make sure it works and fix potential problems. If the client demands anything more, than you should consider charging them.

1

As freelancers, we operate in a different world than large software houses or contract development firms. It's all fine and good for them to say "Read the EULA" or "You need to check section 3.1.4 paragraph 2 of our universal development contract." We need to be more responsible to our clients to keep our businesses going.

When a client engages you, they are expecting you to deliver a solution that works for them in their environment. They are probably not sophisticated enough to understand all of the nuances of development, test and production environments, and frankly they shouldn't have to be. That is the value that we are supposed to provide.

When you start a project, it is your responsibility to understand the environment that your solution will eventually run in. If the solution runs on your machine(s) and not theirs, then you haven't really solved the problem you were engaged to solve. Obviously, there are reasonable limitations based on too many different environments or the customer changing the environment. These should be covered in your contract. But if there are problems right out of the gate running in their environment, your job is not done yet until it runs correctly.

1
  • you said "If the solution runs on your machine(s) and not theirs, then you haven't really solved the problem you were engaged to solve." That is a really good point.
    – Emily
    Jan 12, 2015 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.