Why we built two accessibility products instead of one

Today we are launching not one accessibility product, but two.

Lumi Scanner is for the developer or agency who needs to monitor a site's WCAG compliance, hook it into a CI pipeline, and hand a branded PDF to a stakeholder.

LumiLens is for the person who uses a screen reader, navigates by keyboard, or relies on voice control, and wants to know whether a website will work for them before they invest the time trying.

Same scan engine. Same worker. Two completely different products. Here is why.

Two problems that look similar and aren't

We kept running into the same pattern. We would talk to a developer at an agency and they would describe a problem like "we need WCAG monitoring across 30 client sites with PDF reports we can hand over." Clear, technical, B2B.

Then we would talk to someone who uses NVDA and they would describe a problem like "I just want to know if this online bank works for me before I sign up." Same domain, completely different shape.

When we tried to imagine a single product serving both, every design decision became a compromise. Lead with a WCAG criterion list or a plain-language summary? Show CSS selectors or AT-specific guidance? Is the score a compliance percentage or a "will this work for me" indicator?

Every answer we gave made one audience happy and the other confused.

What developers actually need

Developers and agencies need accessibility as part of their existing workflow:

• - A score they can track over time
• - Specific code-level findings with WCAG references
• - CI/CD integration that fails a PR if the score drops
• - Multi-site dashboards for client work
• - White-label PDFs they can hand to clients
• - Webhooks, Slack, and an API key

That is a product with a dashboard, an API, and a CLI-friendly workflow.

What AT users actually need

Someone who uses assistive technology does not need a dashboard. They need:

• - A way to check a site before they visit
• - A plain-language report, not WCAG 2.4.7 violations
• - Guidance specific to their setup (NVDA, JAWS, VoiceOver, and TalkBack all behave differently)
• - Reviews from people who actually use AT, because automated scans miss most of the lived experience
• - A directory of sites that have already been checked

That is a directory product with reviews and AI personalisation. It looks nothing like a developer dashboard.

What is shared

We split the products at the UI layer, not the engine layer. Behind the scenes, both run on the same scanning infrastructure: five engines, 64 proprietary rules, the same Playwright worker, the same WCAG criteria. Building two engines would have been wasteful. Building two products on one engine is just good architecture.

Shared between the products:

• - The scan engine (axe-core, HTML_CodeSniffer, seven keyboard tests, 53 Lumi custom rules, four AI computed visual checks)
• - The Railway worker
• - The MongoDB cluster
• - The Stripe account
• - The user and organisation data model
• - The honesty principle: automated tools catch around 30 to 40 percent of issues, and we say so

Separate between the products:

• - Two Next.js apps, two domains, two Vercel projects
• - Two auth flows with separate session cookies
• - Two databases on the same cluster
• - Two pricing structures
• - Two product surfaces with no shared navigation

What the split lets us do

Two things we could not have done with a single product.

First, price differently. Scanner pricing reflects what teams pay for monitoring tools (£29 to £129 per month). LumiLens pricing reflects what consumers will pay for an AT-focused report platform (£0 to £7.99 per month). Charging a screen reader user £59 a month for a "personal" plan would have been a category error.

Second, evolve them independently. Scanner is roadmapped toward CI/CD plugins, VPAT auto-generation, and agency reseller tooling. LumiLens is roadmapped toward community collections, AT-specific discussions, and a public accessibility directory. Those are different products. They should be allowed to be.

The bet

Doing two things properly will beat doing one thing in a way that compromises both.

If you are a developer or an agency, head to lumi.livana.io. If you use assistive technology, or want to support a product built for people who do, head to lumilens.livana.io. Behind the scenes you are using the same engine. The product you are using just does not pretend you are the same person.