Keryx adoption strategy

Last reviewed: 25 August 2026

Keryx is SafeCall's first-party mobile notification companion for SafeCall administrators. It replaces the generic ntfy app in the client workflow: an administrator selects friendly alert categories in SafeCall, scans a generated QR code on their own phone or tablet, and receives those alerts in a branded Active/Archive experience.

This is a go-to-market strategy for adoption inside SafeCall accounts. It is not a plan to create an independent Keryx market, product line, or acquisition funnel. The go-to-market roadmap remains the source of truth for launch readiness, technical gates, risks, and GitLab execution.

Strategy in one sentence

Make Keryx the supported default way for SafeCall administrators to receive mobile notifications, beginning with eligible existing installations and then including it in active SafeCall and AlertHub opportunities.

Fixed product decisions

The following decisions are settled constraints:

• Keryx is part of SafeCall and is not independently marketed.
• The intended app user is a SafeCall administrator or operator with administrative responsibility, not a consumer or general-purpose responder audience.
• The administrator selects understandable SafeCall alert categories and scans a QR code generated by their SafeCall installation.
• SafeCall and Keryx own the configuration experience. Ordinary administrators must not need to know about ntfy servers, topics, subscriptions, or manual third-party client setup.
• ntfy can remain part of the delivery implementation and restricted deployer/support documentation; it is not the customer-facing product model.
• Keryx replaces the generic ntfy app with SafeCall-controlled branding, onboarding, notification presentation, and support.
• App Store and Google Play distribution are installation channels for contracted SafeCall clients, not self-service sales or demand-generation channels.
• The initial public release is available in the Czech Republic only.
• The launch audience is SafeCall administrators aged 18 or older; Keryx does not target children or participate in kids/families store programs.
• English is the primary/default store language and complete English/Czech parity is required across the app, SafeCall provisioning, listings, assets, and client material. Missing Czech parity blocks launch.
• Keryx is classified as a Business app. It provides no health functionality, is not a regulated medical device, and is not listed in Health & Fitness or Medical categories.
• Keryx has no independent SKU, in-app purchase, or standalone price. Any infrastructure, implementation, or support cost belongs to the wider SafeCall commercial agreement.
• The SafeCall-generated QR configures connectivity and selected alert categories; it does not purchase, subscribe to, license, or unlock paid digital content.
• Keryx has no user account, checkout, subscription, external purchase link, or in-app purchase call to action.
• Clients may assign or install the public app through standard MDM channels, but administrators still grant permissions and scan a SafeCall-generated QR. Managed configuration and zero-touch provisioning are not launch features.
• Launch support is limited to iOS/iPadOS 17+ and Android 12/API 31+ on the approved phone/tablet, orientation, OEM, camera, and Google Play-certified matrix. Source installability on older versions is not a support promise.
• Tier 1 Android support covers tested Google Pixel/AOSP and Samsung devices. Tier 2 support is model/OS-specific after documented battery exceptions; unqualified/no-GMS/custom/rooted/EOL devices are unsupported.
• WCAG 2.2 AA critical flows, VoiceOver/TalkBack, 200% text, contrast, target size, focus, reduced motion, and camera/notification recovery are launch-blocking requirements. No conformance claim is made before P4 physical-device evidence passes.

Changing one of these constraints requires an explicit product decision and a review of the roadmap, store narrative, UX, support model, and this strategy.

Intended administrator journey

flowchart LR
  SafeCall[SafeCall administration]
  Categories[Friendly alert categories]
  QR[Generated QR code]
  Keryx[Keryx on administrator device]
  Verify[Verified test notification]
  Use[Active and Archive workflow]

  SafeCall --> Categories
  Categories --> QR
  QR --> Keryx
  Keryx --> Verify
  Verify --> Use

