Written by: Michał Sobieraj, Operations Manager, Digital Colliers
We sell custom AI builds and we say no to most of them. That sounds backwards until you look at the numbers. More than 80% of AI projects fail, roughly twice the failure rate of conventional IT projects. When someone asks us to build something custom, the first question we ask is not what they want built. The first question is whether building makes sense at all.
The decision test we use has four parts. If you cannot answer yes to all four, the custom build is the wrong move. Here is what we ask.
Does the deadline actually exist
Most timelines people bring to a scoping call are not real deadlines. They are someone's guess at urgency. The test is simple: what breaks if you ship three months late. If the answer is a competitor ships first, that is not a deadline. That is a bet on market timing. If the answer is a regulatory compliance window, that is a deadline. If the answer is a board presentation or a demo at a conference, that is not a deadline. That is internal politics.
Real deadlines are binary. You either have regulatory approval by the cutoff or you do not operate. You either deliver before your biggest customer's contract renewal or you lose the contract. Everything else is negotiable. When 88% of AI proof-of-concepts never reach widescale deployment, shipping something that works matters more than shipping something on time that does not work.
If you do not have a real deadline, you have time to test whether an existing tool solves the problem at 80% of the outcome for 20% of the cost. That is almost always the better call.
Can an existing tool do this
The pattern we see most often is teams skipping straight to custom because they think their use case is special. It usually is not. The question is not whether Salesforce or HubSpot or whatever SaaS tool does exactly what you want. The question is whether it gets you 70% of the way there and whether that 70% is enough to validate the problem.
Custom builds cost more and take longer than anyone expects. They also lock you into maintenance. If you can validate the core workflow with an off-the-shelf tool, you learn whether the problem is real before you pay to solve it perfectly. When 95% of enterprise GenAI pilots deliver zero measurable P&L impact, betting big on custom before you have proof of value is a bad idea.
The test here is not whether the tool is perfect. The test is whether you can run a three-month pilot with the tool and measure whether the outcome justifies a bigger investment. If you can, do that first.
Do you have someone to own it
Custom software is not fire and forget. Someone has to own it after launch. That means responding when it breaks, making decisions about feature requests, and keeping dependencies patched. Most teams underestimate this. They think the build ends when the code ships. The build ends when someone internal can run it without external help.
The test is simple. Do you have someone on your team who can read the codebase, make small changes, and deploy updates. If the answer is no, you are buying a dependency that will rot. When 42% of companies abandoned most of their AI initiatives in 2025, the reason was not that the builds failed technically. The reason was that no one owned them after the vendor left.
If you do not have internal capacity to own the system, the better move is a vendor relationship where the vendor owns the infrastructure and you own the config. That keeps the dependency manageable.
When custom is the right call
Custom builds make sense when you can answer yes to all three tests above and one more: the custom version delivers a measurable advantage you cannot buy. That usually means a workflow so specific to your operation that no vendor will build it, or a competitive edge that depends on owning the implementation.
The teams that ship custom successfully do two things. They scope small and they build iteratively. They do not try to ship the whole vision in release one. They ship the smallest piece that delivers value, measure whether it works, and expand from there. The decision to build is not a one-time call. It is a series of small bets with clear win conditions.
Sources
- RAND Corporation, "Why AI Projects Fail" (PT-A2680-1, 2025), James Ryseff
- IDC with Lenovo, "The AI CIO Playbook 2025" (March 2025), via CIO.com
- MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (lipiec 2025)
- S&P Global Market Intelligence, 2025 survey of 1,000+ enterprises (North America and Europe)

