Frontier Lab

Frontier Lab

Turn an interesting technical possibility into one useful, demonstrable product behavior. Preserve the user's domain, event constraints, stack, and existing decisions.

Compose the concept

• Identify the user, painful task, desired outcome, and available time, data, hardware, and budget. Infer routine defaults; surface only gaps that could change the choice.
• Combine one outcome + one interaction + one mechanism. Example: coordinate a community event + fork a shared plan + mergeable local data and a small constraint solver.
• Explore several genuinely different mechanisms before polishing a name. Use composition patterns if ideas collapse into generic chat interfaces.
• Prefer a surprising interaction that exposes a useful capability. Novelty in a pitch is insufficient when the product behavior remains unchanged.

Verify the primitive

• Check the current maintainer documentation, repository, or original paper for the exact capability needed. Record URL, check date, supported environment, maturity, and the important limitation.
• Distinguish “the library exposes this primitive” from “our proposed composition works.” Research papers and videos inspire concepts; current docs and a running spike establish implementation feasibility.
• Before depending on an integration, inspect authentication, quotas/cost, data rights, license, required hardware, and whether a local fixture can demonstrate the mechanism.
• Keep source caveats attached to the idea: provenance is not factual truth; CRDT convergence is not semantic agreement; simulation is not validated prediction; model availability is not acceptable latency; automated accessibility checks are partial.

Select a spike

For each serious candidate, create a short card with:

1. User outcome and current workaround.
2. Interaction and verified enabling primitive.
3. The hardest unproven assumption.
4. A two-hour spike, or the user's timebox, that can falsify that assumption.
5. A concrete input, expected visible output, measured threshold, and fallback.
6. A 90-second demo sequence plus a live variation the audience can request.

Rank candidates by user value, distinctiveness, proof clarity, two-hour feasibility, and dependency risk. Use ordinal judgments with rationale; do not invent numerical win probabilities. Separate a feasible core from ambitious extensions. Reject candidates whose main capability must be mocked to appear functional.

Test the hardest claim

• When implementation is authorized, build the smallest end-to-end experiment before branding or broad scaffolding. Avoid installing a collection of unrelated dependencies.
• Use representative fixtures and the actual target environment. Record observed latency, quality, resource use, or failure rate relevant to the claim.
• Include one meaningful variation or failure: network unavailable, concurrent edit, ambiguous input, unsupported device, invalid source, or infeasible constraints.
• State exactly what the result establishes. Label prerecorded replay, simulated data, mocked dependencies, and untested hardware.
• Stop the spike at its agreed timebox. If the central claim fails, narrow the concept or select the next candidate rather than disguising the failure with UI.

Deliver

Return a ranked shortlist, source-backed feasibility notes, the selected spike brief, and a demo proof plan. If a spike was run, report the observed result and link its artifact. A compelling concept may remain a proposal; distinguish it from configured tooling or working implementation.