1. An administrator opens the mobile-notification area in their SafeCall installation.
2. They select friendly categories such as panic-button, low-battery, sensor, or installation-health alerts.
3. SafeCall generates a QR code containing the required configuration.
4. The same administrator installs Keryx from the relevant public store and scans the QR code on their own device.
5. Keryx requests required permissions, configures delivery without exposing transport details, and prompts the administrator to verify a safe test notification.
6. The administrator works with notifications through Active and Archive, including pause, rescan, and reset controls.
7. Replacement, revocation, troubleshooting, and offboarding remain supported SafeCall administration tasks.

Topic names, server URLs, credentials, APNs/FCM integration, and delivery infrastructure may appear in guarded diagnostics or restricted deployer/support material. They are not steps in the normal journey.

Current product-to-strategy gaps

The working product proves the basic QR and notification model, but it does not yet fully deliver the intended journey:

• the SafeCall card is currently named Ntfy Notifications;
• provisioning and documentation still use topic-oriented language;
• unconfigured Keryx guidance assumes that an end user asks a separate administrator for a QR code;
• security, authenticated provisioning, Android background delivery, and iOS killed-state delivery have unresolved launch blockers;
• administrator quick-start, migration, support, and public store-install guidance do not yet exist.

These are readiness gaps, not reasons to weaken the product model. Their acceptance criteria live in roadmap P1, P2, and P4.

Audience and account focus

App user

The initial app persona is a SafeCall administrator aged 18 or older: the person responsible for configuring, monitoring, or supporting a SafeCall installation and its operational alerts. A delegated operator belongs to this persona only when they carry that administrative responsibility.

General employees, consumers, family members, and a broad responder workforce are not launch personas. Expanding to them would change provisioning, credential sharing, privacy, support, offboarding, and commercial assumptions and therefore requires a new product decision.

Commercial stakeholders

• SafeCall account owner: approves use of Keryx within the contracted deployment.
• SafeCall administrator: selects categories, provisions their device, verifies delivery, and uses the app.
• Client IT/security owner: approves mobile, network, notification, and device-management prerequisites, any model-specific least-privilege battery exception, and the managed-device policy profile.
• SafeCall implementation/support: prepares infrastructure, resolves transport-level issues, and owns escalation.
• SafeCall sales/account owner: introduces Keryx only as part of the wider SafeCall or AlertHub value proposition.

Priority order

1. Existing SafeCall clients with a supported installation, an administrator need for mobile alerts, and infrastructure that can pass the roadmap readiness checklist.
2. Existing clients that currently use the generic ntfy app and can be migrated through a controlled category-to-QR process.
3. Active SafeCall or AlertHub prospects for whom administrator mobile notifications strengthen the broader solution.
4. Wider client availability after pilot, support, and release gates pass.

The account list, client names, commercial notes, and deployment details remain in the approved CRM or client system. This repository records only aggregate strategy, acceptance criteria, and non-sensitive evidence links.

Not a target

• people without a contracted SafeCall deployment;
• generic ntfy users looking for another ntfy client;
• consumer app-store traffic;
• organizations seeking a standalone notification service;
• prospects whose required reliability, device, region, or security posture has not passed the roadmap gates.
• devices, OS versions, OEM/model combinations, or restrictive profiles outside the approved P0-04 matrix.

Positioning

Canonical internal statement

Keryx for SafeCall is the SafeCall mobile notification companion for administrators. Select the alerts you need in SafeCall and scan a QR code; Keryx configures delivery and presents notifications in a purpose-built, first-party Active/Archive experience. There is no third-party notification app or manual topic setup to manage.

This statement is the basis for sales enablement, store copy, administrator guidance, and reviewer instructions. Roadmap P0-01 approves sourcectl as publisher, Keryx for SafeCall as the store and in-app name, Keryx as the launcher label, Android com.sourcectl.keryx, and iOS com.sourcectl.keryxapp (29 August 2026 amendment after Apple would not release the original iOS App ID). Wantok is the product umbrella, SafeCall is the contracted platform, and Keryx for SafeCall is its administrator companion. BleuVista remains a separate market-facing portfolio/channel; AlertHub is its SafeCall-powered emergency-alerting solution and does not own Keryx. NavBeacon remains separate. Visual mark, wordmark rules, palette, and asset-kit gaps are approved in visual identity (P2-01).

