Before choosing a technology, you need to choose what you really want to build.
You’ve been asked this question as if the answer were obvious. WordPress or custom development? Shopify or a proprietary platform? And on either side, two camps that don’t understand each other: the “We’ll code it ourselves” crowd and the “Why reinvent the wheel” crowd.
The real problem is that the question has been framed wrongly from the start. The real question isn’t “Which tool should we choose?”, but “What genuinely deserves to be custom-built in your company?”
This isn’t a technology question. It’s a strategic one. And answering it without first pinning down what you’re building – a working tool, a sales channel, a differentiating platform or simply a showcase – means risking making the right technical decision for the wrong problem.
So let’s start again. Properly.
When is an off-the-shelf solution the best choice?
Many executives, as soon as they hear “off-the-shelf”, instinctively picture something generic, cramped, a compromise. That’s wrong. A well-chosen off-the-shelf solution means years of development, thousands of bugs fixed before you arrived, and a community that keeps improving it while you sleep.
Think of Stripe for payments. Notion for internal content management. HubSpot for CRM. These tools aren’t crutches; they’re resource allocation decisions. Every hour you don’t spend maintaining a payment infrastructure is an hour invested in what truly sets you apart.
The real strength of an off-the-shelf solution is its speed of execution. Do you have a tight budget? A short time to market? A functional need that already exists elsewhere? Then the right decision isn’t necessarily to go custom. It’s often to smartly assemble what already exists, and focus development energy where it matters.
Things get complicated when the off-the-shelf solution becomes an operational constraint. When you start “working around” its limits. When your business processes bend to a tool’s logic rather than the other way round. When your sales team spends Friday afternoons importing CSV exports because two systems don’t talk to each other.
At that point, the cost of off-the-shelf is no longer in the monthly license; it’s in lost time, reduced agility and missed opportunities.
“The real debt isn’t technical. It’s in every process you’ve adapted to your tool, instead of adapting your tool to your processes.”
When does custom development pay off?
When you mention custom web development to an SMB leader, the first reaction is often the same: “It’s expensive, it takes forever, and it always ends up going off the rails.” That reputation isn’t entirely unfair. But it describes poorly scoped projects, not an inevitability inherent to the approach.
A well-run custom project starts with a question many avoid: what exact problem am I solving? Not “I need an e-commerce site”. But: is my conversion dropping because the checkout funnel is flawed? Because my catalog is unreadable? Because returns management is an operational disaster? These questions have different answers, and sometimes they don’t call for the same solution at all.
What justifies custom development is the uniqueness of the business process. If what you do doesn’t exist anywhere else exactly the way you do it, then the likelihood that an off-the-shelf tool will serve you perfectly is low. And in that case, insisting on forcing your business into the boxes of a generic tool will cost you – over time – far more than targeted development.
So the question isn’t “Custom or off-the-shelf” in absolute terms. It’s: at what precise point in my value chain does my uniqueness deserve to be translated into code?
A concrete example: an industrial SMB with complex order cycles, key-account customers and configurable products. No standard CRM covers that cleanly. But their internal emails and calendar? Google Workspace, without hesitation. The right mix isn’t “All off-the-shelf” or “All custom”; it’s knowing where to set the cursor.
Choosing the team matters as much as choosing the technology
There’s a dimension often forgotten in this debate: the who. People talk a lot about the what (off-the-shelf or custom) and not enough about who will build it, maintain it and make it evolve.
For an SMB going down the custom development route, the question of human resources is central. Hiring an in-house team in France to build a complex business application? That equation is tough. Finding available senior profiles, retaining them, managing vacations and sick leave: it’s a real HR burden that many executives underestimate.
This is where an option more and more SMBs are seriously considering comes in: offshore development, and more specifically the offshore dedicated team model.
The idea is simple: you build a team of developers in a cost-competitive country (Madagascar, Mauritius or Morocco, to name common examples), which works exclusively for you, with your methods, your tools and your processes.
This isn’t blind outsourcing. It’s an extension of your team, with the difference that the hourly cost is structurally different. And contrary to popular belief, quality isn’t necessarily sacrificed, provided you choose your partner carefully, take care over the initial scoping and invest in communication.
Offshore development long had a bad reputation, often for good reasons: poorly specified projects, unmanageable time zones, seniority levels that didn’t match what had been sold.
But the last ten years have changed a lot. Asynchronous collaboration tools, distributed agile practices and the growing expertise of tech ecosystems in certain countries have radically changed the game.
The offshore dedicated team: an alternative for SMBs
The offshore dedicated team model addresses a very concrete problem: you need sustainable development capacity, not just for a one-off project. You don’t want to manage a provider juggling ten clients. And you don’t have the means, or the desire, to build a complete in-house team.
What a dedicated team gives you is continuity. The developers learn your codebase, understand your business constraints and develop a real product sense. It’s the difference between having someone who ships features and someone who understands why those features exist.
There are conditions for it to work. The first is having someone in-house, on the SMB side, who can act as the link. Not necessarily a full-time CTO, but someone who can frame priorities, review specifications and make technical trade-offs. Without this role, even the best dedicated team spins its wheels.
The second condition is a transparent selection process. Not all offshore development agencies are equal. The difference between a successful collaboration and a budget disaster often comes down to a few details: what is the real seniority level? What is the team’s turnover rate? What testing and delivery processes are in place? These questions must be asked before signing.
CMS or custom development: the questions to ask before choosing
Here’s how we approach the question with our clients, in practice. Not a checkbox matrix, but a series of questions that force you out of vagueness.
Does your competitive advantage depend on your digital tool? If so, if the way you work is different enough to show in the code, then custom development is a serious option. If not, go for off-the-shelf and don’t be ashamed of it.
Do you have processes that don’t fit into any existing box? If every tool you test requires heavy workarounds, that’s a strong signal. But distinguish between “We need to adapt our habits” (normal, often healthy) and “The tool can’t do what we do” (a real problem).
What is your internal capacity to scope and steer a development project? This may be the most underestimated question. A custom project without rigorous steering is a car without a driver. If you have no one able to fill this role, solve that before choosing your stack.
What is your time horizon? If you need something in six weeks, off-the-shelf almost always wins. Custom development takes time for scoping, development and testing. It’s an investment that pays off over time, not over a single sprint.
What budget can you allocate over three years, not just for the initial project? This is often where the calculation flips. An off-the-shelf solution at €500/month over three years comes to €18,000. Well-executed custom development can end up cheaper over time if the operational gains materialize. But you have to do the math honestly, including maintenance, enhancements and the cost of the off-the-shelf solution’s constraints.
What really works in SMBs
In practice, the SMBs that do best don’t make a binary choice. They build a hybrid architecture. Front office on off-the-shelf tools (showcase website, e-commerce, sales CRM), back office custom-built (internal management tool, connector between systems, specific business interface). And they move this cursor over time, according to their growth and constraints.
What also works is starting small. One module. One building block. Not a digital big bang. Testing an offshore dedicated team on a limited scope before entrusting it with all of your product development. Validating that the collaboration works, that quality is there, that deadlines are realistic. Then expanding.
And what fails, almost systematically: projects that started without serious scoping. Specs written in two days. Budgets set before the scope was defined. Development teams chosen on price alone. It isn’t custom development that fails in these cases; it’s the process.
“Custom web development isn’t riskier than any other investment decision. It’s just less forgiving when it’s poorly prepared.”
How to avoid making the wrong decision
There’s a bias in this conversation that I want to name explicitly. When a development provider recommends custom development, ask yourself whether it isn’t because that’s its business model. When a SaaS vendor sells you its solution as “flexible enough for everything”, ask yourself what “everything” really means in your case.
The right decision doesn’t belong to your provider. It belongs to you. And it starts with an hour of honest work on what you’re really trying to build, before you even open a browser to compare tools.
Because the real risk isn’t choosing off-the-shelf when you should have gone custom. It’s never having asked yourself the question at the right time.
Torn between off-the-shelf, a CMS or custom development?
Every company has its own constraints, processes and objectives. That’s precisely why there is no universal answer.
At Etixio, we help SMBs step back before launching a digital project: understanding what calls for an off-the-shelf tool, what deserves specific development, and how to build a solution that is consistent with business challenges and available resources.
If you’re thinking about a web project, a business application or building a development team, let’s talk about your context.
