Why Social Security Organizations Should Resist the Do-It-Yourself Tech Temptation

1. Introduction

Public social security institutions increasingly face pressure to modernize their information systems while controlling costs, improving service delivery, and maintaining compliance with evolving legal frameworks. In this context, some organizations consider developing enterprise software internally, often motivated by dissatisfaction with past vendors, perceived loss of control, or the belief that in-house development will be cheaper and better aligned with institutional needs.  However, extensive academic research in software engineering, information systems, and public administration suggests that large-scale, mission-critical enterprise systems are among the most difficult and risky categories of IT projects, particularly when developed in-house by organizations whose core competencies lie outside software engineering. Over time, internal development efforts frequently result in costs that equal or exceed commercial alternatives, while exposing institutions to substantially higher operational, technical, and governance risks.  This essay argues that the decision to build enterprise social security systems internally reflects a systematic underestimation of total cost of ownership, institutional risk, architectural complexity, and long-term adaptability requirements.

2. Total Cost of Ownership and the Economics of Enterprise Software

The concept of Total Cost of Ownership (TCO) is well established in the academic literature on information systems economics. TCO extends beyond initial development costs to include maintenance, infrastructure, personnel, upgrades, compliance adaptation, and eventual system replacement.  Boehm (1981) and Boehm et al. (2000) demonstrated that software maintenance and evolution typically account for 60–80% of total lifecycle costs, a finding repeatedly validated in later studies of large information systems. Organizations that focus primarily on development budgets therefore systematically underestimate the real financial burden of ownership.

In the public sector, this problem is amplified. Heeks (2006) shows that government IT projects frequently suffer from optimism bias, where initial cost estimates fail to account for institutional constraints, procurement rigidities, and long-term maintenance obligations. As systems age, costs rise sharply due to accumulated technical debt and growing dependency on legacy architectures.

Importantly, comparative studies of build-versus-buy decisions in large organizations find no consistent evidence that in-house development produces lower long-term costs once full lifecycle expenditures are included (Rostami et al., 2017). Instead, costs tend to converge, while internally developed systems carry higher variance and downside risk.

3. Enterprise Software Design as a Specialized Institutional Capability

A central misconception underlying many DIY initiatives is the assumption that enterprise systems are primarily a programming challenge. Academic software engineering research makes clear that coding is the least complex part of enterprise system development.

Brooks’ seminal work The Mythical Man-Month (1975) established that software complexity grows nonlinearly with system size and organizational interfaces. The same is still true today, despite all the tools available to programmers nowadays and automation with AI tools which, at first sight, seem to speed up development significantly. The basic reality doesn’t change: modern enterprise systems must support:

• Configurable business rules
• Workflow orchestration
• Auditability and traceability
• Fine-grained access control
• Performance at scale
• Backward compatibility
• Regulatory adaptability
• Interoperability across institutional boundaries
• Cybersecurity

Developers can only implement what is specified. Designing specifications that remain valid over decades, across changing laws, demographics, and technologies, requires deep architectural expertise and accumulated institutional knowledge that most public agencies do not possess internally.

Empirical studies of large-scale systems development confirm that organizations lacking mature architectural capabilities experience higher rework rates, increased defect density, and premature system obsolescence (Boehm et al., 2000; Sommerville, 2016).

User-Driven Wish-Lists, Path Dependency, and the Absence of Best-Practice Discipline

One of the most pervasive and least acknowledged risks of internally developed enterprise applications is that system requirements are often driven by user wish-lists reflecting existing practices, rather than by evidence-based process design grounded in international best practices, accounting standards, or long-term system sustainability.

Requirements Capture as Institutional Reproduction

The academic literature on requirements engineering consistently shows that users tend to articulate needs in terms of current workflows and pain points, rather than abstract functional objectives or future-oriented system capabilities (Sommerville, 2016). In public administrations, this tendency is amplified by institutional inertia and path dependency: existing procedures, forms, and reporting practices become implicitly treated as “requirements” rather than as design constraints to be challenged.

Heeks (2006) describes this phenomenon as the automation of dysfunction, whereby information systems faithfully reproduce inefficient or outdated organizational processes instead of transforming them. When internal developers rely primarily on user input, the resulting system often encodes historical compromises, manual workarounds, and legacy accounting practices directly into software logic.

