Custom software versus SaaS gets argued on features the team needs and the price of the subscription. The actual decision is about reversibility and maintenance gravity — two factors that determine whether the choice produces three years of confidence or three years of regret. The math is structural; the wrong answer costs the rebuild plus eighteen to thirty-six months of operating on the wrong platform.
Four questions determine the right answer.
Question one — is the workflow truly differentiated, or is it standard with cosmetic variations? Most "we have a unique process" claims are not unique — they are standard processes with team-specific terminology. SaaS handles standard processes well. Custom software is justified only when the workflow produces measurable economic value the standard alternative cannot capture. The honest test: would three competitors in the same industry recognize the workflow as their own with minor adjustments? If yes, SaaS.
Question two — what is the integration depth required? SaaS works well when the integration footprint is two to three systems with maintained connectors. SaaS struggles when the integration depth exceeds five systems, requires custom transformation logic, or depends on internal data sources that have no public API. Integration depth is where most custom decisions are actually justified — not the application logic, but the data flow surrounding it.
Question three — what is the team's capacity to maintain custom software over five years? Custom software has a real fully-loaded maintenance cost — typically twenty to thirty-five percent of the original build cost annually. The business needs the engineering capacity (in-house or contracted) to operate it, or the application becomes brittle within eighteen months.
Question four — what is the exit posture if the decision turns out wrong? SaaS has documented export paths. Custom software the business owns can be rebuilt or extended. Custom software the business outsources to an agency without the source code or operational documentation is the worst possible position — the lock-in is structural and the exit cost is the full rebuild.
Across the engagements where I have advised on this decision, the right answer was usually SaaS for the standard workflows and custom for the genuine differentiation. The framework above produced the answer; the feature comparison rarely did.
If your team is arguing custom because "SaaS is limiting," the conversation is in the wrong frame. The right frame is differentiation, integration depth, maintenance capacity, and exit posture.
