Product-market-fit evidence plan

Last evidence review: 2026-08-10. This is a research plan, not proof of demand or product-market fit.

Hypothesis and narrow wedge

Teams that already treat React Storybook as the source for component examples, tests, and documentation may have a narrower unsolved job: select a component they own and distribute reviewable source through a shadcn-compatible registry. Compify can reduce that work without asking the team to migrate its authoring workflow or trust runtime execution of story files.

Current Compify traction baseline

As of 2026-08-08, Compify has no demonstrated product-market fit. The first-party GitHub API reported 0 stars and 0 forks for a repository created on 2026-08-05. The npm downloads API reported 12 downloads for @compify/cli during 2026-07-08 through 2026-08-06; the npm registry still marked 0.1.0 as latest, and @compify/storybook was not published. These figures are a baseline, not a failure verdict: the release-candidate packages have not been distributed. The project-operated public-alpha API being reachable—including its current Storybook publish route—is a deployment fact, not a package release, managed service launch, user count, or adoption signal. These figures do mean that code quality, ecosystem size, downloads of adjacent tools, and synthetic E2E fixtures must not be presented as adoption, retention, willingness to pay, or PMF.

The next credible evidence is not traffic. It is a Verified Cross-App Handoff (VCH) from a non-demo external library: intentional story selection, reviewed artifact digest, native shadcn installation into a different repository, and a successful destination typecheck/build captured in a local receipt. The hard retention signal is a second distinct-component VCH by the same qualified team within 30 days.

The repository now includes one maintainer-operated technical replay against a pinned external react-uswds Button fixture: static inspection, native pinned shadcn installation, exact source preservation, explicit destination rendering, and a production build pass. Its Storybook preview stylesheet is intentionally outside the selected graph, so it is not visual-fidelity evidence. Because no external team selected, reviewed, or repeated that handoff, this replay is compatibility evidence only—not a qualified pilot, activation, adoption, retention, endorsement, or PMF evidence.

The proposed sequence is deliberately small:

1. start with an existing, intentionally selected React CSF file;
2. statically inspect the supported source boundary and show failures;
3. export a deterministic registry artifact for human review; and
4. install that source into a different application with the existing shadcn workflow.

This is a wedge hypothesis, not a claim that every Storybook is a component marketplace, that a story is automatically distributable, or that Compify has solved dynamic Storybook behavior. Current behavior and limitations are documented in Storybook translation; proposed research and metrics below are not shipped telemetry or managed-service promises.

Directional ecosystem signals

These are reach and activity proxies. Downloads are package downloads (including CI, caches, repeated installs, mirrors, and transitive use), stars/forks are GitHub actions, sitemap entries are catalog pages, and issues are individual reports. None is a count of users, teams, willingness to pay, or demand for Compify.

Theme release assurance adjacency: concierge evidence before product

Compify's legacy editor can create component-scoped factors, groups, semantic values, CSS variables, and flat JSON. That implementation is not evidence that teams want another theme editor, token platform, or AI palette generator. The internal shape audit and package stop gate are recorded in theme-contract-evaluation.md; they are schema evidence, not demand evidence. The only adjacent business hypothesis consistent with Compify's authority boundary is Theme Release Assurance: before a team releases an already-authored token or theme change, identify the statically observable component dependencies, run the checks the team already trusts in named destinations, and retain a reviewed digest-bound evidence bundle.

A qualified pilot must already have all of the following:

• a production React design system with Storybook;
• at least two brands/modes/themes, or one semantic-token set used by three apps;
• a named maintainer and monthly-or-faster token changes;
• a real release from the prior 60 days involving manual review, downstream repair, or regression risk; and
• one canonical Git input plus two destination applications it can use in a private, bounded pilot.

The activation event is a Verified Theme Release (VTR), not a theme saved or page visited. A VTR requires a non-demo external token commit, an explicit owner, a reviewed changed-token and impacted/unknown graph, declared checks over at least ten selected stories and two app destinations, and an approved evidence digest. Runtime, visual, accessibility, build, and static evidence remain separate. Retention requires a second distinct production theme change by the same team within 45 days without founder operation.

Run this as a paid concierge study before building a theme product: offer at most ten 30-day pilot slots at a fixed $1,500 scope (one token repository, up to three modes, 25 critical stories, and two apps). Ask for a real order rather than a pricing opinion. The experiment clock starts only after an owner explicitly approves outbound recruitment. During its first 42 days, make at most 40 individually researched invitations to maintainers who appear to meet the qualification criteria; do not bulk-message or post on their behalf.

