StillWorks

• 

  Stillworks.

Inspiration

Second-hand listings compress condition into phrases like “everything works.” But buyers rarely need everything—they need one specific thing to work reliably. A controller may connect but drift during a racing game. A keyboard may type but miss the exact keys needed for play. A microphone may exist but fail to produce a usable voice signal.

We wanted trust to become a shared action at the moment of exchange, before money changes hands—not another seller rating, AI opinion, or vague promise.

StillWorks also addresses one small but practical source of electronic waste: uncertainty. People often keep or discard electronics because they do not know whether the device still fits someone else’s real need. We cannot solve e-waste with one app, but we can make one second-hand handoff more honest and easier to complete.

What it does

StillWorks turns one seller claim and one buyer need into a short, agreed test plan.

Both people see the criteria before testing. The device then answers through real browser signals:

• controllers through the Gamepad API;
• keyboards through browser keyboard events;
• microphones through local WebAudio RMS measurements;
• webcams through MediaDevices and sampled frame change.

The result is a bounded condition card containing only PASS, FAIL, and UNKNOWN.

A claim can decide which question to ask, but it can never decide the result. Unsupported claims—such as battery endurance, ownership, authenticity, safety, or long-range wireless performance—remain visibly UNKNOWN.

Everything happens locally in the browser. There is no account, backend, analytics, upload, API key, or runtime model verdict. Users can export the evidence as JSON if they choose.

For judges without matching hardware, StillWorks includes a prominently labelled recorded controller fixture demonstrating a real drift mismatch without pretending that the fixture is a live test.

How we built it

StillWorks was created during OpenAI Build Week using Codex with GPT-5.6 Sol.

Codex and GPT-5.6 materially shaped the full product—not just isolated code generation. We used them to:

• generate and compare product directions against the judging criteria;
• reduce the concept to one user moment and one clear promise;
• threat-model seller manipulation, unsupported claims, permission failures, misleading fixtures, and accidental over-certification;
• design the bounded test grammar and conservative evidence model;
• implement the interface, browser adapters, condition reducer, PWA shell, export flow, tests, and documentation;
• iterate on the visual hierarchy, mobile experience, demo narrative, release packaging, and judge path;
• perform clean-build, browser, security, and submission audits.

The application is built with Next.js, React, and TypeScript as a completely static production export. A deterministic planner selects only registered tests. Each test has a visible criterion and a browser adapter capable of producing evidence. The reducer then calculates the final state conservatively: observed failure dominates, missing evidence remains unknown, and only complete passing evidence becomes pass.

The most important architectural decision was where not to use a model. GPT-5.6 and Codex helped discover, design, attack, implement, and verify the system, but the runtime verdict comes only from inspectable code and browser-observed signals.

Challenges we ran into

The hardest challenge was representing the boundary of knowledge honestly.

It is easy to collect a signal and overstate what it proves. Detecting keyboard events does not establish battery life. A changing webcam frame does not establish image quality. A connected controller does not establish precise analogue return. We had to make every criterion narrow, visible, and traceable to a specific observation.

Browser APIs introduced another set of challenges. Device availability and permissions vary. Microphone and webcam work can finish asynchronously after a user aborts a test. Sequential keyboard diagnostics can accidentally share state. Held-key repeat needed a genuinely executable one-second requirement rather than explanatory text.

We also had to provide a useful judge fixture without misleading anyone. The fixture is therefore labelled at the top, in its evidence records, and in the condition-card footer.

Finally, we had to turn an evidence-heavy interface into a clear consumer story. The final design focuses on the human handoff first, then progressively reveals the claim, observable trace, and verdict.

Accomplishments that we're proud of

• Built a complete claim → shared plan → live test → condition-card product flow.
• Implemented four genuinely different browser-device adapters without a backend.
• Made UNKNOWN a first-class result instead of hiding missing evidence.
• Kept seller claims completely outside the runtime verdict.
• Created a reproducible no-extra-hardware judge path.
• Produced a static, local-first PWA that can be previewed without installing dependencies.
• Added downloadable, inspectable JSON evidence.
• Completed a responsive desktop and mobile product experience.
• Verified the release with 12 deterministic and integration tests, TypeScript, lint, production build, HTTP smoke testing, accessibility checks, release auditing, and a clean dependency audit with zero known vulnerabilities.

Most importantly, StillWorks does not claim to certify a device. It records exactly what one bounded handoff established—and nothing more.

What we learned

Trust software becomes stronger when it represents uncertainty as carefully as success.

UNKNOWN is not an incomplete result. It is often the most truthful result available. Preventing silence, missing permission, absent hardware, or an unsupported claim from becoming a false pass was more important than maximizing the number of green indicators.

We also learned that meaningful AI involvement does not require placing a language model inside every runtime decision. GPT-5.6 and Codex contributed most by helping us explore the problem, challenge assumptions, define the trust boundary, implement the mechanism, and verify the release. The final product became more trustworthy precisely because the sale-time verdict stayed deterministic.

What's next for StillWorks

The next version would calibrate thresholds using labelled device datasets and expand the library of deterministic adapters.

We also want to add:

• short-lived QR handoffs so two devices can join the same local test;
• more electronics categories with category-specific evidence boundaries;
• marketplace integrations that attach a bounded condition card to a listing;
• optional signing for evidence integrity without turning the card into a universal certificate;
• accessible guided modes for less technical buyers and sellers;
• reusable calibration profiles for different browser and hardware combinations.

The core rule will remain unchanged: a new category can ship only when it has a real observable adapter, explicit criteria, and an honest boundary around what it cannot establish.

Built With

• codex
• gpt