DRC now,
DCS later.

The strategy in three short paragraphs.

In the next three to six months, we build and launch Digits Research Connect (DRC) — a Research-Use-Only web platform for academic researchers, powered by our two strongest publication-backed assessments: Range of Motion and Dexterity.

In the longer arc, DRC becomes the first client of Digits Core Service (DCS) — the regulated, SDK-accessible infrastructure that will power digital hand assessment across web, mobile, and the clinical AI products being built by Google, AWS, Microsoft, Anthropic, OpenAI, and Meta. In the further-out arc, the same measurement infrastructure extends into robotics through DIGITS Mimic — a standardized way to score humanoid robot hand performance against the human baseline DIGITS has already validated.

This memo asks for alignment on the DRC-first sequencing, on the four architectural commitments laid out below, and on the recommended sequencing of mobile and platform work that follows from them.

The opportunity is bigger than an app.

Until now we have framed DIGITS as a product company building hand assessment applications. The clinical validation, the publications, the patent-pending algorithms, the MediaPipe-based pipeline — all of it consistent with that framing.

But the actual asset we have built is something else: a trusted, peer-reviewed, regulatorily-defensible measurement service for the human hand. That asset can power one application, or it can power hundreds.

The question is whether we have a product they can license from. Today, we do not. The current ASP.NET Core web app is a vertically integrated application — not designed to be embedded, called over an API, or wrapped in an SDK. To win the distribution opportunity in front of us, the asset has to be re-shaped into infrastructure.

Why DRC first, not DCS directly

It would be tempting to start by building DCS — the platform — directly. We are choosing not to, for three reasons.

• Researchers are pulling on us. Academic clinical researchers are the most enthusiastic, ready-to-pay segment we have encountered. They have IRB infrastructure, study budgets, and an unmet need for validated digital hand assessment tools.
• Research Use Only is the fastest regulatory path. RUO products under IRB oversight do not require FDA premarket clearance, and Health Canada has analogous research exemptions. This lets us ship in months, not years — and the real-world data strengthens our eventual 510(k).
• Building DCS without a first client is speculative engineering. Platforms designed in the abstract are usually wrong. DRC gives us an honest forcing function for the API design — shaped by a real, paying user before it ever has to serve a hyperscaler.

Build the product. Let it become the platform.

Two analogies have helped us frame what DIGITS is becoming. The first — Stripe — describes the business shape: a delightful first product on top of regulated infrastructure that compounds into a platform. The second — Slack's headless platform, and the broader "headless" turn in enterprise software — describes the technical shape: a service whose primary surface is increasingly other products rather than its own UI.

Both apply. They are doing different jobs.

Stripe started as a payments API that one developer could integrate in an afternoon. The product was a payment form. The asset was the infrastructure underneath — the bank relationships, the risk models, the compliance posture, the API contract. Over a decade, Stripe layered on tiered products (Connect, Atlas, Issuing, Climate) and grew into the payments infrastructure for the internet. The original payment form became one of dozens of consumption surfaces.

DIGITS has a structurally similar opportunity. The shape of the parallel is worth being explicit about:

The strategic move is the same one Stripe made: build the first delightful product as a real product, but architect it so that the asset underneath becomes the platform.

Stripe explains what kind of company DIGITS is becoming. Slack's recent platform direction explains what kind of product DCS is.

In September 2025, Slack announced a major reorientation of its developer platform for what it called "the agentic era." Two pieces of that announcement matter for us:

• Headless agents. Slack now supports "click-to-create headless agents" — agents that live inside Slack but operate without a traditional UI, callable by other agents and surfaced wherever the work is happening. The agent is a capability, not a destination.
• Slack inside other AI apps. The new Real-Time Search API and MCP server make Slack's conversational data available inside Claude, Perplexity, and other AI clients. Slack is no longer only a place users go. It is a service that other products consume.

Salesforce extended this further in April 2026 with what it branded Headless 360 — the more aggressive claim that "our API is the UI." Every Salesforce capability — CRM, Agentforce, Slack — is now exposed as APIs, MCP tools, and CLI commands, designed to be consumed by agents and products that may never render a Salesforce screen.

The pattern across both companies is the same, and it is the pattern DCS is built around:

One implication worth naming explicitly: a headless service has different success metrics than an app. Daily active users matter less than API call volume, integrator count, and the quality of the partners who depend on us. The number of products that cannot ship without DIGITS is the number that matters. DRC will produce both — paying users and partner relationships — but as DCS opens up, the partner-count metric is the one that compounds.

Decisions that shape both DRC and DCS.

This strategy depends on four decisions we are asking the team to commit to now. Each one shapes both the product we ship in six months and the platform we are building toward. We have intentionally chosen the simpler option for the near term and named the harder option as the future destination.

From DRC to DCS, without rewrites.

The strategic claim of this architecture is that DRC and DCS are not two separate builds. They are one build, sequenced — where every component of DRC v1 either becomes part of DCS unchanged, or stays inside DRC as one of many clients of DCS. Nothing built in the next six months is wasted in the platform we are building toward.

Mobile, sequenced

DIGITS will ship a native mobile experience. The question is when, and against what foundation. The recommendation in this plan is that mobile follows DCS rather than precedes it — for a specific architectural reason: a mobile app built today would integrate against the legacy web architecture, and would need to be re-integrated against DCS once it exists. Building once, against the right foundation, is faster than building twice.

