I was working on an Android project. The client asked me to change the app design every few days, but it was very difficult to change the design in the middle of a huge project.

How would I deal with the client in such situations? Would making a contract and adding a clause at the start would be one way?

  • Are you on fixed price or time-based? If time-based, what's the problem? :) If fixed cost, have you asked them to make such changes billable? Commented May 22, 2013 at 6:40
  • its a fixed price. time is also fixed which is a huge problem in this case. I asked them to change the billable but they said it a very minor change so there is no need. But minor change also required changing the entire structure of the project which lead to lot of time wasting Commented May 22, 2013 at 6:41
  • 1
    Formally, you are bound to what's stated in your contract. We don't know its terms, and also we can't know if the changes are indeed minor. What you can do is (1) split a change into free and billable parts like I suggested here; (2) split your entire project into smaller deliverables, each of which would be fixed in scope, be accepted by a client, and any future changes (except bugfixing) would be billable separately. Commented May 22, 2013 at 6:49

2 Answers 2


I send them a bid for additional work. "Sure we can do that. It will cost $x more. Would you like me to get started?"

The basic point is that you are the expert in your work, and in your business. The customer is the expert in what the customer needs. What you are doing by treating the change request as an RFQ (Request for Quotation) is to push back and protect your own investment while leaving yourself open to do what the customer needs done if they need it that badly. Now I have been known to just do it when the amount of work isn;t very large. But when it is more than a small change, or if it is happening frequently, then I start using it as a negotiating point for more money.

This is also important because it puts your business in a more positive/professional light, while still respecting your customer.

  • 3
    This is absolutely right, I will just add one observation - this happens very often when client thinks in terms of solutions instead of requirements. He might want the app to have certain feel - and instead of describing that "feel" as requirement, he is trying to describe the app GUI that has that feel. Talk to him, find out what is behind those changes and you might find out that it is only one requirement - and maybe you can solve it easily and stop that madness.
    – Erchi
    Commented May 22, 2013 at 9:13
  • @Erchi, agreed. Also not a bad idea in these cases to ask for sketches. One case where it can legitimately happen is when the customer is thinking in terms of requirements and the programmer doesn't understand the requirements. I have occasionally had to step in and sort things out regarding projects where other consultants were involved, so I won't always say it is the customer, but not so infrequently is. Commented May 22, 2013 at 9:32
  • you are right of course. From the simple question I assumed simple situation but that doesnt have to be the case here and it can be the other way around (for me client thinking in terms of solutions is 80% of cases, but that is the nature of my work, for big projects it might be even the other way around).
    – Erchi
    Commented May 22, 2013 at 9:39
  • Yes, it's a freelance classic. C: I'd like to have feature X. Everyone should have it. F: Of course, it will cost Y$. C: Who would need X? It's no use for me ;) Commented May 27, 2013 at 20:33

As a contractor, you'll save yourself a lot of time and headaches if you sit with a client and work through mockups prior to the beginning of a project. This does two things that are worth their weight in gold.

First, it makes sure that the client is comfortable with what they are getting. Presenting them with something they can see and clearly understand helps eliminate miscommunications. Second, it makes sure you have a clear understanding of the clients needs and makes sure you start development in the right direction.

If a prospective client doesn't have a clear vision and plan for the project before you start. Tell them that that is the first thing you will need to help them address if they bring you on for the project. It's ok to bill them for the time spent helping them build out the project plan, but make sure one is in place before starting or things will drift and both you and they will end up frustrated and burnt out.

  • the point is not about contract. the contract was made carefully. What they asked was indeed a minor change in a huge app. Doing minor change caused lot of changes to the structure of the app which took lot of time. This used to happen frequently. There is no miscommunication. But the problem was dealing with changes frequently as the client insisted. Commented May 22, 2013 at 15:39
  • @Raghunandan - if it took major effort to change, then it wasn't a minor change. I'm not just talking about the contract. I'm talking about the project plan. It should be far more detailed than a contract and should cover all the functionality and make sure that it will operate according to the customer's needs. It should also make changes like this unnecessary and if they do come up, it should require adjusting the project plan and re-approval (and cost adjustment) based on the additional work required. Commented May 22, 2013 at 15:42
  • One other thought, if the change is truly minor and going to take under an hour or two to do, then it might not be worth pursuing the full procedure if it isn't common, but for frequent changes or anything that goes beyond that. A more formal change is really necessary. Commented May 22, 2013 at 15:44

Your Answer

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

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