This is particularly problematic in social security institutions, where legacy procedures may predate:
• modern accrual accounting standards,
• integrated contribution–benefit reconciliation models,
• automated compliance and audit mechanisms,
• or high-volume digital transaction processing.

As a result, internally developed systems frequently optimize for familiarity rather than correctness, reinforcing existing inefficiencies at scale.

The Structural Inability of In-House Teams to Say “No”

A critical but under-examined difference between internal development teams and external enterprise software vendors lies in governance asymmetry.  In-house developers are embedded within the organizational hierarchy. They often report, directly or indirectly, to the same managers and business units that generate requirements. Academic studies of internal IT departments show that this proximity creates strong incentives to accommodate user requests, even when those requests conflict with best practices, architectural principles, or long-term sustainability (Keen, 1991; Heeks, 2006).

By contrast, experienced enterprise software vendors possess:
• contractual independence,
• external accountability,
• and reputational incentives tied to long-term system performance across multiple clients.

This structural independence enables vendors to reject or constrain feature requests that violate accounting standards, undermine data integrity, or introduce scalability and performance risks.  Internal teams, however, often lack both the institutional authority and political insulation required to say no — especially when requests come from senior operational staff or influential departments.  Saying “no” is difficult and does not make you popular in an organization, even if it is for the good of the project and the organization.  Projects that do not have strong leaders who can say “no” to higher management, are bound to experience feature creep and get pulled in all directions by different users’ wish-lists that may make a single user’s work easier but directly affect many other users’ work in a negative way.  The decision on features and priorities will be more driven by the perceived influence and power of different user departments in the organization rather than pure technical and objective priorities.

Feature Creep, Architectural Degradation, and Performance Risk

The consequences of unchecked user-driven requirements are well documented in software engineering research. Feature creep — the incremental accumulation of narrowly scoped, user-specific functionalities — is a leading cause of architectural erosion in large systems (Brooks, 1975; Sommerville, 2016).
In enterprise social security systems, this manifests as:
• excessive customization of business rules,
• duplicated logic across modules,
• special-case exceptions hard-coded into workflows,
• reporting logic embedded in transactional layers.

These design choices may satisfy short-term user expectations but often have severe long-term consequences:
• degraded system performance,
• increased maintenance complexity,
• reduced scalability under high transaction volumes,
• and diminished ability to adapt to future legislative changes.

Once embedded, such features are extremely costly to remove because they become operational dependencies. Rostami et al. (2017) note that internally developed large-scale systems frequently accumulate technical debt precisely because early design decisions were made to appease immediate stakeholders rather than to preserve architectural integrity.

Conflicts with Accounting Standards and Regulatory Best Practices

Another critical dimension concerns financial integrity and compliance. Social security systems intersect directly with public-sector accounting standards, actuarial principles, and audit requirements. Users, however, are rarely experts in these domains.

Research in public financial management shows that operational staff often prioritize local reporting convenience over standardized accounting treatment, leading to requests that:
• blur distinctions between cash and accrual concepts,
• compromise audit trails,
• or undermine reconciliation between contributions, liabilities, and payments (OECD, 2016).

Internal developers, lacking both deep accounting expertise and the authority to challenge users, may implement such requests despite their long-term risks. External vendors, by contrast, tend to enforce standardized data models and accounting structures precisely because their systems must satisfy auditors and regulators across jurisdictions.

Loss of Exposure to International Best Practices

Perhaps most importantly, user-driven internal development isolates organizations from international learning effects.
Enterprise software vendors accumulate knowledge across dozens of implementations, legal regimes, and operational models. This exposure enables them to embed:
• proven compliance workflows,
• optimized contribution collection mechanisms,
• scalable benefit calculation engines,
• and fraud detection patterns derived from comparative experience.

Internal teams, by definition, operate within a single institutional context. Without external benchmarking, systems risk becoming locally optimized but globally suboptimal, missing opportunities to adopt more efficient or robust practices already validated elsewhere (Hanseth & Lyytinen, 2010).

Implications for Long-Term System Viability

The cumulative effect of user-driven wish-lists, weak refusal mechanisms, and limited exposure to best practices is the gradual transformation of enterprise systems into rigid, fragile artifacts that are expensive to maintain and difficult to reform.
Heeks (2006) emphasizes that many public-sector IT failures are not dramatic collapses but slow degradations, where systems technically function yet progressively undermine policy objectives through inflexibility, opacity, and rising operational cost.

