Whether you're receiving requests from your product manager in a large company, or from your client as a freelancer, the process is the same.

Everything is "critical"!

You're rushing to complete all the features for an upcoming launch, and your client comes with new feature requests. What's more, they are "urgent", and "critical". "We can't ship without it" is something you will hear often. The truth is, it is often not as critical as they may think. The client of a friend of mine once requested a favicon for their webapp MVP, it was "critical" for launch.

Don't say yes immediately

Your client is right in front of you, you can see the excitement in their eyes, and they are pleading for this awesome additional feature that will delight the user. How can you say no? Well, don't say yes just yet.

Scope (number of features), Time (to develop) and Quality go hand in hand (see https://en.wikipedia.org/wiki/Project_management_triangle). If you increase the Scope (number of features), it will necessarily either take more time and money to complete it all (hence ship later), or you will rush to ship on time and quality will suffer. It is unrealistic for anyone to expect you to build more, at the same quality, and still ship on the same date.

First, evaluate the request. Clarify to understand what problem they are trying to solve, and see if there are alternative, simpler solutions to solve it. Then figure out how much effort it would take you to build. Now that you have a good idea how long it will take you, it's time to announce the price and to prioritize.

Re-prioritize or push the date back

Announce the price:

I can build X for you. Since this is additional work not included in our contract, it will cost you $$$ and take K days to complete.

And give them a choice:

X will take K days to complete. So we can either push back the launch date by K days, or we can de-prioritize another feature of similar size. Out of all the features we had agreed to complete by launch date, can you pick one that we'll do after launch instead?

Don't work overtime

There's another alternative, you might think. Just stay up all night and code away, right? Or code on your weekends. That way, you write more code at the same quality, and you can still ship on time!

In fact, this is a vicious circle, because as you work longer hours, your concentration will decrease. So instead of taking let's say 2 hours to write a functional, cleanly-written feature, you will have taken 4 hours to write a buggy, badly-written feature, plus an additional 2 hours to fix the bugs after the fact. That's what fatigue does.

So don't work overtime. This way you will be well-rested and efficient all the time.