Record one immutable funnel row per organization: invited means a named maintainer received the bounded offer; qualified means the maintainer confirmed all criteria above; enrolled means the scope and kickoff were accepted; paid means the $1,500 order cleared; VTR means activation met the definition above; repeat means a second production release met it within 45 days; and renewed means any paid continuation was ordered within 45 days after the pilot. Every paid pilot remains in the repeat and renewal denominators, including pilots that do not activate. Coverage is calculated across the 25 critical stories each paid team declares at kickoff: the numerator is stories that the static graph can classify as impacted or not impacted for the release, and unknown stories stay in the denominator. Report both per-team coverage and the aggregate story-release numerator and denominator; never discard failed pilots.

After a VTR, test $199/month per protected library for a team offer and $599/month for longer evidence retention and approval policy. These are willingness-to-pay experiments, not published plans. Stop recruitment on day 42 and finish already-paid 30-day pilots plus their 45-day repeat/renewal window; do not extend the clock because results are weak.

Kill or reduce this adjacency to an open policy/receipt module if, after 40 invitation attempts or day 42 (whichever comes first), fewer than three pilots pay; if fewer than two of all paid pilots renew; if fewer than five of all paid pilots complete a second real release; if aggregate static mapping covers less than 70% of declared story-release pairs; or if seven of the first ten qualified teams demonstrate that their existing package CI plus token/visual tools already solves the job. Failure to recruit or qualify enough teams by the deadline is a negative result, not permission to defer the decision. Do not build Figma sync, a token marketplace, visual regression, generic transformations, enterprise administration, or AI theme creation from interview compliments. DTCG import, token dependency graphs, and signed release evidence become candidates only after repeated real-release proof.

The appropriate conclusion is “there is a sufficiently large adjacent ecosystem to recruit a focused sample,” not “the market is 20 million users.” Refresh all dynamic snapshots before external publication.

Concrete pain evidence to investigate

Public questions and issue reports show recurring classes of friction. They are useful prompts for interviews, not prevalence estimates, endorsements, roadmap commitments, or proof that the reporter would adopt Compify.

Storybook authoring, discovery, and scale

• storybookjs/storybook#7711 asks to filter and search components by tag: discovery becomes harder as a catalog grows.
• #22922 reports the Story Source addon not showing the whole story in Storybook 7.x: displayed examples are not always equivalent to reviewable canonical source.
• #9828 asks whether CSF stories can be generated dynamically: real repositories exceed a purely static model, directly testing Compify's intentional non-execution boundary.
• #4784 requests versioned component documentation: consumers need provenance and change/version context, not merely a current preview.
• #6408 reports a build-storybook heap-out-of-memory failure: large-catalog build cost can make “just publish another Storybook” an incomplete distribution answer.

These reports span years and versions; an old or closed issue may no longer reproduce. Interviews must ask about the current repository and current version. Compify does not claim to solve Storybook search, docs versioning, or build memory; the issues only motivate testing a smaller explicit-export job.

Registry consumption, monorepos, metadata, and trust

Recent shadcn issue reports expose seams that any registry-producing workflow must respect:

• shadcn-ui/ui#10055 reports MCP failing to discover components.json in monorepo subdirectories.
• #10496 reports the CLI overriding the configured style for third-party registries.
• #10689 reports a registry build pipeline ignoring dependency and development-dependency metadata.
• #11002 reports add --diff / --dry-run previewing incorrect aliases for cross-workspace monorepo files.
• #7775, #7891, and #8323 ask about or report private registry authentication, authenticated registry dependencies, and private registry URLs through MCP.

These issues argue for testing actual destinations, aliases, dependency metadata, dry-run/review behavior, and private authentication. They do not establish that Compify's current output works around upstream defects. Record the shadcn CLI version and client in every pilot rather than claiming universal compatibility.

Cross-project component sharing

Two Stack Overflow questions capture the job in users' own broad terms: “How to share react component across multiple projects?” and “What is the simplest way to share React components between projects?”. The Stack Exchange API reported 25,424 and 14,407 views respectively on 2026-08-07 (API snapshot 71356016, API snapshot 52956271). Views are cumulative, dated, affected by search traffic, and not evidence that readers use Storybook, prefer source copying, or want Compify.

Target profiles and jobs to be done

Primary: React design-system maintainer