Message pillars

1. SafeCall-native setup: selection starts in the SafeCall administration interface, not in a third-party app.
2. Scan instead of configure: the QR code carries the required setup and removes manual server and topic entry.
3. Purpose-built administration: Active/Archive, badges, pause, rescan, and reset support the SafeCall notification workflow.
4. First-party ownership: branding, documentation, release lifecycle, and support remain under SafeCall control.
5. Honest delivery limits: Keryx is subject to network, notification, platform, device-power, and service constraints and is not described as a guaranteed emergency channel.

Language guardrails

Use:

• “Keryx for SafeCall”;
• “SafeCall mobile notification companion”;
• “for SafeCall administrators”;
• “select alert categories and scan a QR code”;
• “requires a configured SafeCall deployment”;
• “supplemental operational notifications,” where delivery limits need to be stated;
• “supported after the published device and client-IT prerequisites pass.”

Do not use:

• “standalone notification app” or “notification platform”;
• “for anyone” or consumer-oriented acquisition copy;
• “configure your ntfy server/topics” in ordinary administrator guidance;
• “guaranteed,” “always delivered,” or unsupported “instant emergency” claims;
• wording that describes Keryx as medical, diagnostic, treatment, clinical monitoring, or health functionality;
• “supports all Android devices,” “works on any managed device,” “fully accessible,” or other compatibility/conformance claims not backed by the P0-04/P4 matrix;
• wording that suggests the free store download grants access to SafeCall without a contract.

Approved commercial wording

P0-03 approves this fact pattern for reviewer, listing, sales, support, and client-onboarding material:

Keryx for SafeCall is a free mobile companion for administrators of a separately contracted SafeCall physical/building deployment. Downloading Keryx does not buy or provide SafeCall. The SafeCall-generated QR configures connectivity and selected alert categories for that deployment; it is not a payment, subscription, license, or paid digital-content unlock.

The final English/Czech wording remains a P2 deliverable, but every surface must preserve these audience-specific rules:

• Listing lead: state the SafeCall dependency before features. Say the app is free, requires compatible SafeCall configuration, and has no Keryx account, checkout, subscription, or in-app purchase.
• Reviewer notes: identify the separately contracted physical/building deployment; explain QR connectivity; provide an isolated SafeCall-style environment, durable sample QR, and safe test notification; never use client data or require manual ntfy/topic setup.
• Sales/account: offer Keryx only within SafeCall/AlertHub opportunities. Quote the wider deployment, implementation, infrastructure, and support, never a Keryx SKU, and do not send unqualified prospects to the store.
• Support: explain that downloading the free app alone cannot receive alerts. Contracted clients need setup from their SafeCall installation; non-clients follow the wider SafeCall commercial path, not an in-app link.
• MDM/client IT: the same public app can be assigned or installed through Apple Business Manager/standard MDM or managed Google Play. This is an installation channel only. Keryx does not support managed app configuration, injected credentials, deep-link provisioning, zero-touch setup, custom/private binaries, or silent configuration at launch. Restrictive policies require client IT review and supported-device evidence.

Offer and packaging

Keryx is included as a SafeCall companion capability:

