BitShovel.One real problem at a time
Open the current workflowCurrent Workflow中文

One real problem at a time

中文

HISTORICAL DIG · JUL—AUG 2026

Which format should I build first for an AI product?

A first version is often started in the most familiar tool or the format that looks most complete. Only later does the real constraint emerge: how the user enters, which device capability the core action needs, whether platform identity or distribution is essential, and which step must happen on a real device.

First recorded · Last public revision · Revision 2
Core actionTarget deviceRequired capabilityEntry & distributionDevice result

HOW IT RELATES TO WORKFLOW 001

Relation to the current subject

It changes “which tool builds apps best?” into “which surface does this task path require?”

Workflow 001 chooses a working setup from the deliverable, runtime, cost, and permission boundary. This historical record applies the same logic to product surfaces: define the core action and target device before choosing web, mini app, native app, or game runtime. It connects directly to Q01 runtime location and to post-generation interface and delivery checks.

Record state at the time

  • AI product prototype
  • First product surface
  • Standard record
  • Developing
  • Historical E2 · three maker examples and two platform references · no same-task cross-platform run

THE GUIDANCE AT THE TIME

Judgment at the time

There is no default surface: freeze the action, eliminate by requirement, then complete once on a real device.

Open full rationale and return rules
Do not choose a product category first. Freeze one entry–action–visible-result contract, then name the target user and device, required hardware, identity and sharing relationships, offline or background needs, and review or payment boundaries. Eliminate surfaces that cannot satisfy a named requirement, then choose the lowest-commitment surface that can complete the path on the target device. Simulators and screenshots inspect layout; the decision requires one real-device path. Web, mini app, native app, and game runtime are all options—not defaults.
Who it was for
Individuals and small teams who can name one concrete user action but keep switching among web, mini-app, native-app, and game-runtime tooling
Why it mattered then
Open note

An oversized surface introduces accounts, review, signing, permissions, compatibility, and maintenance before the core action is established. An undersized one can hide required device capability or platform relationships until the end. Both replace “can the action complete once?” with “how much interface did we build?”

Where the judgment stops
Open note

Fly Pieter is a maker account; its revenue or reach claims cannot establish that the web caused success. SpookSeek's store page shows device, OS, and distribution constraints, while its privacy information is developer-declared and not verified by Apple. MobileReady provides simulation and preview, not real-device validation. MDN and Apple documentation explain capability, permission, and review mechanisms; they do not establish compatibility, privacy, approval rates, or user outcomes for a product. BitShovel has not rebuilt the same core action in four surfaces or measured external-user results.

CHECK BEFORE READING ON

Fit check

Run the preflight only when one user action and one visible result can be named.

This record may help

  • You can write one sentence naming one user, one entry point, one action, and one visible result.
  • You are willing to use fixed demo data and complete one target-device path before building a full backend or opening store accounts.

Do not use it yet when

  • The core action is still “build an AI product,” “make a community,” or “create a platform,” with no observable result.
  • The first pass would require real payments, production accounts, sensitive data, or irreversible permissions.
  • You intend to use screenshots or a simulator as proof that camera, background, offline, sharing, or store distribution works.

HISTORICAL TRIAL · ONE FIXED DEMO PATH

Historical trial

Spend 45–90 minutes writing constraints, eliminating surfaces, and recording entry-to-result on one target device.

Time needed
45–90 minutes: 20 minutes for constraints, then 25–70 for one fixed demo path; stop at the cap
Likely cost
No paid template, developer account, store service, or real model call in the first pass
Permission boundary
Use fixed demo data only; do not request camera, contacts, location, payment, production identity, or persistent background access by default
  1. 01

    First step

    Open this step

    Write one entry–action–visible-result contract and list five constraint groups: target device, required capability, identity/sharing, offline/background, and review/payment. Give web, mini app, native app, and game runtime one row each, eliminating any surface that fails a required condition. Build one fixed demo path in the lowest-commitment survivor, then record entry, permission prompts, visible completion, and failure points on one target device.

  2. 02

    What should exist

    Open this step

    One surface-elimination sheet, one fixed demo path, one real-device result record, and one reversible continue-or-switch decision.

  3. 03

    How to tell it worked

    Open this step

    The target device can move from the agreed entry point to the visible result, and every rejected surface maps to a named constraint rather than preference. This establishes only that one demo path is viable—not user demand, store approval, maintainability at scale, or business results.

  4. 04

    Stop when

    Open this step

    Stop if the core action remains unclear, the only differences are aesthetic, a simulator is being treated as a device result, or continuing requires a store account, real payment, production identity, sensitive data, or consequential permission.

  5. 05

    How to back out

    Open this step

    Keep the interaction contract, constraint sheet, and device record; remove platform scaffolding and demo credentials, revoke trial permissions, and return to the lowest-commitment surface that still satisfies every required condition.

