Micro Club / Independent research / September 2026

PointCast Micro Club V2

Product requirements for a home for Micro owners

Product, design, engineering, QA and community operations. Research snapshot: September 29, 2026, America/Los_Angeles. All target requirements, thresholds and commercial plans are proposals; local prototype scope is explicitly identified.

Inside this edition

  1. Earn the owner relationship through play
  2. Three games, three tactile reasons to play
  3. Reliability before accounts; identity before a feed
  4. A small backend with explicit trust boundaries
  5. Make “Micro tested” an earned label
  6. Use a small pilot to decide what deserves to grow
  7. Sources and reading notes
01 / Decision and product strategy

Earn the owner relationship through play

Build a small, reliable destination that makes a Micro immediately satisfying: get the controls working, play a distinctive short game, then keep or share something worth returning to. “Number one destination” is an ambition, not an evidenced market position.

Problem and evidence

Owners can already remap controls: Work Louder documents six layers and app-linked switching; Elgato and Logitech also maintain customization ecosystems [H02] [H08] [H10]. PointCast must add a compelling play collection and trustworthy setup evidence.

Codex Micro is currently listed as sold out [H01]. Compatibility questions appear in individual owner reports [H12] [E05], which are useful design signals but not prevalence data. Start with existing owners and preserve ordinary keyboard/touch access.

Jobs and target sequence

Scope and status

Local V2 prototype scope Production target - proposed
Three new games; seeded replay/challenge URLs; local personal bests Existing PointCast authentication after repository audit; optional account after play
Mapped keyboard and touch controls; physical HID/RGB unproven Versioned compatibility recipes, physical device QA and support ownership
V1 Signal Run, Pocket Echo and Bloom Room preserved Saved profiles, challenges and curated presets with reporting/deletion

Deliberate boundaries

No mandatory wallet, hardware purchase, public feed, direct messages, creator payout marketplace, native HID bridge or LED-control promise in this release. Do not present a local passport as registration or a local best as a global rank.

02 / Game specifications

Three games, three tactile reasons to play

The V2 collection uses discrete semantic actions so a dial, joystick, ordinary keyboard or touch surface can reach the same game rules. Seeds reproduce content; they do not prove score integrity.

Dial In - precision

A 60-second run with five frequency locks. Previous/next actions move the tuner; the action key attempts a lock. A Micro dial maps to previous/next, with buttons and keyboard fallback.

Switchboard - deliberate puzzle play

Solve three 4×4 pipe boards. Joystick directions select a tile; rotate changes its orientation. Hints deduct 70 points. Touch selection and rotate controls remain available.

Pulse Club - rhythm

A 30-second, four-pad procedural rhythm round. Provide latency correction from -150 to +150 ms, explicit sound start/mute controls and visual timing cues.

Shared acceptance

All three support start, restart, clear end state, local best and seed-sharing. Label scores “local” or “unverified.” Share links carry game/version/seed, never account secrets. Preserve V1 navigation and saved data; a failed storage write must not prevent play.

03 / Priorities and acceptance criteria

Reliability before accounts; identity before a feed

P0 is the required release behavior. P1 follows successful physical-device and return-play pilots. This page specifies target acceptance; it is not a claim that the public backend already exists.

P0 / Play and onboarding

P0 / Public-launch prerequisites - proposed

P1 / Retention and contribution

04 / Proposed production design

A small backend with explicit trust boundaries

These data and endpoint contracts are proposed, not implemented. Confirm names and integration points in the PointCast repository audit; extend existing services rather than introducing a parallel identity stack.

Minimal data model

Record Essential fields
Profile Existing user ID; handle; visibility; self-declared device; created/deleted timestamps
Run ID; user or anonymous session; game/version/seed; score summary; timing; validation class
Challenge ID; game/version/seed; creator; optional public result; expiry/visibility
Preset ID; author; versioned mappings; device/OS/Input versions; license; moderation status
Report ID; reporter; target/type; reason; status; reviewer audit timestamps

Endpoint contracts

