Modular Procurement Without Vendor Lock-In

Executive brief

Modular modernization only works if procurement changes with it. Agencies need a way to buy interoperable capabilities without recreating monolithic lock-in one module at a time.

The way government buys software shapes the software it receives.

In unemployment insurance, that point matters because many modernization procurements still assume that a state must buy one large system from one primary vendor. The resulting project may include benefits, tax, appeals, portals, correspondence, identity, payments, reporting, employer workflows, staff tools, security, integrations, and data conversion. Because everything must work together, the procurement becomes large, slow, expensive, and hard to change.

This all-or-nothing model creates familiar risks. Requirements are difficult to define up front. Vendors must price uncertainty. Agencies must evaluate broad claims across many domains. Implementation schedules stretch. Policy changes continue during the project. By the time the new system launches, the state may have replaced one dependency with another.

Modular modernization is meant to reduce that risk. Instead of buying one indivisible system, a state should be able to adopt a specific capability, validate it, operate it, and replace or expand it later. That is the right direction. But modular procurement has to be designed carefully.

A module is not truly modular just because it is smaller than a full system. A module can still lock a state in if it depends on private interfaces, undocumented data assumptions, custom integrations, vendor-controlled testing, or contract terms that make replacement impractical.

The procurement test is simple: can the state buy this capability without giving up future options?

If the state cannot replace the capability later, the procurement is not truly modular. If another provider cannot implement the same boundary, the interface is not truly open. If acceptance depends on subjective demonstrations rather than objective evidence, compatibility is not truly governable. If the state cannot see how data, audit records, configuration, and operational handoffs work, public control is incomplete.

A better model starts with defined capability boundaries.

For each capability, agencies should know what the capability is responsible for, what it consumes from other capabilities, what it provides to other capabilities, what events or status changes it exposes, what evidence it preserves, what configuration belongs to the state, and what operational handoffs must occur.

That boundary becomes the basis for procurement. Vendors can compete on implementation quality, cost, service, usability, performance, security, and operational fit while still meeting the same baseline expectations. A state can compare options more fairly because the expected behavior is clearer.

Conformance evidence should be part of procurement from the beginning. Agencies should ask providers to show test results, interface behavior, data handling, accessibility support, security controls, audit logging, monitoring, incident response, and operational documentation. Evidence reduces guesswork and makes reuse possible across states.

A governed marketplace or store model can make this easier. The value of a marketplace is not just listing products. It is organizing the conditions under which products can be trusted, compared, and adopted. A useful marketplace helps agencies understand capability boundaries, dependencies, readiness evidence, implementation requirements, support models, and procurement pathways.

This does not eliminate state procurement authority. It strengthens it. State procurement teams still decide what they need, what contract path is appropriate, what legal requirements apply, what security review is required, and what vendor relationship is acceptable. The difference is that they are no longer forced to define every technical boundary from scratch.

Modular procurement can also expand the vendor ecosystem. Many companies can build excellent identity workflows, document services, correspondence tools, analytics, customer experience layers, or staff workflow capabilities. Far fewer can compete credibly for a complete UI replacement. If the only meaningful procurement is the large replacement procurement, competition stays narrow.

Open-source and state-developed capabilities also benefit from this model. A state-built module or open-source component becomes more reusable when it implements a known boundary, includes documentation, and can be validated through conformance evidence. Without those supports, reuse often depends on heroic custom integration.

Procurement should also preserve state policy control. UI law varies by state, and modernization cannot erase that. A modular capability should distinguish between common infrastructure and state-specific policy, rules, notices, workflows, and operational choices. A provider should not gain control of state policy simply because it controls the software boundary.

For agencies, practical procurement questions include:

• What capability are we buying?
• What boundary does it own?
• What systems or workflows does it depend on?
• What conformance evidence exists?
• How will we migrate data in and out?
• How will we operate, monitor, and support it?
• What happens if we replace it later?
• Does this procurement reduce future risk or create a new dependency?

Those questions should be asked before the procurement is released, not after implementation begins.

Modular procurement is not just smaller purchasing. It is a different modernization discipline. It rewards interoperability, evidence, portability, and operational fit. It gives states more paths to improve. It lets vendors compete where they are strongest. It makes public investment more reusable.

The future of UI modernization should not depend on repeating large replacement projects every decade. It should depend on a marketplace of governed, tested, replaceable capabilities that states can adopt responsibly.