You're in a procurement meeting. A supplier has shown you a polished app with your logo on it, your colours, your station names. It looks ready. Then someone asks who owns the accessibility statement, who updates the step-free route when a lift fails, and what happens to your content if you change supplier. Silence. That's the point where a white label application stops being a branding exercise and becomes an operational decision.

I'm Tom Pey, Founder and a blind accessibility technologist. I built navigation technology because I needed it to work in real stations and venues, not in a demo. My advice is direct. Buy the reusable capability if it's hard to build. Don't outsource accountability for accessibility, data quality, or exit rights.

What a White Label Application Actually Is

A white label application is built and maintained by one provider, then released under another organisation's brand, content, and distribution channel. You control the customer relationship and the service promise. The provider supplies the repeatable technology underneath.

That's more than a reskinned interface. A reskin changes colours. A proper white label model changes who owns trust, content, support, and day-to-day operations.

The diagram below separates the provider, brand, content, and distribution layers.

Why UK Retail Explains the Model Well

Britain learned this model in grocery long before software. A 2010 University of Oxford paper reported that private-label products accounted for approximately 47% of the total UK grocery market, based on Nielsen Homescan data, in its Oxford research on UK private label scale. Sainsbury's was reported in the same work to offer almost 13,000 products in private-label ranges.

Retailers didn't win by putting their name on someone else's tin. They controlled product innovation, merchandising, and supply chains, then segmented ranges across economy, mainstream, premium, organic, and specialist categories. The visible brand earned trust. The underlying production stayed repeatable.

Software follows the same logic. If you're comparing platform models more broadly, this white-label DXP platform overview sets out how rebrandable software is packaged for resale and reuse.

What This Means for Navigation and Wayfinding

Navigation fits the model naturally. A transport operator, hospital, university, or stadium already owns the relationship with passengers and visitors. It also owns the local truth, including accessible entrances, platform changes, assistance points, and temporary closures.

The positioning engine, routing logic, and audio guidance don't need rebuilding for every venue. They belong in the shared platform. Your job is to govern the local configuration well.

Practical rule: If the supplier controls your content, your customer data, and your ability to leave, you haven't bought a white label product. You've rented shelf space in someone else's app.

Judge every proposal on that split. Brand control without data control isn't ownership. It's decoration.

White Label Compared With Custom and Off-the-Shelf Software

Don't start by asking whether white label is fashionable. Ask which delivery model matches your risk, timeline, and internal capability. UK procurement teams usually care about seven things, and the table below puts them side by side.

Comparing White Label, Custom, and Off-the-Shelf Software

Where Each Model Breaks Down

Custom software gives you the deepest fit. It also multiplies timeline risk, recruitment risk, and long-term maintenance. If the hard problem is indoor positioning, you're funding specialist engineering that already exists elsewhere. That's rarely a sensible use of public money.

Off-the-shelf SaaS is quick, but it usually forces your passengers into someone else's brand and someone else's roadmap. That creates a problem for public services. Users trust the operator in front of them, not an unfamiliar vendor name at the moment they need help.

White label sits between the two. It's strongest when three conditions hold:

• Hard capability: The underlying technology is difficult, specialist, or expensive to replicate.
• Clear brand value: Your name materially increases trust, adoption, and accountability.
• Local variation: Each tenant needs its own content, routes, languages, and operating rules.

If those conditions don't hold, don't white label. Buy the standard product or build the bespoke one. For teams weighing an embedded route instead of a standalone branded app, our guide to indoor navigation SDK options explains where an SDK fits inside an existing app estate.

The trade-off is dependency. You gain speed and a maintained core. You accept platform limits. Make that trade consciously, with exit terms agreed before launch, not after your users depend on the service.

How a White Label Architecture Actually Works

A credible architecture separates what must be built once from what must change locally every day. If a supplier can't draw that separation on one page, don't buy it.

The hierarchy below shows the shared platform feeding a brand layer, then the user experience.

The Four Layers That Matter

Shared platform. This holds the difficult engineering, including positioning, routing, map handling, and core accessibility components. In infrastructure-free navigation, that includes dead reckoning using device-native sensors, so guidance continues indoors and underground without GPS, Wi-Fi, or installed beacons. Our explainer on how an indoor localization system works covers the positioning layer in detail.