Why This Risk Is Systemic, Not Accidental

Crucially, this problem is not the result of poor intentions or inadequate skills. It is structural:
• Users are experts in current operations, not in future system design.
• Internal developers are accountable to users, not independent from them.
• Enterprise best practices emerge from cross-institutional learning, not isolated development.
Without deliberate counterweights — which are rare in in-house initiatives — internal development almost inevitably privileges short-term satisfaction over long-term institutional resilience.

4. Post–Go-Live Risk: Law, Scale, and Technological Change

A recurring pattern in public-sector IT is that early success masks long-term fragility.

4.1 Legal and Policy Change

Social security systems are inherently policy-driven. Legislative amendments require rapid, precise changes to benefit formulas, eligibility rules, contribution ceilings, and new data exchange and reporting obligations. Systems not designed around configurable policy engines become brittle, forcing costly code changes and increasing the risk of errors (Heeks, 2006). When the prime minister’s office calls and wants to know how fast a new benefit can be configured and paid to 1 million beneficiaries, the IT director shouldn’t have to go look for the developer who recently resigned and was the only one who knew how that particular benefit configuration can be modified.

4.2 Scalability and Performance

Database and architectural decisions made early in a project can severely constrain future scalability. Studies of large transactional systems show that retrofitting scalability is significantly more expensive than designing for it from the outset (Sommerville, 2016). Once production volumes increase, architectural limitations become existential threats rather than technical inconveniences. The initial go-live period of a home-developed system usually is riddled with bug-fixes still and due to a smaller database and transactions, the system itself, apart from the bugs, may be functioning fine. The real test occurs as volumes grow, users increase and suddenly performance issues are appearing which the inhouse developers have never faced before.  Unless experienced system architects were involved during the original design of the applications, such scalability issues can cause major disruption.

4.3 Technological Evolution

Programming languages, browsers, operating systems, databases, and security standards evolve continuously. Legacy lock-in is one of the most documented failure modes of public-sector IT systems (OECD, 2016). Organizations that build internally often lack the capacity for continuous refactoring and modernization, leading to escalating costs or forced system replacement. Since all costs are borne by the organization, in other words, there are no other clients for the same system who will help cover the costs of upgrades and potential rewrites due to technology changes, the cost of development is on-going, never-ending and often unpredictable. Far more than the typical 10% to 20% maintenance fees charged by commercial software providers.

5. Security, Data Protection, and Institutional Risk

Security is not a feature; it is an ongoing process. Social security systems manage some of the most sensitive data held by the state. Academic research shows that security failures are strongly correlated with organizational capability rather than intent.

Anderson (2020) emphasizes that secure system design requires sustained investment in threat modeling, testing, monitoring, and governance. Public institutions rarely maintain the depth of specialized expertise required to manage this continuously. Again, it is difficult for a social security administration to hire and retain experts in all fields of software engineering as well as security, which is a discipline in itself. Securing the network and infrastructure in existence is a major challenge on its own, there is really no room for adding in additional potential points of failure with internally developed software for mission critical applications.

Moreover, regulatory frameworks such as GDPR and comparable national laws impose strict obligations regarding data minimization, auditability, breach notification, and access control. Failure to meet these standards exposes institutions to legal liability, reputational damage, and operational disruption (OECD, 2019).

6. Integration as a Structural, Not Technical, Challenge

Modern social security systems operate within dense institutional ecosystems: tax authorities, banks, healthcare providers, civil registries, and digital identity platforms. Integration is therefore not merely technical but organizational and legal.
Research on inter-organizational information systems shows that integration complexity increases exponentially with the number of stakeholders involved (Hanseth & Lyytinen, 2010). Systems that are not explicitly designed for interoperability tend to become siloed, undermining policy coherence and administrative efficiency. The design for this, again requires experts in API development, not for a small website, but for enterprise applications, and those APIs need to be designed for both performance as well as security.

Vendor platforms benefit from accumulated integration experience across jurisdictions, while internal teams face a steep learning curve with each new interface. In other words, the right vendors will have the experience and have learned the lessons over time with countless customers using their applications in high-transaction-volume environments, whereas inhouse development teams will by definition be restricted to what they experience on the job.

