We are a custom software studio, so read what follows with the appropriate suspicion. Then notice that most of it argues against buying from us.
That is not modesty. It is that the projects which go badly are almost always the ones where a standard tool would have been fine, and the client and the supplier both wanted it to be interesting.
Start from the opposite assumption
The default should be: buy something. Off-the-shelf tools are enormously cheaper than they look, because the price you compare is a subscription against a build, and the real comparison includes the fact that somebody else maintains it, fixes it, and adds to it forever.
So the question is never "would custom be better". Custom is almost always better in the sense that a bespoke suit is better. The question is whether the difference is worth what it costs, and for most processes in most companies, it is not.
What each one is actually good at
Airtable and similar. Outstanding when the shape of the data is still changing and the number of people is small. It is a spreadsheet that learned about relationships and permissions. Where it stops: when you need real validation, when the logic is more than a formula, and when the per-user cost starts scaling with a team that is mostly reading.
Monday, Asana, ClickUp. Genuinely good at work coordination: tasks, stages, who is doing what. People try to run inventory and invoicing in them, which they are not, and the tell is when the board has columns nobody updates because updating them is manual.
Odoo. Underrated in Romania and worth serious consideration. It is a real ERP with real accounting, and there are local partners who know the fiscal side. Where it hurts: the moment your process does not match its process, you are into customisation, and Odoo customisation is a specialist skill with its own supplier lock-in. "Custom Odoo" is not a cheaper custom system, it is a custom system with a large opinionated framework underneath.
Custom. Right when a specific workflow is genuinely how you compete, when the integration surface is the point, or when the per-seat maths has turned against you at scale.
The three signals
In our experience the decision comes down to whether any of these is true. If none are, buy something.
One: you are bending the business around the tool. Not "we had to change a habit", which is usually healthy. The real signal is a process step that exists purely to satisfy the software, and a person whose job is partly to be a workaround. Export to Excel, fix it, import it back, weekly.
Two: the integration surface is the actual job. If most of the value is in making four systems agree, no single product will do it, because each of the four thinks it is the centre. This is the most common case in Romanian companies and the most consistently mis-scoped, because it looks like a system problem and it is a plumbing problem.
Three: the per-seat maths has flipped. Twelve users at 30 EUR a month is 4.300 a year. Forty users is 14.400 a year, forever, and rising with headcount. Against a one-off build, that changes the answer somewhere between those two numbers, and where exactly depends on how much of the tool you actually use.
Notice that only the third is about money and it is the least common reason people call us.
The two tests we use on a discovery call
The Excel test. If you already have a spreadsheet doing this, what is in it that the standard tool cannot represent? If the answer is "nothing, we just have not moved it", the project is a migration, not a build. If the answer is a column full of logic nobody can express in the tool, that is signal one.
The leaving test. Imagine the tool doubles its price next year. What do you do? If the answer is "grumble and pay", the process is load-bearing and you have a lock-in question worth pricing. If the answer is "move", you are fine and should stop worrying.
What we actually recommend, most of the time
Keep the standard tool for what it is good at. Build the one thing it cannot do. Connect them.
That is the cheapest correct answer in most Romanian SMEs and it is almost never the answer people expect, because it is less satisfying than either "buy a platform" or "build a system". It is also the reason our integration work is priced per scope rather than from a floor: it is usually smaller than the system somebody arrived asking for.
If a supplier tells you that everything should be custom, they are selling. If a reseller tells you their platform does everything, they are also selling. The useful conversation is the one where somebody asks what your spreadsheet columns are, and what they cost you, before proposing anything.