Qualifying shape: owns a Storybook-backed React library; supports two or more applications or workspaces; reviews component source; has repeated requests for one-off adoption; and is willing to name an approved distribution boundary. Likely environments include a monorepo design-system package or an internal component repository consumed by several product teams.

Job: “When an application team asks for one supported component, let me turn the source already represented in Storybook into an inspectable, approved artifact, so they can adopt and own the source without my team creating a second manual distribution workflow.”

Success evidence: can identify the last real handoff, select the source without consulting Compify staff, review every included file/dependency, and approve a second component later. Curiosity about MCP or an addon alone does not qualify.

Primary user: consuming application engineer

Qualifying shape: works in a React application already using or willing to use the shadcn CLI; needs to customize source rather than consume an opaque compiled package; and can test the installed result in a destination different from the source library.

Job: “When I need a house component, give me the reviewed implementation and its declared dependencies through a familiar source-install workflow, so I do not copy from rendered docs, reconstruct imports, or wait for a library release.”

Success evidence: understands that copied source transfers maintenance to the consumer, reviews the diff, and gets the component running without undocumented maintainer intervention.

Gatekeeper: platform, security, or developer-experience engineer

Qualifying shape: controls CI, credentials, source publication, monorepo conventions, or third-party tooling approval.

Job: “When maintainers distribute internal component source, give me a local, deterministic, non-executing inspection and an auditable artifact boundary, so I can evaluate exposure and automate policy without executing arbitrary stories.”

Success evidence: can explain included files, credential scope, failure modes, and provenance; approves a bounded pilot rather than merely tolerating a demo.

Secondary: agent-heavy application team

Qualifying shape: already uses Storybook or shadcn agent tooling for a concrete workflow, not just experimentation.

Job: “When an agent needs upstream context and an approved implementation, let Storybook MCP explain the component and registry tooling install the reviewed artifact, without confusing context retrieval with source authorization.”

This is secondary until human-driven inspect/export/install retention is shown. Teams without Storybook, non-React renderer teams, teams needing arbitrary dynamic story execution, and teams satisfied by a compiled package are not the first cohort.

Competitive and complementary boundaries

Adoption and trust blockers

1. Source exposure: static text can still include proprietary code, unnoticed credentials, customer data, or unintended transitive files. A parser's non-execution property reduces one risk; it does not make publication safe.
2. Fidelity: decorators, loaders, globals, CSS/build aliases, assets, dynamic imports, and generated stories may be necessary for the real component. A successful static inspection is not visual or behavioral equivalence.
3. Dependency and path correctness: monorepo aliases, peer dependencies, styles, registry dependencies, and consumer-specific configuration can make a schema-valid artifact fail after installation.
4. Private-registry authentication: token transport, MCP client behavior, transitive private dependencies, revocation, and logs must survive a real security review; upstream issues show this cannot be assumed.
5. Ownership after copying: consumers may expect package-like upgrades or support while maintainers intend a fork. Provenance, change policy, and the point where ownership transfers must be explicit.
6. Artifact review burden: if maintainers cannot easily see why every file and dependency is included, deterministic output alone will not create trust.
7. Workflow authority: teams may not accept a Storybook story as the right selection surface, or may require design, accessibility, and legal approval elsewhere.
8. MCP category confusion: context retrieval is not authorization to publish or install. Compify should coexist with, not impersonate, Storybook MCP.
9. Operational confidence: current-source build/setup, version compatibility, lack of a proven hosted service, and concern about vendor longevity may block pilots before product value is tested.

Anti-goals for this wedge

• Replacing Storybook, Chromatic, design tools, visual regression, or component tests.
• Executing stories or promising conversion of arbitrary dynamic CSF/runtime state.
• Becoming a general-purpose package manager, design-system portal, UI generator, public marketplace, or source-code crawler.
• Supporting every Storybook renderer or every asset/build system before React demand and retention are demonstrated.
• Treating addon metadata, stars, downloads, page views, issue counts, exports, or generated artifacts as activated teams.
• Publishing source automatically or hiding included files, dependency metadata, provenance, diagnostics, or the native registry artifact.
• Claiming current shadcn, MCP, private-auth, or monorepo compatibility without a pinned end-to-end test in the target environment.

Validation interviews

Recruit against the qualifying shapes above. Ask for a screen share of the last real event before showing Compify. Separate the maintainer, consumer, and security answers when they are different people.

