No reseller margin
We are remunerated for engineering and integration outcomes. We do not depend on licence or hardware resale margin, so specifying more product does not increase our revenue.
Why Vendor-Neutral Matters
Independence is an engineering requirement, not a marketing claim
When a single supplier owns the requirement, the product and the roadmap, the state has outsourced more than a system. It has outsourced a decision it can no longer revisit.
The problem
Lock-in rarely announces itself
Vendor lock-in is seldom the result of a bad decision. It is usually the accumulated result of many reasonable ones: a proprietary data format accepted to save three weeks; a matching algorithm embedded directly in an application rather than behind an interface; a licence model that made the pilot inexpensive and the national rollout unaffordable.
By the time the constraint is visible, the cost of removing it exceeds the cost of living with it — and that calculation is precisely what a supplier with a captive account depends on.
Our position is simple. The state should be able to change its mind about any component of its national infrastructure, at any time, at a proportionate cost. That is a property you have to engineer in from the beginning. It cannot be retrofitted.
Five ways lock-in enters a national programme
- Requirement capture. Specifications written around one product’s feature list.
- Data formats. Citizen records held in a structure only one vendor can read.
- Interfaces. Point-to-point integration instead of a standards-based layer.
- Commercial terms. Per-transaction licensing that scales with national adoption.
- Knowledge. No client engineer able to operate the system unaided.
Structural independence
What makes our neutrality real
Any integrator can claim neutrality. These are the structural conditions that make it verifiable — and they are conditions we accept in contract.
No exclusive alliances
We maintain technical relationships across each discipline and disclose every one of them. No agreement obliges us to lead with a particular platform.
Published evaluation criteria
Selection criteria and weightings are agreed with the client before vendors are assessed, and the completed matrix is handed over as a programme artefact.
Abstraction by design
Biometric engines, HSMs, databases and cloud platforms sit behind interfaces we define, so a component can be swapped without rewriting the system around it.
Client-owned artefacts
Architecture, data models, interface specifications, test suites and operational runbooks are delivered to the client as their property.
Contestable exit
Exit and transition provisions are drafted at contract signature, not at contract expiry. Including our own replacement.
The consequence
What neutrality changes for the client
| Dimension | Single-vendor national programme | Vendor-neutral integration |
|---|---|---|
| Technology quality | Best available within one portfolio — strong in some disciplines, weak in others. | Best available worldwide, per discipline, assessed against your requirement. |
| Pricing leverage | Erodes after award; renewals are negotiated from a position of dependency. | Retained for the life of the system; components remain competitively tendered. |
| Obsolescence | Governed by the vendor’s roadmap and end-of-life decisions. | Managed component by component, on the state’s timetable. |
| Data sovereignty | Citizen data held in proprietary structures; export is a project in itself. | Canonical, documented data model owned by the state from day one. |
| Audit & scrutiny | “Commercially confidential” frequently limits what can be disclosed. | Decision rationale and evaluation evidence are programme deliverables. |
| National capability | Operational knowledge resides with the supplier. | Knowledge transfer is a contracted deliverable with acceptance criteria. |
Signature Model
Independence, expressed as an architecture
This is the same model that governs every engagement. Note where technology selection sits: after the mission and after the requirements — never before them.
Fair questions
The objections buyers raise — answered
Isn’t a single vendor simpler to manage?
It is simpler to procure. It is not simpler to run, and it is considerably harder to leave. In a vendor-neutral programme the client still has one accountable counterparty — Qcuboyds — for design, integration and service. The difference is that the accountable counterparty has no financial interest in which product wins.
Doesn’t multi-vendor integration add risk?
Integration risk is real, and it is the risk we specialise in retiring: interface contracts defined early, reference implementations built before commitment, end-to-end test harnesses maintained for the life of the system, and formal FAT and SAT gates. The alternative risk — a monolithic dependency on one supplier’s continued goodwill, solvency and roadmap — is harder to mitigate because it cannot be engineered around after the fact.
If you don’t resell, how are you paid?
Through engineering, integration, programme delivery and support services. Licences and hardware are contracted directly between the client and the chosen suppliers wherever the client prefers, which keeps procurement transparent and keeps our advice uncontaminated by margin.
How do we know an evaluation was genuinely open?
Because you set the criteria with us before it starts, your staff sit on the evaluation panel, and you receive the completed matrix including the rejected options and the reasons for rejection. An evaluation you cannot inspect is not an evaluation.
What if we already have a single-vendor system?
Most of our work begins there. The usual first step is a lock-in assessment: what is genuinely proprietary, what is merely undocumented, what data can be liberated immediately, and what an incremental path to a standards-based integration layer looks like without interrupting live services.