• the mobile binary is free to download from the selected public stores;
• use requires a compatible, contracted, and correctly configured SafeCall installation;
• no Keryx subscription, standalone quote, in-app purchase, or self-service onboarding is offered;
• implementation work, notification infrastructure, client IT prerequisites, training, and support are handled under the applicable SafeCall agreement;
• initial public availability is limited to the Czech Republic and approved iOS/iPadOS 17+ and Android 12/API 31+ phones/tablets, OEM tiers, orientations, and client environments;
• both English and Czech experiences must be complete before launch;
• standard public-app MDM assignment is permitted for installation, but interactive permissions and QR provisioning remain required;
• support follows the SafeCall support channel and escalation model under the P0-05 operating class: Czech business hours (Monday–Friday, CET/CEST), next-business-day first response, and same-business-day acknowledgment of supported-tier core-path incidents by the go/no-go owner; there is no standalone Keryx mailbox, public status page, 24/7 desk, or emergency-dispatch SLA;
• go/no-go authority and backup are Thomas Minitsios (single-person concentration is a named risk reviewed at account-recovery verification and the first P5 go/no-go);
• no beta or production calendar date is set until remaining P1–P4 launch blockers are closed or explicitly accepted;
• no analytics or crash SDK ships at launch; field diagnosis is client-reported until a later privacy-approved minimum signal exists.

The stores must explain this dependency clearly enough to prevent misleading consumer installs while still providing durable reviewer access.

Existing-client adoption play

1. Identify eligible installations

The SafeCall account owner and implementation team review the external account inventory for:

• a supported SafeCall version and QR contract;
• an administrator use case for one or more friendly alert categories;
• an approved P0-04 iOS/Android version, form factor, orientation, OEM/model tier, functioning camera, and client-IT policy profile;
• production notification infrastructure that passes P1/P4 prerequisites;
• a named client owner, pilot administrator, and support path;
• no unresolved policy, security, privacy, or delivery blocker.

2. Run a readiness review

Confirm category mapping, test data, TLS/authentication, push prerequisites, retention, device policy, model-specific battery exceptions, accessibility and permission recovery, support coverage, rollback limitations, and offboarding. Transport details are handled by implementation/support, not handed to the administrator as setup instructions.

3. Demonstrate the complete SafeCall flow

Show category selection in SafeCall, QR generation, store installation, scan, permission recovery, a safe test notification, Active/Archive, pause, rescan, and reset. Do not demo Keryx as a disconnected app or teach manual topic entry.

4. Pilot with administrators

Pilot administrators provision their own devices without transport assistance, complete the agreed delivery and usability matrix, and record support needs. The pilot passes only when the tested production-equivalent architecture and the roadmap P4 acceptance criteria pass.

5. Roll out and support

Use store release channels and client communications approved by P5. Confirm first verified alerts, known platform limitations, escalation contacts, device replacement, revocation, and offboarding. Expand only within the staged rollout and stop thresholds.

6. Capture reusable evidence

Record privacy-safe aggregate outcomes, recurring objections, setup failures, support effort, and approved reference material. Client identity and sensitive deployment evidence remain in their controlled systems.

Migration from the generic ntfy app

Migration is a client change, not merely an app-install instruction:

1. Restricted implementation/support staff inventory the existing notification categories, recipients, transport configuration, and device constraints.
2. Map the required alerts to friendly SafeCall categories.
3. Prepare the authenticated Keryx QR flow and a safe test message.
4. Agree whether a short overlap is safe; account for possible duplicate notifications and do not silently remove the working fallback.
5. Have each administrator install Keryx, scan their QR, and verify expected foreground/background behavior.
6. Retire the generic ntfy subscription only after the client owner accepts the Keryx result and limitations.
7. Document reset, uninstall, credential revocation, and support outcomes.

Ordinary administrators should see a category and QR migration, not a list of topics to recreate.

Active-prospect play

Keryx supports a SafeCall or AlertHub opportunity; it does not create a separate lead:

1. Establish the broader SafeCall problem and contracted deployment model.
2. Introduce Keryx as the first-party administrator notification experience.
3. Demonstrate the complete SafeCall-to-Keryx flow using safe data.
4. State platform, infrastructure, support, and delivery limitations.
5. Include Keryx readiness and pilot work in the wider SafeCall proposal and implementation plan.
6. Do not direct prospects to download Keryx before a compatible test or contracted SafeCall environment exists.

