The In-House Build vs. The Commercial Platform A Risk Comparison
Published on: Sat Jun 01 2024 by Ivar Strand
The In-House Build vs. The Commercial Platform: A Risk Comparison
A recurring strategic question for organizations managing large-scale programs is whether to build a custom financial system in-house or buy a Commercial Off-The-Shelf (COTS) platform. There is no universally correct answer. The optimal choice depends on an organization’s specific context, capacity, and, most importantly, its appetite for different types of risk.
The decision is not a choice between a risky and a safe option. It is a choice between two fundamentally different risk profiles. Understanding this distinction is the foundation of making a sound strategic decision and designing an appropriate assurance framework.
The Risk Profile of Commercial Off-The-Shelf (COTS) Software
Procuring a COTS platform introduces risks that are primarily related to opacity and dependency. The user is acquiring a “black box,” whose internal logic is controlled by an external party.
- Logic and Assumption Risk: A COTS product comes with a pre-packaged set of assumptions about accounting standards and business processes. As we have discussed previously in this series, these embedded rules may not align with an organization’s unique operational or fiduciary requirements, creating a risk of a fundamental mismatch.
- Vendor Lock-in and Dependency: The organization becomes dependent on the vendor’s financial health, business priorities, and technical support. The vendor controls the timeline for critical security patches and future product development. If the vendor discontinues the product or is acquired, it can create a significant operational disruption.
- Configuration Risk: While modern COTS systems are highly configurable, this flexibility is itself a source of risk. The complexity of the available settings can make it difficult to determine the true state of the internal control environment. A critical control may be inadvertently disabled through an incorrect configuration choice.
The Risk Profile of In-House Developed Solutions
Building a system in-house shifts the risk profile from external dependency to internal capacity and discipline. The system is a “glass box”—its logic is theoretically transparent to the organization, but the quality of that logic is entirely dependent on the internal team’s capabilities.
- Lack of Development Discipline: Organizations whose core mission is not software development often lack a formalized Software Development Lifecycle (SDLC). This can result in inconsistent coding standards, inadequate testing, and poor documentation, making the system difficult to manage and prone to error.
- Key-Person Dependency: The system’s architecture and logic may be fully understood by only one or two internal developers. The departure of these individuals can leave the organization with a critical system that no one else has the knowledge to maintain, debug, or evolve.
- Technical Debt and Maintenance Burden: In-house projects may prioritize rapid delivery of initial features over long-term code quality, accumulating significant “technical debt.” Furthermore, the total lifecycle cost of securing, maintaining, and hosting a custom application is frequently underestimated.
Implications for Monitoring and Assurance
The choice to build or buy determines the focus of a robust monitoring strategy.
- For a COTS system, assurance must focus on interrogating the “black box.” This involves rigorous configuration audits, independent output validation, and a structured approach to vendor management.
- For an in-house system, assurance must focus on the development process itself. This requires enforcing a disciplined SDLC, mandating independent code reviews, and ensuring that documentation and testing are comprehensive.
Neither path provides an escape from the need for rigorous, independent verification. Whether managing the opacity of a vendor’s platform or the potential inconsistencies of a custom build, a structured monitoring framework is essential to ensure the system is fit for purpose and worthy of stakeholder trust.