Tenant configuration. Each operator gets isolated branding, content, languages, points of interest, and admin roles. Venue teams should amend a closed entrance or a moved assistance point without waiting for a full app release.

Data pipeline. Accessibility information arrives through versioned APIs or controlled CSV pipelines, with owner, timestamp, source, and expiry rules attached. Unknown must stay unknown. Never let the app infer that an unlisted facility is accessible.

Release layer. Platform releases and tenant content updates move on different tracks. That decoupling is what makes the model scale.

The short video below shows how sensor-based guidance behaves in a real built environment.

Integration is where deployments succeed or stall. Your app must connect cleanly to existing operational systems, identity services, and content workflows. Organisations planning that work often review integration services for enterprises to understand how third-party systems are connected without rebuilding the core platform.

Demand tenant isolation in writing. Separate credentials, role-based administration, audit logs, and controlled publication workflows aren't extras. They're the controls that stop one tenant's error becoming every tenant's incident.

When Customisation Quietly Reduces Accessibility

A white label application is not automatically an accessible application. That's the assumption I challenge most often, and it's the one that harms disabled users first.

UK public-sector bodies remain responsible for accessibility even when a supplier provides the product, and UK government guidance on equality and accessibility regulations requires mobile applications to meet WCAG 2.2 AA and publish an accessibility statement. Outsourcing the build doesn't outsource the duty.

The checklist below summarises where accountability stays, even after customisation.

Why the Testing Burden Is Per Tenant

Every change can introduce a barrier. New brand colours can fail contrast. Renamed navigation labels can confuse screen-reader users. A different map treatment, notification pattern, or form flow can break a journey that passed testing in the base product.

Independent UK testing reported accessibility barriers in 72% of tested user journeys, as cited in the government guidance linked above. Treat that as a warning against validating only the vendor's demo build. Test the configured version your users will receive.

WCAG 2.2 AA requires content to be perceivable, operable, understandable, and compatible with assistive technology. In app terms, that means correctly labelled controls, support for large text, working error handling, and content usable in both portrait and rotated screen orientations without complex gestures. From October 2024, UK monitoring moved to WCAG 2.2, as set out in the government accessibility monitoring report for public sector websites and mobile apps.

Who Owns the Accessibility Statement

Each public-facing branded app needs its own statement, published where users find information about that app. The supplier can provide testing evidence, known-issue records, and templates. Your organisation must verify its own content, features, support contacts, and release version, as required by government guidance on publishing an accessibility statement.

Our overview of current digital accessibility standards is a useful starting point for acceptance criteria. Put one question to every vendor, in the first meeting.

Who owns the accessibility statement for our branded version, and who retests it after every configuration change?

If the answer is vague, walk away.

Why Operators Choose Branded Navigation Apps

A passenger who cannot see the departure board does not care whose SDK sits inside the app. They care whether the voice telling them to turn left belongs to an operator they already trust, and whether it is right.

That is the reason operators choose branded navigation. The name on the app store listing carries trust they spent years building. The alternatives create friction they cannot afford: a third-party app passengers must discover and download on their own, or installed hardware across every site.

Transport Operators Need Fewer Things to Maintain

Metro and rail networks run high-footfall, high-change environments. Beacons and fixed hardware create a permanent maintenance burden. Batteries fail. Layouts change. Contractors move things. An infrastructure-free platform removes that estate-wide upkeep.

Hardware-free is the point.

That operational logic sits behind deployments and programmes associated with WMATA, SBS Transit, LTA Singapore, and CapMetro Austin. The aim is keeping guidance accurate across complex interchanges without installing and maintaining equipment everywhere. In the UK, the Equality Act 2010 frames the duty. In the United States, ADA Title III does comparable work for public accommodations.

Venues Need Content They Can Change Today

Retail, health, and stadium teams face a different friction. Layouts change constantly. A clinic moves, a gate closes, a shop unit turns over. If every change needs an app release, staff stop updating the system and users lose trust.

Named UK settings such as the Royal Hospital for Children and Young People, Lord's Cricket Ground, and Westfield London illustrate why tenant-controlled points of interest matter. The venue team knows what changed this morning, and the platform must let them publish it this morning. Our Liverpool ONE case study shows the same content-control principle in a large retail destination.

