Technological Decisions At Intersection Of Markets: What Changes If Your Clients Have Different Standards

The global software outsourcing market keeps expanding. Grand View Research reports it reached $744.6 billion in 2024 and is projected to hit $1.22 trillion by 2030. Main growth drivers come from highly regulated sectors like healthcare, finance and critical infrastructure. In these areas, regulatory frameworks, data sovereignty laws, and liability structures vary sharply by country. Every company operating in these sectors should mind one hidden pitfall: engineering decisions that are commercially neutral in one market may carry serious legal and financial consequences in another.

Among the professionals recognised for addressing this challenge is Oleksandr Orlov, Co-Founder and Chief Technology Officer of Andersen. His work has influenced how international organisations approach software architecture, compliance integration, and large-scale technology delivery.

Over the past fifteen years, Oleksandr has led the development of engineering frameworks that enable companies to transition from regional operations to highly regulated global markets. His methodologies are now applied across the healthcare, finance, and enterprise technology sectors. They help organisations adapt to complex regulatory environments while maintaining technical scalability and operational efficiency.

Before founding Andersen in 2011, Orlov directed engineering at MyBit BV in the Netherlands, managed project delivery at Possoftware in Ukraine, and operated his own development business. This sustained career arc gave him a direct view of how workflows change when a software organisation crosses borders. The clients his teams now serve: S&P Global, Capital Farm Credit, JPMorgan Chase & Co. operate under strict compliance regimes that have no direct equivalent in the markets where Andersen started.

What Role Does Compliance Play In Architecture?

Oleksandr’s most consequential insight for cross-market expansion is also the least intuitive. The regulatory environment of a target market is an architectural input. It isn’t a late-stage checklist. Teams that discover this late pay for it twice: once to build the system and once to rebuild it.

The U.S. healthcare market makes this concrete. Security breaches in this sector carry massive financial risks.

IBM’s 2024 Cost of a Data Breach Report placed the average cost of a healthcare incident at $7.4M, which is $1.86 million more than in financial services, the second-most expensive sector.

The Impact Of HIPAA And ISO 27001

This cost gap reflects the specific liability structure of HIPAA. The law does not prescribe specific technologies. Instead, it requires documented risk analysis, enforceable access controls, encrypted data flows, and defined incident response procedures.

Business associate breaches originate in third-party vendors rather than the primary healthcare provider. These breaches increased by 337% between 2018 and 2024. Consider a European software company developing a clinical platform for American clients. Under U.S. law, they become a “business associate” the moment protected health information flows through their systems. The compliance obligation travels with the data.

ISO 27001 and HIPAA overlap in several areas:

• Access controls
• Audit logging
• Incident response
• Risk management

ISO 27001 doesn’t replace HIPAA compliance. However, achieving it forces the organisational transformation that HIPAA demands. This includes documented policies, tested procedures, defined escalation paths, and third-party-audited controls. For a non-American company, it also functions as market entry evidence. Enterprise contracts and vendor assessments usually expect ISO 27001 certification. Today, many U.S. enterprises and government entities require it as a strict prerequisite for doing business.

Andersen’s Operational Shift

When Andersen entered the U.S. healthcare delivery market, Oleksandr Orlov spent two years transforming the company’s internal operations before writing any code for American medical clients. In-house decision chains were restructured. Data governance policies were formalised. Incident response procedures were tested against real-world scenarios. The company pursued and achieved ISO/IEC 27001 certification.

“Compliance dictates the architecture,” Oleksandr observes. “You must adapt your entire organisational structure, from physical hardware security to the access protocols your development team uses. You need this before you have the right to work with this kind of data.”

The two-year investment preceded their engagement with ProScan Imaging.

The company runs one of the largest privately held teleradiology networks in the United States. The software relied on a microservice and event-driven architecture. From the initial specification stage, every data flow that carried protected health information was intended to be encrypted. This preparation absorbed upfront costs. Otherwise, these costs would have surfaced later as mid-project architectural pivots. Those are the exact pivots that extend enterprise healthcare projects by months.

Vendor Independence As a Major Principle

Parallels’ 2026 State of Cloud Computing Survey highlights a massive trend. Fully 94% of organisations report concerns about vendor lock-in. Nearly half describe themselves as “very concerned.” When a platform scales, proprietary dependencies accumulate. They often surface as structural constraints at the worst possible moment: during contract renegotiations, market expansion or regulatory audits.