Public AlertHub or BleuVista material may reference the capability only after P2 applies the approved P0-01 hierarchy and approves the resulting portfolio language. It must link back to SafeCall installation/support information rather than creating an independent Keryx conversion path.

Enablement package

The launch program must produce:

• a one-page internal positioning and qualification brief;
• an eligible-installation and infrastructure readiness checklist;
• a SafeCall-to-Keryx demonstration script with safe test data;
• an administrator quick-start for category selection, QR scan, permissions, test notification, and Active/Archive;
• a controlled generic-ntfy-to-Keryx migration guide;
• administrator troubleshooting and offboarding guidance;
• support triage and escalation material that separates ordinary UX from restricted transport diagnostics;
• store listing, reviewer, privacy, terms, install, and support material that states the SafeCall dependency;
• release and client communication templates.

Roadmap P2 owns approved public/store content. P4 owns readiness, guides, and pilot evidence. This strategy owns why the artifacts exist and how they support adoption.

Objection handling

Why not keep using the ntfy app?
Keryx removes third-party branding and manual endpoint/topic setup, presents SafeCall categories and workflows, and gives SafeCall ownership of the administrator experience and support lifecycle.

Can someone use Keryx without SafeCall?
No. Keryx requires configuration generated by a compatible SafeCall installation and is not a general notification client.

Why is Keryx free if SafeCall is contracted separately?

The store binary is an installation convenience included with a separately contracted SafeCall physical/building deployment. Keryx is not sold separately and downloading it does not purchase or provide SafeCall.

Does the QR buy or unlock digital content?

No. The QR supplies connectivity settings and the administrator's selected alert categories for their SafeCall deployment. Keryx has no account, checkout, subscription, paid SKU, external purchase link, or in-app purchase.

Can client IT deploy Keryx through MDM?

Yes, as the same public app and for installation only. Administrators must still grant required permissions and scan their SafeCall-generated QR. Managed configuration, zero-touch setup, injected credentials, and blanket compatibility with restrictive profiles are not supported launch claims.

Which devices are supported?

The launch baseline is iOS/iPadOS 17+ and Android 12/API 31+ on the published phone/tablet, orientation, OEM/model, camera, and client-IT matrix. Pixel/AOSP and Samsung are required Tier 1; named Tier 2 model/OS combinations require evidence and approved battery settings. Source installability or a broad OEM family name alone is not a support commitment.

Does Keryx conform to WCAG 2.2 AA?

WCAG 2.2 AA critical flows and the approved assistive-technology, text-scale, contrast, focus, target-size, motion, and permission-recovery criteria are launch requirements. Do not claim current conformance until P4 physical-device evidence passes.

Does Keryx guarantee emergency delivery?
No. Delivery depends on the approved client infrastructure, network, operating system, notification settings, device power behavior, and current service state. Approved fallback and escalation procedures remain necessary.

Why does the app need camera access?
The camera scans the SafeCall-generated QR code so the administrator does not have to enter transport configuration manually.

Can administrators type a server or topic manually?
Not in the normal supported workflow. Restricted diagnostics may expose technical details when approved, but manual configuration would recreate the problem Keryx is intended to solve.

Can a client give Keryx to a broad responder population?
Not under the launch model. The initial audience is SafeCall administrators. Expanding the persona requires a new provisioning, credential, privacy, support, and commercial decision.

Adoption and outcome measures

Targets are set by the P0-05 accountable owner during P4; this strategy does not invent volumes or dates.

Adoption funnel

• eligible SafeCall installations identified;
• installations passing technical and policy readiness;
• clients agreeing to an administrator pilot;
• administrators completing QR provisioning;
• administrators receiving the first verified test notification;
• pilots passing usability, delivery, upgrade, and soak criteria;
• approved client rollouts;
• supported administrators active on approved Keryx versions.

Experience and operational outcomes