The recommended sequence is therefore:

• Months 0–6. Mobile-readiness work happens implicitly through the DRC build: the assessment API contract that DRC consumes is the same contract a mobile app will consume. Every API design decision is made as if a mobile client were already calling it.
• Months 6–12. Mobile development begins in earnest as the first non-web client of DCS. React Native against the DCS SDK. Web and mobile become peers — both consumers of the same service — with the experience properly cross-platform from day one rather than retrofitted later.
• Months 12+. Mobile becomes a primary surface for clinical-mode deployments, where patient-at-home assessments are most natural on a phone.

This sequencing is a deliberate strategic choice, not a deprioritization. Mobile-first researchers exist, but they are a smaller segment than desktop-first researchers, and the research workflows DRC supports — study setup, multi-subject management, longitudinal data export — are desktop-natural. Mobile's strongest use cases sit in the clinical and patient-facing tiers, which is exactly where the timeline brings mobile online.

Beyond healthcare: DIGITS Mimic.

Everything in this memo so far has treated DIGITS as digital hand assessment infrastructure for healthcare. That framing is correct for the next three to five years. It is not the whole opportunity.

The longer arc of DIGITS extends into a sector that today has the same problem healthcare had ten years ago: no standardized way to measure hand performance. That sector is humanoid robotics. We are calling this future capability DIGITS Mimic.

Humanoid robots are being built by Tesla, Figure, Boston Dynamics, Agility, Sanctuary, Unitree, and a wave of well-funded entrants. The hand is the hardest part of the body to engineer, and dexterity is the bottleneck capability that determines whether a humanoid robot can do useful work. Every one of these companies is, separately, trying to figure out how good their robot's hand actually is.

The robotics research literature has been explicit about this gap for years. A few representative voices:

Multiple competing benchmarks exist — Elliott and Connolly, HD-marks, HumanoidBench, DexH2R — but no single standard has emerged, and none of them is anchored to a clinically validated human baseline. Robotic hands are typically evaluated against ad-hoc "human baseline results" produced by the same lab that publishes the benchmark, with no inter-lab consistency.

DIGITS has, almost as a byproduct of our healthcare work, built the thing the robotics field has been asking for: a clinically validated, peer-reviewed, regulatorily-defensible measurement system for the human hand, with a real and growing human reference dataset. Our healthcare moat doubles as the missing component of an industry-standard robotics benchmark.

DIGITS Mimic is a service, exposed through the same DCS infrastructure that powers our healthcare products, that scores a humanoid robot's hand performance against the human DIGITS baseline using identical methodology. A robotics company points DIGITS Mimic at their robot's hand performing standard tasks; DIGITS returns range-of-motion and dexterity scores expressed on the same scale as our human assessments.

Concretely, the value proposition has three parts:

• A single, consistent score across humans and robots. A robot scoring at the 60th percentile of human dexterity means the same thing across every lab, every company, every product cycle. The fragmentation problem disappears.
• A clinical-grade reference baseline. The DIGITS human baseline is peer-reviewed, regulator-recognized, and growing every time a researcher or clinician uses our healthcare products. No competing benchmark can match this.
• An external, third-party measurement. Robotics companies cannot credibly self-score against an in-house benchmark when raising capital, marketing to customers, or claiming product-market fit. DIGITS is the independent referee.

Adding DIGITS Mimic to the long-term plan does three things for the company:

• It widens the moat without widening the build. Mimic does not require new ML, new clinical validation, or a separate regulatory pathway. It reuses the assessment engine, the scoring methodology, and the API contract that DRC and DCS are already producing. The robotics offering is a new surface on the same platform.
• It opens a market with very different unit economics from healthcare. Robotics companies have venture-funded R&D budgets and short procurement cycles. A Mimic license could be priced at a small fraction of a single robotics engineer's annual cost and still be one of the largest revenue lines DIGITS has — without touching healthcare reimbursement complexity.
• It strengthens the "standards body" positioning. If DIGITS becomes the canonical way to measure hand performance for both humans and machines, the moat is no longer just clinical validation — it is industry adoption of a measurement standard. That is the strongest possible competitive position.

The dual-baseline framing is worth being explicit about, because it changes how we describe what DIGITS is:

Concretely: nothing changes in the DRC build. Mimic is a Phase 3+ capability, not a Phase 1 or Phase 2 commitment. The reason it belongs in this memo is that knowing Mimic exists in the long-arc plan affects two near-term decisions:

• Telemetry design. The de-identified telemetry we begin collecting from DRC is the seed dataset that makes our human baseline more authoritative over time. Designing telemetry to grow that baseline asset — not just to measure DRC product performance — matters more if we know it will eventually anchor a robotics benchmark.
• Methodology documentation. The scoring methodology we publish for DRC needs to be precise enough that it can later be applied to a non-human hand and produce comparable scores. This is a low-cost discipline if we adopt it now and an expensive retrofit if we don't.

Beyond those two threads, Mimic is a future-state capability that informs investor and partner narratives — particularly for hyperscaler conversations, where robotics is a parallel platform play many of the same companies are already making — but does not require any near-term engineering commitment.