7. Opportunity Costs and Institutional Focus

Finally, internal software development imposes significant opportunity costs. Public organizations have finite managerial attention, budgetary flexibility, and political capital. Diverting these resources toward managing software engineering risk reduces capacity to focus on core mandates: compliance enforcement, benefit adequacy, service accessibility, and policy innovation.

Heeks (2006) notes that many public IT failures stem not from technical incompetence but from institutional overstretch — organizations attempting to do too much outside their comparative advantage.

8. What Social Security IT Teams Should Focus on Instead:

Strategic Institutional Capabilities Beyond Core System Development

If the academic and empirical literature suggests that social security organizations are poorly positioned to build and sustain large-scale enterprise software internally, the next question is constructive rather than critical: what should internal IT teams focus on instead? Research in public-sector information systems increasingly emphasizes that the most effective government IT units are those that act as institutional enablers rather than product developers. Their value lies not in writing core application code, but in orchestrating organizational change, safeguarding operational continuity, ensuring security and compliance, and leveraging data and digital tools to enhance service delivery (Heeks, 2006; OECD, 2016).

8.1 Prior to and During the Implementation: Building Organizational Readiness

Change management

One of the most consistent findings in public-sector IT research is that organizational failure, not technical failure, is a dominant cause of unsuccessful system implementations. Kotter’s (1996) change management framework emphasizes that large transformations fail when institutions underestimate user resistance, cultural inertia, and the operational anxiety induced by major changes. Heeks (2006) similarly emphasizes “design–reality gaps” as a core explanation for failure in e-government initiatives.

In practical terms, internal social security IT teams add the most value when they lead or co-lead: stakeholder mapping, communications planning, training coordination, adoption measurement, and the day-to-day “translation” work between operational departments and the vendor’s project team. This reduces the likelihood that the implementation becomes a purely technical exercise divorced from institutional reality.

Data cleansing and migration readiness

Data quality is one of the most underappreciated risks in enterprise implementations. Strong, Lee, and Wang (1997) show that data quality must be understood “in context,” because operational success depends not only on the correctness of data but also on how users interpret, trust, and consume it. For social security organizations, legacy data often contains duplicates, inconsistent identifiers, contribution gaps, and undocumented exceptions.

Vendors can provide tooling and methods, but internal IT teams should own data governance and readiness activities: designing validation rules, reconciling records with authoritative registries, creating migration acceptance tests, and coordinating with business owners to validate edge cases and exceptions that are unique to the institution’s history.

Requirements definition and governance

Internal teams should not try to “design the product” feature-by-feature. Instead, the highest-value internal role is to define principles, constraints, and non-functional requirements: security and access governance, auditability needs, performance expectations, integration constraints, data retention rules, and legal requirements. This approach aligns with requirements engineering best practice, which distinguishes between capturing what users say they want and defining what the system must reliably achieve under real conditions (Sommerville, 2016).

In addition, internal teams can help ensure that requirements discussions remain disciplined and do not devolve into wish-lists or locally optimized demands that undermine best practices, architectural integrity, or regulatory compliance (Heeks, 2006; Keen, 1991).

8.2 After Implementation: Sustaining the Institutional Ecosystem

Internal user support and knowledge mediation

Research on enterprise system outcomes consistently highlights that benefits depend heavily on sustained post-implementation support, process stabilization, and organizational learning (Markus, Tanis, & van Fenema, 2000). Social security IT teams should build strong first- and second-line support, maintain internal knowledge bases and training materials, and act as an escalation and triage layer so that operational noise does not overwhelm vendor change pipelines.

Security, networking, and operational resilience

Security is an ongoing process requiring institutional governance and operational controls, not just technical features (Anderson, 2020; OECD, 2019). Internal teams should prioritize identity and access management practices, segregation of duties, endpoint controls, security awareness programs, and incident response playbooks in coordination with national cybersecurity entities where applicable.

Equally important is resilient networking and infrastructure monitoring, because many service interruptions originate in connectivity, configuration, or operational failures rather than core software defects. Internal teams should maintain redundancy plans, performance monitoring, and service oversight practices aligned with public-sector digital government strategy principles (OECD, 2016; OECD, 2020).

Contingency planning, business continuity, and disaster recovery

