Owning the code is not owning the capability

A custom case-management system often starts with a sensible sentence: our process is different, so our software should be different too. A small team builds the first version, operators finally get screens that resemble their workflow, and the company stops paying someone else's licence fee. For a while, ownership feels like control.

Then the system becomes the business. It holds applicant records, document decisions, payments, communications, government references, service deadlines, and the unofficial workarounds that experienced operators have learned to depend on. The team that built it moves on. Changes get slower. Exceptions move into spreadsheets. The software is still owned by the company, but the capability to change it safely has begun to disappear.

That is the real technology risk in visa operations. In-house software is not inherently expensive or poor quality. It becomes both when owning code is mistaken for owning the full capability required to operate it.

What we can learn from the outside

We reviewed the public product pages and documented applicant journeys of six established visa-service providers across corporate mobility, consumer travel, and government outsourcing. We looked for the basic shape of each service: requirements discovery, application intake, document handling, appointment booking, payments, status tracking, notifications, and escalation to a person. We did not open paid cases or submit personal information. This was a limited outside-in review, not a usability test or an audit of private systems.

The first finding was sameness. Nearly every provider now promises some combination of online applications, document guidance, status updates, and expert review. Those features have become the category baseline. A form, a document uploader, and a tracking page no longer prove that a company has unusual technology.

The second finding was fragmentation. Public journeys regularly crossed boundaries between an operator, a government service, an appointment provider, a payment service, and an offline centre. Applicants could be asked to carry a reference from one system into another. A tracking surface might describe the operator's part of the journey without exposing what was happening inside a consular process. An exception that began online could still end in email or a call centre.

None of this proves bad engineering. Governments set many of these boundaries, and public screens do not reveal whether a provider built, bought, acquired, or outsourced the systems behind them. That limitation matters. It would be irresponsible to look at a frustrating journey and declare that an internal development team caused it.

The first build is the smallest commitment

Software budgets encourage companies to think in projects. There is a start date, a feature list, a delivery partner, and a launch. The financial case usually compares that visible build cost with several years of subscription fees. It rarely prices the organization that must exist after launch.

That organization needs product ownership, user research, software engineering, testing, security, operations, support, accessibility, data governance, and domain expertise. It needs somebody accountable for service quality, not merely somebody who can approve a change request. It also needs enough continuity that a staff departure does not turn an undocumented rule or integration into a critical dependency.

The exact cost varies too much for a universal build-versus-buy formula. A useful warning comes from a very different sector: the US Government Accountability Office's 2025 review of critical legacy systems. Federal agencies reported spending about 80% of their IT expenditure on operating and maintaining existing systems. The same review found outdated technologies, unsupported components, known security vulnerabilities, rising costs, and shortages of people able to support critical software.

That 80% figure should not be copied into a visa company's business case. Government estates are different in scale, age, and procurement. The transferable lesson is simpler: maintenance is not a residual expense. Over a system's life, it can become the main work.

Visa operations make the ownership test harder

A visa platform is exposed to change from several directions at once. Immigration rules change. Government forms and portals change. Consular appointments move between providers. Payment requirements differ by market. Passports expire. Documents must be collected, checked, retained, and deleted under different legal and contractual obligations. A single case can cross digital and physical channels before it is complete.

The pace is not theoretical. In February 2026, the UK began enforcing digital permission to travel for visitors from 85 nationalities after processing more than 19 million ETA applications. The European Union is building a common online visa application platform, while ETIAS is due to begin operations in the last quarter of 2026. Each change creates new requirements, new applicant questions, and new failure paths for operators to absorb. The UK ETA rollout, the EU visa digitalisation regulation, and the official ETIAS timeline show a category that is still actively changing shape.

The data raises the standard further. Visa work can involve passport details, financial evidence, travel history, facial images, and fingerprints. The UK's Information Commissioner's Office confirms that biometric data used to identify a person receives special-category protection. Security therefore has to be part of the software lifecycle, not a review performed once before launch. The NIST Secure Software Development Framework treats preparation, protection, secure production, and vulnerability response as continuing organizational practices for exactly this reason.

A company that builds this software is choosing to maintain competence across all of those surfaces. Source-code ownership does not reduce the obligation. It concentrates it.

Poor software sends its invoice through operations

Technology debt in a visa business rarely appears as a clean line in the profit and loss statement. It arrives disguised as operational work.

• An operator retypes applicant data because two systems do not share a reliable record.
• A senior caseworker checks routine cases because rules cannot be changed safely without a release.
• A support team answers status questions because the portal cannot explain where responsibility currently sits.
• A new corporate client waits for onboarding because every integration is a custom project.
• An incident depends on the one contractor who still understands an old workflow.

Each workaround can look cheaper than replacing the underlying capability. Together they change the economics of the business. Skilled staff spend time reconciling systems instead of resolving difficult cases. Growth requires more coordination. A regulatory update becomes a delivery risk. Management may own every line of code while having little practical control over the speed or safety of change.

Research from Google's DevOps Research and Assessment program adds an important qualification. Strong software delivery predicts better organizational outcomes only when reliability is also high. When reliability is poor, faster delivery can have no benefit or even a negative effect. The point is not to release more often. It is to build the delivery and operational capability to change a live service without making it less dependable.

Build the difference, buy the burden

The alternative is not to outsource every technical decision. Visa companies have real differentiators worth protecting: their interpretation of complex cases, service promises, client relationships, operating playbooks, market coverage, and ways of handling exceptions. Software that expresses those advantages can deserve internal investment.

Commodity obligations are different. Authentication, audit trails, document infrastructure, role-based access, workflow state, notification delivery, integration monitoring, and routine security maintenance are necessary, but owning them does not automatically distinguish a visa company. Rebuilding them consumes the same people and budget that could be improving the parts customers actually choose.

This points to a hybrid strategy. Buy or adopt a durable platform for the shared burden. Configure the operating model around the company. Build only where the result creates a measurable advantage that cannot be reached through configuration or integration. Keep data portability and exit paths explicit so that buying a platform does not simply exchange internal dependency for vendor dependency.

Five questions before approving another internal build

1. Does this capability differentiate the service? If customers would not choose the company because of it, custom code needs a stronger justification.
2. Who owns the live product? Name the accountable team, not the project sponsor or delivery supplier.
3. Is the full lifecycle funded? Include security, support, accessibility, integrations, regulatory changes, incident response, and replacement.
4. Can quality be measured? Track applicant completion, manual rework, exception rates, change lead time, reliability, and recovery, not just whether the feature shipped.
5. Can the company leave? Internal and vendor systems both need documented data export, migration, and retirement plans.

An honest answer may still support building in-house. Large operators with enduring product teams, mature engineering practices, and genuinely distinct workflows can create excellent software. The mistake is assuming that ownership itself produces those capabilities.

---

The most expensive system is not necessarily the one with the highest invoice. It is the one the business cannot change safely and cannot stop using. Visa companies should own what makes them better. Everything else should earn its place against the full cost of keeping it good.