• time and completion rate from category selection to first verified alert;
• provisioning failures that require explanation of ntfy/topics or support intervention;
• delivery latency, missed/duplicate alerts, reconnects, and platform-specific failures in the controlled evidence set;
• permission, battery, QR, replacement, reset, and migration support contacts;
• support first-response and resolution time;
• crash/stability signal only after a privacy-approved minimum collection decision; launch collects none by default;
• generic ntfy configurations retired only after accepted migration;
• client retention, expansion, or reference evidence influenced by Keryx;
• store review, rating, policy, and unsupported-install themes.

No metric authorizes analytics or collection of administrator/client identifiers. P0-05 prohibits an analytics or crash SDK at launch; any later signal requires an approved purpose, minimization, consent where required, retention, access, and disclosure decision. CRM and deployment counts remain external; the repository may retain only approved aggregate results or evidence links.

Adoption gates

• A0 — Model fixed: this document and the roadmap agree on the SafeCall, administrator-only, non-standalone role.
• A1 — Accounts qualified: external account owners identify eligible installations and named pilot responsibility.
• A2 — Workflow ready: friendly categories, QR provisioning, first-party copy, infrastructure, and release candidate pass the affected roadmap gates.
• A3 — Pilot accepted: administrators provision without transport knowledge and the production-equivalent delivery/usability matrix passes.
• A4 — Client rollout authorized: support, communication, staged release, stop thresholds, and offboarding are owned.
• A5 — Operational adoption: supported installations and versions are reviewed through the P6 cadence and evidence informs the SafeCall roadmap.

Decision and experiment register

Use a GitLab work item or linked controlled record for each open hypothesis:

Question or hypothesis:
Why it matters:
Documented facts:
Assumptions:
Affected SafeCall clients or segment:
Owner:
Validation method:
Evidence location:
Decision deadline:
Result:
Decision and date:
Roadmap/work-item changes:
Review or expiry date:

Initial hypotheses to validate without changing the fixed model:

• administrators understand the friendly category names without topic explanation;
• an administrator can complete install-to-test-alert without transport assistance;
• replacing the generic ntfy app reduces configuration and support burden;
• Active/Archive and current controls fit the administrator workflow;
• store copy and in-app onboarding prevent reviewers and store visitors from mistaking Keryx for a standalone service;
• the approved support and telemetry posture provides enough evidence to operate Keryx without unnecessary personal data.

Do not place client names, contact details, production QR payloads, credentials, topics, incident content, or commercially sensitive account notes in this document.

Roadmap handoff

• P0: P0-01 fixes sourcectl as publisher, Keryx for SafeCall as the public name, and the Wantok/SafeCall hierarchy. P0-02 fixes Czech-only, English/Czech, adult-administrator, Business, and non-medical launch classification. P0-03 fixes the free-companion, QR-configuration, payment-free, reviewer, sales/support, and installation-only MDM narrative. P0-04 fixes the OS, form-factor, orientation, OEM/battery, managed-device, and accessibility baseline. P0-05 fixes launch RACI, go/no-go authority, the unset-until-gates date policy, the SafeCall support operating class, and the no-analytics launch telemetry posture. P0 is complete; later phases must not reopen the fixed product role.
• P1: makes hidden transport secure and supportable and approves honest privacy, delivery, and safety claims.
• P2: turns this positioning into SafeCall-related store, install, support, screenshot, and localized content.
• P3: creates trustworthy store artifacts and account/signing continuity.
• P4: proves friendly-category provisioning, administrator usability, migration, real-device delivery, guides, and the client pilot.
• P5: gives reviewers the same SafeCall flow and controls client rollout without a standalone Keryx campaign.
• P6: maintains compatibility, support, updates, renewals, and privacy-safe adoption evidence.

Strategy decisions belong here, readiness and accepted risks belong in the roadmap, execution state belongs in GitLab, and client/account records remain in their approved external systems.