How to Politely Push Back on Unreasonable Demands

by Arif Ikhsanudin, Backend Developer

Clients can sometimes ask for the impossible—or the unreasonable.
Here’s how to set boundaries without burning bridges.

Recognize When It’s Too Much

First, identify the difference between challenging and unrealistic.

  • Look for tasks that conflict with your timeline, budget, or expertise.
  • Note requests that compromise quality or violate best practices.
  • Trust your instincts: if it feels off, it probably is.

Key: A quick reality check saves stress later.

Respond Calmly, Not Emotionally

Your tone is everything. Responding with frustration only escalates tension.

  • Use neutral language like “I want to make sure we maintain quality here.”
  • Avoid words like “impossible” or “never”—frame it as a constraint.
  • Keep sentences short, clear, and solution-focused.

Tip: Calm communication shows professionalism, not weakness.

Offer Alternatives

Clients respect pushback when paired with options.

  • Suggest adjusted timelines, scaled-down scope, or phased delivery.
  • Show how your alternative meets their goals without overextending.
  • Be flexible, but don’t sacrifice core standards or your well-being.

Pro insight: Alternatives make it a discussion, not a rejection.

Set Clear Boundaries

Being upfront prevents future conflicts.

  • Explain your workload, priorities, and realistic capacity.
  • Use statements like “I can focus on X first, then address Y by [date].”
  • Document agreements in writing to avoid misunderstandings.

Remember: Boundaries are a sign of reliability, not rudeness.

Keep Perspective

Pushing back is part of healthy professional relationships.

  • Clients may be testing limits, not attacking you personally.
  • Standing your ground can build trust, not tension.
  • Reflect on each experience to improve future negotiation strategies.

Closing line: Politely pushing back isn’t confrontation—it’s smart, professional self-respect that keeps projects—and relationships—on track.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

How to Write Rails Migrations Without Causing Downtime

Most Rails migration patterns that work fine in development will lock tables in production. Here is the mental model and specific techniques for schema changes that deploy safely on live databases.

Read more

The Difference Between a Message Queue and an Event Stream

Message queues and event streams are often discussed interchangeably, but they have different semantics, different use cases, and different operational characteristics. Choosing the wrong one creates problems that are hard to fix.

Read more

Second-Level Cache in Hibernate — When It Helps and When It's a Trap

Hibernate's second-level cache sits between the application and the database, caching entities across sessions. Configured correctly it eliminates repeated reads. Configured wrong it serves stale data silently, produces hard-to-debug invalidation failures, and breaks distributed deployments.

Read more

The Best Architecture Decision Is the One You Can Explain to Your Team

An architecture that requires deep expertise to understand is an architecture that only one person can safely modify. Explainability is not a soft requirement — it is a hard constraint on how well a system can be maintained.

Read more