When Your Vendor Says "It Can't Be Done": A Four-Layer Test for SMEs

Last month a 12-person skincare e-commerce brand came to us. Their site rebuild was quoted at NT$180,000 and stalled in week six: the owner wanted a shipping notification pushed automatically over LINE after each order, and the vendor replied "LINE can't do that" and went quiet. The owner had exactly one question for me — is this genuinely impossible, or does he just not want to build it?

I get asked this more than twenty times a year, and the answer is different every time. The real problem is not vendors lying. It is that most owners have no method for taking "it can't be done" apart, so they guess. A wrong guess usually costs two months and six figures in NT dollars.

Four common misreadings of "it can't be done"

Myth 1: "Can't be done" means technically impossible. Reality: in the projects we have handled, fewer than one in ten are truly impossible. The rest are "not worth it under your current budget, timeline or architecture" — and those two situations call for opposite responses.
Myth 2: Another vendor will manage it. Reality: if the constraint comes from a platform or a law, every vendor hits the same wall. Apple requires digital content to be sold through in-app purchase, and outside the US storefront an external purchase link needs an approved entitlement (App Store Review Guidelines 3.1.1), while a LINE push message requires a user ID, which means the recipient must already have added your official account (LINE Messaging API documentation). Switching vendors here just pays to run the same requirement twice.
Myth 3: Asking "why can't it be done" gets you an answer. Reality: that question returns a pile of jargon. The question to ask is "whose constraint is this".
Myth 4: A vendor who says yes to everything is safer. Reality: the vendor who never says no is the higher risk. The problem simply surfaces late in development, where rework costs three to five times more than it would have upfront.

The core framework: the four-layer constraint test

Drop every "can't be done" into these four layers and your next move becomes obvious.

Layer	Source of the constraint	Negotiable?	What you do
L1 Platform / law	Apple, Google Play, LINE, payment providers, privacy law	Not negotiable	Demand the official documentation link, then find an alternative route
L2 Architecture	Existing system, database, legacy ERP design	Negotiable at a price	Ask for an hours estimate to change the foundation
L3 Resources	Budget, schedule, headcount	Fully negotiable	Cut scope, phase it, or add budget
L4 Willingness / skill	Team is unfamiliar, or does not want to maintain it	Change approach or people	Ask how long it would take someone who knows the domain

Memorise one sentence: "Is this a platform rule, a system architecture limit, a budget and schedule limit, or unfamiliarity? Please send me either an official documentation link or an hours estimate." An honest vendor returns one of the two within three business days. A vendor who can produce neither is almost always at L4.

Three companies, one sentence, three different conclusions

12-person skincare e-commerce (LINE shipping notice): L1. The alternative is a notification-type message from the official account, or SMS at roughly NT$0.8–1.2 per message; 12 hours of development, about NT$24,000, and the problem is closed.
60-person metal fabrication plant (real-time ERP integration): the legacy ERP has no API, so this is L2. A staging database with a 15-minute sync job costs NT$220,000 over six weeks; true second-level real time means replacing the ERP, from NT$1.5 million. The word "real-time" is the cost driver, not the integration.
200-person salon chain (in-app top-ups without platform commission): L1, and Google Play's payments policy aligns with Apple's. The alternative is moving the top-up flow to the website and letting the app display balance only — roughly NT$960,000 a year in commission avoided.

What a wrong call costs

Reading L1 as L4 and switching vendors: 40–60 hours of re-tendering and handover, NT$80,000–150,000 to redo requirements, two to three months lost — and the answer is still no.
Reading L4 as L1 and accepting it: the feature never exists and humans fill the gap. At 20 hours a month and NT$350 an hour, that is NT$84,000 a year, paid indefinitely.
Reading L2 as L3 and throwing budget at it: features stacked on a bad foundation add about 30% to every later change, and the eventual refactor typically costs two to three times what you saved.
Hiring the "we can do anything" vendor: late-stage rework commonly runs 25–40%, meaning an extra NT$45,000–72,000 on a NT$180,000 project, with no reliable delivery date.