In those moments, a proprietary architecture cannot guarantee the required data sovereignty.

Cross-market expansion amplifies this risk. A platform that functions acceptably in one regulatory environment can create severe operational and contractual constraints in another. This situation is common in regulated U.S. markets.

Standard procurement requirements often include platform portability provisions and data sovereignty clauses. Proprietary architectures may fail to satisfy these rules.

Oleksandr Orlov saw the consequences of vendor lock-in firsthand during an engagement with a U.S. healthcare provider. The client’s previous vendor had embedded proprietary data formats, runtime dependencies, and interface protocols throughout the platform. The vendor then used these dependencies as leverage during contract renegotiations. The client had no practical exit.

Orlov’s team removed the lock-in through a systematic overhaul:

1. Ported data to open formats
2. Replaced proprietary interfaces with documented standards
3. Rebuilt the components tied to the vendor’s specific runtime

The process was technically straightforward but organisationally difficult. They executed the migration in a live clinical environment on a system the client depended on daily. All of this happened while a commercial dispute with the incumbent vendor ran in parallel.

The experience led Oleksandr to formulate a vendor-neutral architecture methodology. This framework later became the governing engineering principle across Andersen’s international engagements: open standards, documented interfaces, portable data formats and zero proprietary runtime dependencies in client-facing systems.

“A client who can leave but chooses to stay is a more stable relationship than one who can’t leave,” Oleksands notes. For CTOs delivering into regulated American markets, this is a core engineering specification.

Building Scale Through Consistent Delivery

Technical decisions at market boundaries require organisational infrastructure to execute without glitches. Consistency is impossible if quality depends entirely on which individuals work on a project. Companies must deliver reliably across markets, time zones, and client expectations.

Oleksandr Orlov built Andersen’s response to this problem over several years. His strategy grew from direct experience with its consequences. Managing twenty engineers simultaneously across multiple client engagements, he found the span of control unsustainable.

The solution was structural. Oleksandr introduced vertical management layers with defined authority and escalation paths. He combined these with horizontal alignment frameworks, goal matrices, performance criteria, and individual development tracks that gave engineers in different geographies a common standard to work toward.

From that foundation, he built PDS Competency Centres. These internal units own delivery standards for specific domains:

• Fixed-Price Delivery Centre: formalises how engagements are scoped, estimated, and certified at each milestone
• AI-Augmented Delivery Centre: embeds AI tooling into the fixed-price framework as an operational capability with its own standards and assessment criteria
• AWS Centre: sets cloud infrastructure baselines

“Andersen is a field of experiments and proficiencies,” Orlov notes. Each centre ensures the organisation sets the quality floor, not the specific staff assigned to a project.

Data support the operational logic:

• Forrester (2024): Businesses adopting structured outsourcing frameworks reduce operational costs by up to 40%. They also improve service delivery speed by 30%
• McKinsey: Research on AI adoption in software engineering points to 20–45% productivity gains when AI tooling is integrated

Orlov pushed AI consulting into Andersen’s service portfolio before market demand materialised. He built an internal unit to adapt existing tools to specific project contexts. When market demand arrived, the organisation was already prepared to meet it.

What Cross-Market Experience Can Teach

The practical lesson Orlov draws from fifteen years of cross-market delivery goes beyond any specific technology or regulatory regime. It is about sequencing.

Too many organisations consider market entry a business development problem. They identify the client, build the relationship, and defer technical constraints. Consequently, they discover those constraints at the worst possible moment. It happens mid-project, under tight timelines, and after making irreversible architectural choices.

On the other hand, successful businesses treat market entry as an engineering preparation problem. They seek to understand the regulatory environment and build internal compliance infrastructure. They also validate technology choices against target market maintainability criteria. As a result, regulatory and delivery constraints reinforce each other positively.

Beyond individual projects, Orlov’s work reflects broader trends in enterprise technology management. His focus on compliance-first architecture, organisational scalability and infrastructure portability foresaw challenges that are now top of mind for global enterprises. As more organisations operate under multiple regulatory jurisdictions, the principles he established years ago have become important considerations for software leaders worldwide.

“Entrepreneurship is not freedom,” Orlov observes. “But it is quite an interesting game.” The game, at the intersection of markets, is understanding which rules apply before the first move is made.