1. “Tell me about the last component moved from this library into another application. What triggered it, and when was it?”
2. “Show me the exact source, story, docs page, ticket, or message where the handoff began. Which one is canonical?”
3. “What did each person do from request to working component? How long did each step take, and what had to be corrected?”
4. “Why was it copied rather than consumed as a package? Who owns fixes and upstream changes afterward?”
5. “How often did this happen in the last six months, across how many destination applications and distinct components?”
6. “What do Storybook, Chromatic, your package pipeline, or a registry already solve? Where exactly do they stop?”
7. “Which decorators, globals, styles, assets, aliases, generated stories, or runtime data does this example depend on?”
8. “Before source may leave this repository, who approves it and what evidence do they require? Which files must never be included?”
9. “Show me a recent install or copy diff. How were dependencies, paths, tokens, and private registry access handled?”
10. “If static inspection rejects this example rather than executing it, what would you change, and at what point would the restriction make the tool unusable?”
11. “Which alternative would you use tomorrow if this did not exist? What would make that alternative clearly better?”
12. “After installing the first component, what event would cause you to return for a second one within 30 days?”
13. “What would make you uninstall this, fail security review, or tell another team not to use it?”
14. “Would Storybook MCP, registry MCP, or neither participate in this workflow? What authority do you believe each has?”

Avoid “Would you use this?” and pricing hypotheticals until the respondent has shown a recurring event. Strong evidence is observed repository work, a reviewed artifact, a separate destination install, and voluntary second-component use.

Falsification tests

Stop, narrow, or reposition the wedge if any of these hold after recruiting the specified cohort:

1. No recurring handoff: fewer than 8 of 15 qualified interviews report copying or repackaging Storybook-backed components across applications at least quarterly and cannot show a recent example.
2. No incremental value: fewer than 5 of 10 activated teams export a second distinct component within 30 days.
3. Static boundary is too narrow: fewer than 60% of intentionally selected story fixtures in pilot repositories inspect successfully, or maintainers reject the required simplifications.
4. Review cost dominates: median time from first inspect to accepted artifact exceeds 30 minutes after onboarding.
5. Existing alternative wins: at least 70% of qualified teams say and demonstrate that direct registry authoring or a component library solves the job with no meaningful recurring pain.
6. Destination reliability fails: fewer than 70% of accepted artifacts install and run in a separate target application without undocumented manual repair.
7. MCP confusion persists: more than 20% of activated users believe Compify replaces Storybook MCP after onboarding and documentation revisions.
8. Security objection blocks adoption: 3 or more of 10 security reviews reject local static parsing even when no story code is executed.

Record repository shape, versions, selection rationale, and unsupported syntax for every failure; do not inflate success by silently excluding difficult pilot components.

North star and 90-day scorecard

The hard activation event is a Verified Cross-App Handoff (VCH): an intentional Storybook selection from a non-demo library produces a reviewed digest, the native pinned shadcn client installs it into a different repository, and that destination's declared typecheck/build exits successfully. A local receipt records the inputs, hashes, exact argument vectors, changed files, and result without sending telemetry. The rollup north star is Weekly Activated Libraries (WAL): distinct external source libraries with at least one VCH in a rolling seven-day window. Count a library once per week; exclude employees, templates, CI retries, and repeated installation of the same digest.

Track Weekly Activated Storybooks (WAS) as the Storybook-specific diagnostic: distinct Storybook projects satisfying those same three events. WAL remains the broader north star if one library contains multiple Storybooks; WAS reveals whether the claimed wedge actually supplies activation. Neither metric exists as shipped telemetry merely because it is specified here. Use consented event data and a single identity/event dictionary.

Interview every activated and abandoned pilot. At day 45, prioritize the top two unsupported patterns only if each occurs across at least three qualified teams. At day 90, continue only if second-component use and cross-application installs both meet target; ecosystem size and top-of-funnel interest are insufficient.

Source and review discipline

All counts above were captured on 2026-08-07 from the directly linked first-party repository, npm API, Storybook sitemap/docs, shadcn docs/issues, Stack Exchange API, vendor sites, or product sites. Issue titles and current product behavior can change; issue existence does not mean the behavior is current. The addon sitemap method counts <loc> elements and subtracts the /addons index for the detail URL estimate. npm “last-week” responses identify their own 2026-07-31 to 2026-08-06 window.

For the next review, save the response date/window and methodology, re-open every source, pin tested Storybook/shadcn/client versions, and distinguish observed pilot behavior from public proxy metrics. Do not convert downloads, stars, forks, URLs, views, questions, or issues into unique-user, revenue, or demand claims.