Stale guidance is worse than no guidance for a disabled visitor. Standards such as BS 8300, PAS 78, BS EN 17210, and the UN Convention on the Rights of Persons with Disabilities all point toward accessible information and independent movement, and they reward systems that stay current without capital works.

Campuses and Councils Need a Route Around Capital Approval

NHS estates managers and council teams rarely win easy capital approval for installed infrastructure. Budget cycles are slow, and buildings are shared, listed, or constantly reconfigured. A software layer that needs no beacons and no pre-mapping fits that political reality.

For estates teams in that position, Waymap is one relevant option. It provides navigation through a customer's branded app, using smartphone motion sensors to guide people indoors, outdoors, and underground without GPS, Wi-Fi, or installed hardware.

Choose branded navigation when your name carries trust and your content changes often. Treat the logo as the easy part. The harder question is whether the configured build underneath it still meets the accessibility standard your passengers rely on, because a rebrand never carries conformance with it.

Procurement and Governance for an Accessible White Label Launch

Speed to launch is a weak procurement criterion on its own. Buy evidence, portability, and operational control. The playbook below is what I'd expect a competent UK buyer to put in the contract.

Accessibility Evidence You Should Require

• WCAG and EN 301 549 evidence: Test records against the configured tenant build, not only the base platform.
• Disabled user research: Testing with people with different abilities during delivery and after launch.
• Tenant-owned statement: A named owner, an update trigger for every release, and a contact route for barriers.
• Remediation deadlines: Agreed fix times for known issues, with consequences for missed dates.

UK guidance on accessibility requirements for public sector websites and apps supports regular reviews throughout the contract lifecycle. Build those reviews into the service, not into a launch checklist that nobody revisits. Our guidance on public sector procurement for accessible technology goes deeper on structuring these requirements.

Data Contracts Matter More Than Visual Customisation

Treat accessibility data as a governed operational dataset. The UK National Centre for Accessible Transport reports that 57% of surveyed disabled people use an app to plan journeys, while only 23% express confidence in local-authority apps, in its NCAT report on the transport accessibility data gap. Branding won't close that confidence gap. Current, provenanced data might.

Require structured ingest, provenance retention, mandatory-field validation, and an explicit unknown state. The Department for Transport accessibility datasets cover stations, stops, and services across Great Britain, with data supplied by operators, local authorities, and public sources, as described in EsferaSoft's overview of London mobile app development and transport data. Your contract should mirror that discipline.

Acceptance test: Measure how quickly an infrastructure change appears in the app, and what share of accessibility records carry a current verification date.

Lifecycle Terms That Prevent Lock-In

Agree exit rights, data export formats, map and content ownership, API access, independent analytics, termination assistance, and renewal pricing before signature. A guide to software licensing deals can help your legal team frame the licence, ownership, and termination clauses that sit underneath the commercial promise.

Shorter contracts, open standards, and exportable configuration data keep you adaptable. Without them, a successful launch becomes a three-year hostage negotiation.

What to Ask a White Label Supplier Before Signing

Stop asking whether you should white label. Ask what must be contractually portable before you do. That question exposes weak suppliers in minutes.

White label works when the underlying capability is hard to build, when you control the customer relationship and operational data, and when accessibility is treated as a per-tenant obligation. It fails when the contract protects the platform more than the public service built on it.

Take this checklist into your next supplier conversation:

• WCAG 2.2 AA evidence: Ask for test results on a configured tenant build, not the vendor's polished demo environment.
• Statement ownership: Ask who updates the accessibility statement after each release, and get a name, not a team.
• Disabled user testing: Ask who tested, on which journeys, and what changed as a result.
• Portability proof: Have the supplier export your maps, content, and configuration during the pilot. A clause promising open formats means little until you have opened the file.
• Exit rehearsal: Ask what leaving would cost in months and effort, beyond the licence fee.
• Data freshness: Ask for verification dates and update times on accessibility records, in writing.

Judge the answers, not the demo. A supplier who welcomes those terms is selling a platform you can govern. One who resists is selling dependency.

For branded navigation, the test is the same. Infrastructure-free positioning, tenant-controlled content updates, and measurable accessibility outcomes decide whether the app earns trust at scale. Logos don't.

If you're evaluating a branded navigation app for a station, hospital, campus, stadium, or retail destination, talk to us before you sign anything. Visit Waymap to discuss infrastructure-free, step-accurate guidance that your team can govern, update, and measure under your own brand.