BITSHOVEL R2 EXPLAINER · FIXED FICTIONAL DATA

Method and interfaces

The sample removes unnecessary platform commitments before sending the surviving route to a device gate.

Open method boundary

The task, data, device, and decisions in the diagram are fixed fictional material. It explains surface reasoning; it is not a running web, app, mini-app, or game screenshot and does not establish that the web route passed a device test.

Freeze the action, then eliminate surfacesBITSHOVEL R2 EXPLAINER · FIXED FICTIONAL DATA
Surface-selection gate for a fictional task, freezing a scan-to-share-card action before eliminating web, mini app, native app, and game runtime by capability, platform, background, and release constraints

The sample needs no store, background service, or game loop, so the web remains the first route. This is constraint reasoning—not a claim that the web is always better.

About this image and its source

BitShovel explainer created August 16, 2026. The task, device, data, states, and decision are fixed fictional examples with no real user, account, permission, payment, or run result.

Open source page ↗

SOURCES AND EVIDENCE

Sources and evidence

As of August 16, 2026, three maker cases and two capability/review references support separate entry, hardware, simulation, and distribution boundaries—not comparative format success rates.

Open evidence boundary

Historical E2 remains the label from the original record. Revision 2 returns the three examples to case signals and adds current capability and review documentation. Together they support writing constraints before choosing a surface, not a same-task comparison, format ranking, or product-success claim.

  1. 01
    Maker account · Current review

    Fly Pieter: a browser entry reduced install and update friction

    Open source boundary

    Only the maker's description of entry format is retained. Revenue, reach, and causal claims that the web produced success are excluded, and the flight experience is not generalized to ordinary products.

    Open original source ↗
  2. 02
    Store and device case · Current review

    SpookSeek AR: iPhone, camera, and store distribution are explicit constraints

    Open source boundary

    The App Store page supports device and distribution boundaries. Its privacy label is developer-declared and marked unverified by Apple, so it is not privacy, safety, adoption, or format-superiority evidence.

    Open original source ↗
  3. 03
    Maker preview tool · Current review

    MobileReady: multi-device frames are simulation and demo, not a device-completion record

    Open source boundary

    Maker material supports preview, capture, and demo. It does not establish camera, permission, performance, browser compatibility, or real-device flow. The prior publisher image is not redistributed in Revision 2.

    Open original source ↗
  4. 04
    Web capability reference · Current review

    MDN: web camera access requires a secure context, user permission, and supported input

    Open source boundary

    This shows that the web can access hardware under permission, context, device, and compatibility conditions. It does not establish that the sample path ran on a real device.

    Open original source ↗
  5. 05
    Native distribution reference · Current review

    Apple: App Store submission introduces review, metadata, account, hardware, and permission requirements

    Open source boundary

    This establishes additional commitments in native distribution. The guidelines evolve and do not guarantee approval, discovery, or a user outcome for any app.

    Open original source ↗

REVISION RECORD

Revision record

Revision 2 removes the “ordinary forms prefer the web” shortcut and replaces it with a stoppable, reversible elimination method.

Open 2 revisions
  1. Revision 1

    Changed the comparison from whole platforms to the device capability and entry needed for one core action.

  2. Revision 2

    Replaced “prefer the web for ordinary forms” with an executable elimination method: freeze the interaction contract and five constraint groups, choose the lowest-commitment viable surface, and require one real-device path.

    What the record said before
    List device capability and distribution entry first; prefer the web for ordinary forms and sharing, then use a mini app, native app, or game runtime when platform relationships or hardware are required.
    What changed
    Write one entry–action–visible-result contract and five constraint groups; no surface has automatic priority. Eliminate options that miss a required condition, choose the lowest-commitment survivor, and decide whether to continue from one target-device completion record—not a simulator or screenshot.

WHAT THIS RECORD LEAVES

What this record leaves

The first-version goal is not the most complete platform. It is one completed core action with the least commitment.

If no required condition explains why a surface was rejected, or only simulator screenshots exist, the surface decision has not been made.

Return to Dig index