Proposed route Contract
POST /micro/runs/start Return server run ID, seed/version and expiry; rate-limit anonymous starts.
POST /micro/runs/:id/finish Accept bounded result summary once; return validation class. Reject foreign, expired or duplicate runs.
GET/PATCH /micro/profile Read permitted fields; authenticate writes; enforce handle rules and visibility.
POST/GET /micro/challenges Create/read a bounded seed challenge; private reads require authorization.
POST /micro/presets and /micro/reports Validate schema, authenticate submissions and queue public content for review.
DELETE /micro/profile Authenticate, revoke access and apply the documented content/data deletion policy.

Integrity and privacy

Use validation classes local-only, submitted-unverified and server-verified. A seed or signed start token alone does not verify a score. Until a game-specific validator exists, exclude submitted results from competitive ranking.

Collect semantic product events and bounded score summaries, never raw keystrokes, OS input streams or device serial numbers. Any future replay validator must specify minimal semantic game actions and retention separately.

Proposed pilot retention: delete anonymous event-level data after 30 days; keep nonidentifying aggregates. Account-linked saves persist until deletion under the published policy. Document cookies/local storage and applicable consent behavior before public launch.

05 / Setup, quality and release gates

Make “Micro tested” an earned label

Vendor mapping guidance proves available configuration features [H02] [H03] [H04]. It does not prove these browser games work on every firmware, transport or browser. Publish tested combinations with dates, not a blanket compatibility claim.

Onboarding path

Choose device → select an unused game layer → map the common actions → test each control → complete one round → optionally save or share. Show how to switch back before changing mappings. Link vendor support for hardware/firmware issues; do not prescribe destructive resets.

Physical QA matrix - proposed

Dimension Required coverage / evidence
Device Codex Micro; Creator Micro 2 Base and Pro kept distinct; ordinary keyboard fallback
Transport USB on each device; Bluetooth on supported models only
Desktop Current stable macOS/Windows; Chromium plus Safari on Mac and Firefox; label combinations actually tested
Input/firmware Record exact versions, app focus, layer and mapping; test with common monitoring conflicts present/absent
Controls Dial both directions; four joystick directions; each pad; repeat/hold; blur/reconnect; restore original workflow
Fallback/accessibility 390 px touch, keyboard-only, muted, reduced motion, blocked local storage and malformed share link

Milestones and accountable roles

Milestone Owner / exit evidence
M0 - local collection Game engineer + designer: three game loops, preserved V1, reproducible seeds and browser QA
M1 - device pilot QA lead + support editor: 12 observed owners; dated compatibility recipes and restore evidence
M2 - private identity pilot Platform engineer + community lead: auth audit, authorization tests, deletion/report workflows
M3 - public beta Product lead: pilot gate review; privacy text, support coverage and rollback plan
M4 - creator drop Editorial lead: approved budget, license, QA and attribution for each contribution

Stop conditions

Do not claim hardware support if required controls fail or restoration is unreliable. Do not open public contributions without report/removal coverage. Hold release for cross-account data access, unrecoverable saves, scoring after completion or broken V1 routes.

06 / Measurement and commercial hypotheses

Use a small pilot to decide what deserves to grow

Thresholds are internal provisional rules, not industry benchmarks. Exclude team/test traffic; report recruitment and cohort sizes. Assess retention after all 30 activated owners complete follow-up through day 8.

Measurement definitions

Metric Numerator / denominator / cohort
Activation Unique setup starters completing a round ÷ unique setup starters; split by device and entry path
Setup success Uncoached owners completing setup + one round in <3 min ÷ 12 observed owners; timer starts on setup entry
D7-window retention Activated owners completing a session on days 6-8 ÷ 30 activated owners; first completion is day 0; cohort timezone recorded
Share utility Unique recipients completing a shared seed ÷ 20 unique non-team recipients explicitly sent a challenge; also report landing-to-play conversion
Creator delivery Invited creators delivering a QA-approved experience within budget ÷ 3 invited creators

Proposed go / no-go

Commercial and resource hypotheses

Keep setup, tester and one game free. Test a finite $12 collection; separate interest, checkout starts and orders. Adjacent prices do not establish Micro demand [E07] [E10].

Illustrative only: $12 less an assumed 15% variable deduction yields $10.20 contribution; a hypothetical $1,500 content/QA budget needs 148 sales, excluding tax and ongoing overhead. Replace assumptions with actuals before spending. Scope: three games, shared input, support and a 14-day pilot. Agree effort/rates separately; payouts, subscriptions and broad networking are deferred.

Evidence / primary sources

Sources and reading notes