# What to Do When Your Developer Says "It's Not Possible"
A founder sent me a message three months into working with her developer: "He says adding a feature that shows users their subscription history is not possible with our current tech stack. Is that true?"
I looked at the tech stack. PostgreSQL database, Django backend, React frontend. I've built that exact feature on that exact stack dozens of times. It's a straightforward query and two UI components.
It wasn't technically impossible. It was a matter of priorities, complexity estimates, or something the developer didn't know how to do. Those are very different problems - but they all come packaged in the same phrase: "It's not possible."
The Three Things Developers Usually Mean
When a developer says something is "not possible," they typically mean one of three things, and each requires a different response.
The first is genuine technical impossibility. This is rare but real. True technical limitations do exist: you can't make a server respond in negative time, you can't make a mobile app work without network connectivity in certain scenarios, you can't legally process certain types of data in certain jurisdictions. When a developer says something is genuinely impossible, there's usually a clear technical reason they can articulate precisely.
The second is "not possible given our current constraints." This is the most common use of "impossible." It usually means: not possible in our timeline, not possible with our current architecture without significant refactoring, not possible at the price you're expecting to pay, or not possible without expertise we don't currently have. These are real constraints but not hard limits - they can be overcome with resources, time, or different approaches.
The third is "I don't know how to do this." Developers, especially early in their career, sometimes express knowledge gaps as technical impossibility. It's not dishonesty, usually - it's that they genuinely can't see a path to a solution and interpret that as the solution not existing.
Understanding which one you're facing determines how you respond.
How to Distinguish Between Them
The first thing to ask: "Can you explain specifically why it's not possible?"
A developer who means genuine impossibility can explain it precisely, reference the technical constraint, and tell you what world would have to be different for it to become possible. "We can't push real-time updates to users without a persistent connection or polling because HTTP is a request-response protocol" - that's a real constraint with a real explanation.
A developer who means "not possible given constraints" will usually start describing the complexity: "we'd have to refactor the data model, it would take weeks, we'd need to change the API structure." That's not impossibility - that's a cost estimate.
A developer who means "I don't know how" will often be vaguer. "It's just not the way this technology works" without specifics, or "I've never seen this done before," are signals worth following up on.
How to Push Back Constructively
Pushing back on "impossible" claims is a legitimate part of managing a development relationship, not a sign of distrust. Here's how to do it without damaging the relationship.
Ask for alternatives rather than contradicting. "If we can't do it that way, what's the closest thing we can achieve? What would get us 80% of the value?" This reframes the conversation from "you're wrong" to "let's solve the underlying problem." It also forces the developer to engage with the goal rather than the specific implementation.
Ask for second opinions when stakes are high. If the impossible feature is business-critical, bring in an outside technical resource for an hour to evaluate it. Frame it to your developer as: "I want to make sure we're exploring all our options before we scope this out." Most developers don't take this personally when framed correctly.
Separate the constraint from the approach. If a feature is constrained by the current architecture, ask: "What would we need to change about our architecture to make this possible? Is that worth doing, and what would it cost?" Sometimes the answer is genuinely no - the refactoring required is too expensive. Often the answer is that a targeted change enables the feature without a full rewrite.
When They're Right
Non-technical founders sometimes overcorrect and assume every "impossible" claim is an excuse. Some are not.
Developers are right about impossible when they can point to fundamental constraints: browser security policies that prevent accessing certain data, third-party APIs that don't expose certain functionality, regulatory requirements that genuinely prohibit specific data handling.
Developers are also right when the complexity is accurately described and the ROI is genuinely poor. If a feature would take eight weeks to build and serve 3% of users, that might be the right call to deprioritize.
The key is demanding enough specificity to evaluate the claim. "Impossible" without explanation is not acceptable. "It would take six weeks of backend refactoring because our data model doesn't support this relationship structure" is evaluable - you can decide whether six weeks is worth it.
Building a Culture Where Developers Surface Problems Early
The deeper issue behind frequent "impossible" claims is often cultural. Developers who feel unsafe giving bad news early start giving it late - disguised as impossibility. The feature has been known to be problematic for weeks, but the developer didn't raise it because they were afraid of the founder's reaction.
The pattern I see in healthy development relationships: developers bring problems early when they're still options. "I'm starting on the subscription history feature. I noticed our data model doesn't store the information we'd need. We have two options - I can modify the model which takes three days and carries some migration risk, or I can build it from transaction records which takes five days but requires no schema changes. What would you like me to do?"
That's not impossible. That's a developer who feels safe surfacing problems and offering options.
Creating that culture means rewarding early problem-surfacing, not punishing it. When a developer tells you three days into a sprint that a feature is more complex than estimated, the right response is "thanks for telling me early - let's reprioritize," not frustration that the estimate was wrong.
The founder whose developer said subscription history was impossible? I connected her with a developer for a two-hour consultation. It took two days to implement. The original developer was junior and genuinely didn't know the approach. We didn't fire him - we got him better technical mentorship, and he stopped having "impossible" features after that.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr