You are told to budget for two companies. You need one.
Buy the platform from a software company, then hire an IT firm to make it work — that is the default assumption in this market, and most buyers price it in before they have spoken to anyone. It is a choice, not a law. Here the people who build the product also do the implementation.
Where the two-vendor split actually costs you
Not in the invoice — in the seams. Every row below is a place where the gap between the two companies becomes your problem to manage.
Why the split exists at all
It is not a conspiracy — it is a consequence. Large platforms are built to be sold at volume, so they are configured rather than changed, and a partner ecosystem grows up to do the configuring. That works, and for a very large enterprise it is often the right shape. What it means for a company of twenty or two hundred is that you pay two margins for a system that still cannot do the one thing that makes you different.
What we do instead
We build the product and we do the implementation — the onboarding, the modules shaped to your workflows, the integrations, the data load and the training. Because it is one company, "the software cannot do that" is a decision rather than a wall, and it is a decision made by people who can go and change the software.
What we are not claiming
That one company is automatically better than two. A large enterprise with an internal IT function and a mature partner already in place has a working model, and we are not going to pretend otherwise. What we are saying is narrower and checkable: the split is not compulsory, and where you would otherwise be managing the seam between two suppliers, here there is no seam to manage.
Questions buyers ask
Do we need to hire an implementation partner for Alef?
No. Implementation is done by us — structured onboarding, modules built to your workflows, integrations, data loaded and verified, and team training. You can also take the system as it is built today with no implementation fee at all and just pay the per-app subscription; the build is a separate scoped engagement when you want one.
Is that not just a smaller company doing both jobs badly?
It is a fair worry, and the honest answer is that it depends on what you need. What one company buys you is that configuration and product change are the same conversation. What it costs you is the partner ecosystem a very large platform has — a choice of firms, local presence in many countries. If that ecosystem matters more to you than the seam, the two-vendor model is the right call and you should make it.
What happens to our customisations when you release an update?
Your configuration and customisation live with your account on top of the product, rather than as a fork beside it, so platform releases keep arriving. Where a change is deep enough to need ongoing care, that is scoped into the engagement rather than left as a surprise.
Who do we call when something breaks?
Us. That is the whole point — one contract and one support line, so a problem cannot be routed between two suppliers while you wait. This is a statement about who is accountable, not a published response-time guarantee; if you need contractual SLAs, that is part of the engagement conversation.
Tell us what you are trying to run
Bring the process that no off-the-shelf system has handled properly. That conversation is with the people who can change the product, which is the entire difference.