In over 10 years of working with PrestaShop I have never told a client "it can't be done". Not because I'm a superhero or because I know every line of this system's code by heart. The reason is simpler: over the years I've learned that "it can't be done" is almost always untrue. It can be done. The question is always different: how long will it take, how much will it cost, and is there a simpler path to the exact same business goal.
When a client comes to me with a requirement that sounds impossible, I don't say "it can't be done". I say: "I need a moment to think this through, I'll come back with a proposal". And I do come back. Always.
In this article I share four real cases from my practice that initially sounded like unsolvable problems. And how each one ended up as working code in production.
Integrating an ERP system that "can't be integrated"
The internal fear in every integration project sounds like this: every ERP system has a different data structure, different API, different business logic. Which means every integration is a project from scratch, every single time. With two systems that's still manageable. With five, it's a nightmare.
Working on the integration of two different ERP systems with PrestaShop (IFS and Impuls), I faced exactly this problem. The original approach assumed writing separate logic on the PrestaShop side for each of them.
I thought about it differently.
Instead of writing integration logic on the PrestaShop side every time, I wrote one generic integrator. All the logic specific to a given ERP system lives on its side. PrestaShop always receives ready, normalised DTO objects, regardless of where the data comes from. Another ERP system to connect? Data mapping and done. No new project, no rewriting the store's logic.
"PrestaShop doesn't support trade credit"
I heard this in the context of a B2B project. And technically it's true, default PrestaShop doesn't have a built-in trade credit module. But "default PrestaShop doesn't have this" is not the same as "it can't be done in PrestaShop".
I thought about it this way: trade credit is essentially a specific payment method with additional rules. Instead of looking for a ready-made module, I built a dedicated payment method available exclusively to the B2B customer group.
The end result: a B2B customer sees a "trade credit" option at checkout that nobody else sees. After placing and synchronising the order with the ERP, their credit balance updates automatically. When the limit is approaching exhaustion, the system sends alerts. The customer sees their current balance in their account panel. No PrestaShop core modifications, no hacks.
"To hide products for a customer group, you need to modify the core"
This is my favourite example, because "PrestaShop core modification" is a phrase that should trigger a red flag in every store owner's mind. Modifying the core means problems with every system update and technical debt that grows month by month.
The requirement was: B2B customers have individually negotiated prices for specific products. If a customer doesn't have a set price for a given product, they shouldn't see it at all, not in listings, not in categories, not in the menu.
It sounds like a task requiring deep system intervention. It turned out it wasn't.
The solution is based on the customer groups and specific pricing mechanism that PrestaShop has built in. The absence of a specific price for a given group on a particular product makes that product invisible to that group at every level of store navigation. Zero core modifications, zero technical debt, full compatibility with updates.
"You can't speed up this store without changing the hosting"
A classic. The store is slow, the client asks what to do, the answer comes: "you need a better server". Sometimes that's true. But often it's the simplest possible answer, not necessarily the right one.
In one project, the store's TTFB was 2.5 seconds. After analysis it turned out the main culprit was the way fonts were loaded. One change in the approach to loading assets, one concrete result: TTFB reduced to 0.3 seconds. Same hosting, same server, same database.
You can find the detailed description of this case study in a separate article: How I reduced PrestaShop TTFB from 2.5s to 0.3s.
How to recognise a good PrestaShop developer
Not by the fact that they say "everything can be done". Anyone can say that. You recognise a good developer by how they react when they encounter a requirement they don't know.
Bad signal: the answer "it can't be done" comes within a few minutes of hearing the requirement. This means the developer didn't look for a solution, they just confirmed they don't know how to do it immediately.
Good signal: "I need to think about this, I'll come back with a proposal in X". And they do come back. With a concrete proposal or with an alternative that achieves the same business goal by a different route.
An alternative is not a failure. Sometimes "it can be done but costs 80 working hours" while an alternative approach achieves 90% of the same effect in 8 hours. A good developer will present you with both options and help you make the decision. A bad one will say "it can't be done" and close the topic.
Summary
There are no bad client requirements. There are requirements that need more time to think through, requirements where the optimal solution is different from what the client imagines, and requirements where the implementation cost exceeds the business value. That last one is the only case where the honest answer is "technically it can be done, but it doesn't make business sense" and then I propose an alternative.
If you're looking for someone who doesn't say "it can't be done" when faced with difficult requirements for your PrestaShop store, check out SLA care packages or contact me directly.
FAQ
How can I tell if a developer really can't do something in PrestaShop?
Ask for technical details. A good developer will explain exactly what the obstacle is and why. If the answer is vague and contains no specific technical reasoning, that's a signal that "it can't be done" means "I don't know how and I don't want to look for a solution".
Is it always worth looking for a solution rather than an alternative?
Not always. Sometimes an alternative is the smarter choice, faster to implement, cheaper to maintain and achieving the same business goal. The key is that the client has a choice and understands the trade-offs of each option, rather than simply hearing "it can't be done".
What should I do when my PrestaShop developer says "it can't be done"?
Get a second opinion. Not because the developer is necessarily wrong, but because everyone has blind spots and limits to their experience. If two independent people say the same thing with specific technical reasoning, there probably is a real problem. If the second person immediately sees a solution, you have your answer.
