How should I inform my client that backend changes after a product launch is not just a bug fix or enhancement?

Question

My client and I agreed on an architectural design for an android application, which included the MySQL database. The application has been released, and has grossed a good number of users and data. The client is suddenly asking me to modify the back-end and use Firebase instead of MySQL because he talked to someone from Google who suggested Firebase would be better.

The client has a notion that integrating Firebase is a very simple task. How can I make the client understand that completely changing the back-end is not a minor enhancement or bug fix, and that this will take some time to implement and incur an extra cost? I'd like to politely explain these facts as there is a string chance of me securing another project from them which I am particularly interested in doing. Please offer your suggestions.

Answer 1

Just tell them the facts.

Hi.

Unfortunately, using Firebase isn't a simple change to the project and would involve a significant amount of rework of the architecture. As a very rough estimate, I think it would take about <some number> of weeks of effort. Shall we have a call to discuss further?

I suspect the answer here would then be "OK, don't worry about it then" but you never know.

Answer 2

By their nature the back-end elements of systems are essentially invisible to customers/end-users and as such they often have difficulty comprehending the amount of complexity and work that goes into them. It's not their fault, and it's up to devs like you and me to help them bridge that gap and put it in to terms that they can relate to. Metaphors are good for this, especially if you can use them to show the differences between a "bug fix" type change and a more significant change such as the one they are talking about. The exact one to use depends on the person you are talking to but likening it to things like changing a tyre (bug fix) vs a full engine change (changing to firebase) on a car , or replacing a window (bug fix) vs structural work on a buildings foundations (firebase) is the kind of thing that I'm talking about. This coupled with a reasonably detailed estimate/breakdown of the work involved should give you the best chance of them understanding

As a slight side note it sounds like you aren't convinced that the change offers any real value (or at least not enough to justify the work involved), if so I'd say it's worth explaining the pros/cons of the change, say that you are happy to do the work if they want but that you aren't sure it will give them value for money.

Answer 3

I'd say that ultimately, helping your client understand the complete technical scope of the desired change is not your problem. This actually sounds more like you haven't instituted a very good change-control process in your past interactions with the client, i.e:

• You're on a fixed price contract
• You've allowed the scope of the project to creep repeatedly in the past
• It's unlikely that you've been paid in "milestones", preferring maybe a deposit in the beginning and a big lump of money in the end.

If you've "trained" your client to believe that scope creep is a freebie, you shouldn't be surprised one bit at this stage. I've seen lots of situations where the client holds the final payment as a hostage over large last-minute changes, and it's not fair to the developer at all but many developers tolerate such behavior out of (innocent) ignorance.

Don't worry about project #2, because honestly you can go over to the 'Computer Gigs' section on Craigslist in any major city and see how many parties are trying -- daily -- to get work done for free with promises of additional work later. It's a very common hustle.

Be more concerned about this client not trying to get over on you for project #1. Set your price, and stick to it. I recommend you charge hourly, because beside your code changes, the client is also going to expect you to migrate the existing data to Firebase. Develop a written scope-of-work document, and have your client sign to it before you start any work. This step cuts down on misunderstandings later.

Answer 4

I assume you have a contract with the client.

For this change to come through you need a new contract bnecause it's work not covered by the initial agreement.

So to communicate that this is not a trivial thing, make him an offer where you specify the hours needed and a price for your work.

That's the best way to communicate this.

Answer 5

I would put together a detailed Estimate including all the tasks that would need to be done and the hours to do them and the overall cost. Don't forget the cost of moving the existing data to the new data source. As a guess I would estimate this to be several thousand hours of work, but you need to be much more specific than that, show them what needs to be done and what each major task of this would take.

I also would include a risk analysis describing the risk of introducing new bugs, the lack of data integrity, the chance that some data would be lost in transferring to the new database, etc.

Once you present it, either they will pay you a large amount of money to make the change or you will never hear of it again.

Answer 6

There is a very simple rule - the customer is always right. As long as the customer pays.

The cost is: Migrating all your data from MySQL to Firebase (without losing anything). Updating the client software. Convince all the end users to update their applications - that's a tricky one, because end users hate that kind of thing and you will have losses.

Updating the client software is most non-trivial. You will move from a well-tested application to something that is again in an alpha state. You will be moving from a standard and tested environment to a proprietary solution. There is cost involved, Firebase is not free and depending on what you are doing, it might not be cheap. And from things I read here and there on the internet, Firebase is easy for simple things but can turn into a nightmare when you go over the limits. MySQL will be here five years, ten years, 20 years from now. No guarantee with Firebase. Firebase will change whenever Google feels like changing it.

Finally, what is his source for his information? He talked to someone from Google? Firebase is a Google product. Of course someone from Google will praise it to high heavens.

So you will make an estimate for this "simple" change. The estimate will be based on your estimates, not on the clients opinion. If he thinks your estimate is too high, you can offer him as an alternative to do this work, paid for every day of actual work. You are most certainly not going to do it based on his low estimate. Tell him that you are a professional software developer, and you know better than a Google salesman.