Social security operations are mission-critical. Interruptions in contribution processing or benefit payments can rapidly become social and political crises. Herbane (2010) shows that crisis readiness and continuity capacity are organizational capabilities requiring planning, governance, and routine testing—not merely documentation. Internal IT teams should lead or co-lead continuity planning, disaster recovery exercises, manual fallback procedures, and restoration protocols so that institutional service obligations can be maintained even when systems fail or external dependencies break.

8.3 Innovation at the Edges: Add-Ons, Internal Tools, Data Warehousing, and Mobile Channels

Developing add-ons and internal productivity tools

Internal teams often can and should develop extensions that do not destabilize the core system: reconciliation utilities, internal dashboards, document management helpers, and automation scripts. This is most sustainable when done through loosely coupled designs—an established lesson in information infrastructure research (Hanseth & Lyytinen, 2010). The objective is to increase internal productivity without creating unmanageable customizations inside the core application.

Data warehousing and analytics

A mature social security institution increasingly relies on data warehousing and analytics to improve compliance targeting, fraud detection, forecasting, and evidence-based policy support. Internal teams should own data governance, reporting definitions, warehouse pipelines, and analytical enablement, coordinating closely with actuarial and policy units (OECD, 2016).

Mobile apps and digital access channels

Citizen-facing channels evolve rapidly, and inclusion increasingly depends on accessible digital services. The United Nations E-Government Survey emphasizes the role of digital government in inclusive service delivery and the importance of multi-channel access, including mobile (United Nations, 2020). Internal IT teams can add value by designing channel strategies, prototyping citizen experiences, integrating vendor APIs, and continuously improving usability without destabilizing the core transaction engine.

9. Conclusion

The academic literature across software engineering, public administration, and information systems converges on a clear conclusion: building and sustaining large-scale enterprise software is a highly specialized activity with structural risks that public social security institutions are poorly positioned to absorb.

In-house development does not reliably reduce costs over the system lifecycle and often increases exposure to security, scalability, and governance failures. By contrast, specialized vendors amortize development costs across clients, maintain dedicated architectural expertise, and evolve systems continuously in response to legal and technological change.

For social security organizations, the strategic imperative is therefore not technological self-reliance, but institutional resilience — achieved through focusing on core public functions while partnering with entities whose core competence is enterprise software design and evolution.

References

Anderson, R. (2020). Security engineering: A guide to building dependable distributed systems (3rd ed.). Wiley.

Boehm, B. W. (1981). Software engineering economics. Prentice Hall.

Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D., & Steece, B. (2000). Software cost estimation with COCOMO II. Prentice Hall.

Brooks, F. P. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley.

Hanseth, O., & Lyytinen, K. (2010). Design theory for dynamic complexity in information infrastructures: The case of building Internet. Journal of Information Technology, 25(1), 1–19.

Heeks, R. (2006). Implementing and managing eGovernment: An international text. SAGE Publications.

Herbane, B. (2010). Small business research: Time for a crisis-based view. International Small Business Journal, 28(1), 43–64.

Keen, P. G. W. (1991). Shaping the future: Business design through information technology. Harvard Business School Press.

Kotter, J. P. (1996). Leading change. Harvard Business School Press.

Markus, M. L., Tanis, C., & van Fenema, P. C. (2000). Multisite ERP implementations. Communications of the ACM, 43(4), 42–46.

OECD. (2016). Digital government strategies for transforming public services in the welfare areas. OECD Publishing.

OECD. (2019). Digital security risk management for economic and social prosperity. OECD Publishing.

OECD. (2020). The OECD digital government policy framework. OECD Publishing.

Office of the Inspector General. (2022). The Social Security Administration’s challenges and successes in obtaining data to determine eligibility and payment amounts (A-01-21-51029). Social Security Administration.

Rostami, A., Sommerville, I., & Hammond, J. (2017). Build software or buy? A study on developing large-scale software. Journal of Systems and Software, 132, 191–208.

Sommerville, I. (2016). Software engineering (10th ed.). Pearson.

Strong, D. M., Lee, Y. W., & Wang, R. Y. (1997). Data quality in context. Communications of the ACM, 40(5), 103–110.

United Nations. (2020). United Nations e-government survey 2020: Digital government in the decade of action for sustainable development (with addendum on COVID-19 response). United Nations Department of Economic and Social Affairs.