Credibility scorecard for a "no" (10 dimensions, 0–2 points each)

Names which layer the constraint sits in
Supplies an official documentation link or clause number
States the specific condition (for example "requires prior user consent")
Proposes at least one alternative route unprompted
Attaches hours and cost to that alternative
Explains what insisting on the original requirement would cost
Responds within three business days
Explains it once in language you understand
Has a track record of admitting "I don't know this area"
Is comfortable with you seeking a second opinion

Reading: 16 and above, believe it. 10–15, ask for the missing evidence before deciding. 9 or below, spend a small amount on a technical second opinion before you decide anything about the relationship.

How we take these on — and who we turn down

The engagement we are most often hired for is a technical second opinion (Advisory): NT$18,000 over 10 business days, delivering a four-layer verdict table, the official sources behind each verdict, and two to three alternative routes with individual quotes. You can take it straight back to your existing vendor without replacing anyone. Only if the verdict is L2 and you decide to rebuild does this become a Project engagement, moving to a Retainer from NT$25,000 per month after launch.

We decline outright when:

The goal is a report for litigation or to extract compensation from a vendor
You will not grant access to the existing system or source code
You want us to prove the incumbent is lying rather than establish what is true
The requirement itself is not settled and you only want a number

90-day playbook

Week 1: list every requirement that got a "can't be done", send the standard question against each one, and require a written reply.
Weeks 2–4: assign a layer to each reply. L1 goes straight to alternative routes, L3 goes straight to a scope and budget conversation, L2 and L4 go to a second opinion.
Months 2–3: ship the alternative route as a minimum viable version, prove the workflow holds, then decide whether the full build is worth funding.
Day 90: review three numbers — how many blocked requirements are resolved, how many manual hours per month you removed, and whether vendor response time improved. Only if none of the three moved is replacing the vendor the right answer.

Decision checklist

☐ I have a written reply, not a verbal remark
☐ The vendor can name which layer the constraint sits in
☐ I have seen an official documentation link or clause number
☐ I verified the domain belongs to the platform itself
☐ At least one alternative route was proposed
☐ That alternative has hours and a price attached
☐ I know what insisting on the original requirement costs
☐ This requirement has a measurable revenue or cost impact
☐ I have calculated the annual cost of the manual workaround
☐ The contract states how change requests get priced
☐ I know where the source code lives and who holds access
☐ I am willing to pay for a small second opinion before deciding

FAQ

If a vendor refuses to provide an official documentation link, is he lying?

Not necessarily, but it is one of the strongest signals available. Platform-level and legal constraints are always written down publicly — data handling duties, for instance, are set out in Taiwan's Personal Data Protection Act. A vendor who cannot produce a source usually never checked one, which means the "no" was an impression rather than a finding.

I am not technical. How do I confirm the document actually supports the claim?

Three checks are enough: confirm the domain is the platform's own (developer.apple.com, developers.line.biz and the like), ask the vendor to point to the specific clause, and paste that clause into any AI tool and ask for a plain-language explanation. If all three line up, accept it.

Once I conclude it is L4, do I have to replace the vendor?

No. Most L4 cases are domain unfamiliarity — e-invoicing, for example, must follow the specification published by Taiwan's Ministry of Finance E-Invoice Platform. Carving that one piece out to a specialist while the incumbent keeps the rest is cheaper and faster than moving the whole project.

How do I judge whether a quote for one extra feature is reasonable?

Ask for it split three ways: interface, backend logic, and testing plus deployment. Reasonable hourly rates on small and mid-sized Taiwanese projects typically land between NT$1,200 and NT$2,000. If you receive only a total with no hours, or the hours contain no testing, something is usually wrong.

Next step

If a single "can't be done" is currently blocking your project, send us the requirement, the vendor's reply and a short description of your existing system. We offer a free 30-minute consultation, run the four-layer test on the call, and tell you whether you are facing a non-negotiable platform rule or a quote you can negotiate. Nothing to sign first.