There is one question that separates projects that go well from projects that get expensive halfway through, and it is almost never asked in time: do we solve this with a platform that already exists, or do we build something of our own? The answer usually gets improvised according to whatever the supplier happens to know how to do, which is exactly the wrong criterion.
Worth defining terms. A platform is any product already built where you configure rather than code: an automation tool, a CRM, a project manager, a vertical industry package. Custom development means writing your own code for a specific problem. Between those poles sits a large middle ground, and that is where most sensible projects end up.
Why the platform almost always wins at the start
Starting from an existing product is cheaper, ships sooner and creates no maintenance debt. Somebody has already solved the edge cases your company has not hit yet, and that invisible work is most of the value of mature software. On top of that, if the tool turns out not to fit, replacing it costs considerably less than throwing away your own code.
That is why our default position is to try to solve it with what already exists, even when the result is less elegant. A process running on a standard, boring platform beats a perfect process that depends on somebody maintaining a custom build every time a third-party API shifts.
When does the platform stop paying off?
The tipping point does not arrive through volume or user count. It arrives when the cost of bending the tool into doing something it was never designed for exceeds the cost of building it.
The signals are fairly clear. When the configuration starts accumulating chained workarounds nobody can explain in a sentence. When you are paying for three separate products because none of them covers the whole thing, and the combined monthly bill starts to look like a development retainer. When the company's most important process depends on a limit in the subscription tier. Or when the business does something no tool on the market contemplates, precisely because that is what sets it apart from competitors.
If what makes you money is exactly what no tool knows how to do, that is where building makes sense. Everywhere else, configure.
The mistake of costing only the entry price
The comparisons circulating online pit a monthly fee against a development quote and conclude the obvious. That sum is incomplete in both directions.
On the platform side it omits licence costs as the team grows, the middleware needed to glue it to the rest of the stack, and the risk of the price rising or the product changing direction without warning. On the custom side it omits what almost nobody budgets: keeping it alive costs between fifteen and twenty per cent of the build cost every year. A €20,000 build implies an unspoken commitment of three or four thousand annually, and whoever fails to plan for it ends up with an abandoned system within two financial years.
The middle ground, where nearly everything lands
In practice, most well-framed projects do not pick a pole. They use existing products for what the market already solves well (invoicing, payments, email, document storage) and build a small proprietary layer exactly where the business is specific. That layer is usually far smaller than the company feared: not a whole application, just a handful of processes and a database that governs the other tools.
This approach has an advantage that only shows up in year two. Because the proprietary part is small, it can be replaced without drama. And because the standard part is standard, you can switch supplier without rewriting anything.
Questions worth answering before deciding
- Is this process going to change much over the next two years? If yes, the platform gives you more room to manoeuvre.
- Is this process what differentiates us, or is it administration that every company in the sector does identically? Only the former justifies building.
- Who will maintain it, and on what annual budget? Without a concrete answer, it is not time to develop yet.
- If we wanted to leave tomorrow, what do we take with us? With an existing product you take the data. With a custom build you take everything, provided it is documented and the code is yours.
Where we stand
We are tool-agnostic, and we say so without ceremony: we gain nothing by recommending any particular platform and we take no commission from any vendor. That lets the conversation start from the problem rather than from a catalogue.
In most of the work that reaches us, the right answer turns out to be connecting properly what the company already pays for and building very little. When building is warranted, we build it, document it and hand over the keys. But reaching that conclusion on day one, without having looked at what is already there, is almost always a sign that somebody is selling hours.
Both routes are set out separately: automation on top of what already exists and custom software.