iFixit

01 · A missing part, a working device. Open a separate demo or create an empty workbench. Independent student project.
02 · Save your private access file. Whoever holds it can manage the workbench; there is no email recovery.
03 · Three fictional repair requests and three example offers. Each demo visitor gets a separate server-backed workbench.
04 · One request per diagnosed part: exact model, part reference, specification, repair purpose and general collection area.
05 · Share the public request. Required part details are visible; private workbench keys and offers remain separate.
06 · Donors transcribe their own part labels and condition. Matching feedback does not certify compatibility or safety.
07 · A separate donor receipt tracks status, withdrawal and handover. The displayed code belongs to this fictional example.
08 · Matching labels still require technician inspection, written notes and suitability confirmation before reservation.
09 · A DDR3 offer conflicts with the DDR4 request. Mismatched or incomplete labels block reservation on the server.
10 · Reserve one offer for 48 hours. Record collection with the donor’s code, or release the reservation if plans change.
11 · Record a test and device-owner confirmation before counting a repair. This example result is explicitly simulated.
12 · One simulated outcome, clearly labeled. Offers and handovers never become fabricated impact or carbon-saving totals.
13 · Primary-source repair research, a narrow coordination gap and a realistic pilot. Local interviews remain pending.
14 · Coordinator controls cover retention, private access files, key rotation and record export. Bearer-access limits are explicit.
15 · Privacy explains public fields, separate access, storage, retention and the limits of coordinator-reported evidence.

The specific problem, and how we know it is real

A diagnosed repair can stall because the correct spare part is unavailable or too expensive. Meanwhile, someone nearby may hold a useful spare without knowing who needs it. iFixit / local explores a narrow way to connect that supply with a clearly specified repair and follow it through to a recorded outcome.

The Open Repair Alliance's 2024 analysis reports unavailable parts in 25% of recorded repair barriers and expensive parts in 18%. These are findings from its community repair dataset, not measurements of our neighborhood. Restarters' spare-parts guidance also describes model-specific assemblies, uncertain used-part condition and mislabeled parts. That evidence shaped our focus on exact labels, technician inspection and a complete handover record.

Local firsthand evidence is still pending creator review. We have not invented a repair-shop interview, donor network, physical repair or beneficiary result. The next step is a consent-based conversation with one local repairer about actual jobs waiting for parts. This gap matters because local relevance is central to Neighborhood Hacks.

What iFixit / local does

iFixit / local gives a repair shop or school repair club a small coordinator workbench. The coordinator records a diagnosis, the device model and revision, exact part reference, specification, purpose and general staffed collection area. One request is for one part.

A public request link lets a donor transcribe the labels from their own part, describe its condition and submit an offer. The donor receives a separate private receipt. The coordinator sees which fields match, differ or remain unknown. A mismatch or missing detail blocks reservation, including direct API attempts.

Matching labels are only a candidate. The coordinator must record an actual inspection and confirm suitability before reserving a part for 48 hours. When the part is physically received, a code from the donor's private receipt and receipt notes record the handover. The technician then records what was tested. A successful outcome also requires the device owner's confirmation.

Donors can withdraw pending or reserved offers. Coordinators can release a reservation, close an unfilled request or reopen an unsuccessful repair. Expired reservations reopen automatically. Offers and handovers never count as successful repairs.

A realistic model

The initial pilot is one willing repair desk, ten diagnosed computer repairs and an existing local donor network. Memory, keyboards, cooling fans and hinges keep the first version bounded. Batteries, power supplies, medical equipment and safety-critical repairs are outside the pilot. The website does not diagnose faults, certify hardware or ask donors to dismantle devices.

The coordinator handles collection during existing repair sessions. A donor without a smartphone participates through the desk. The pilot needs no payments, shipping, paid AI API or marketplace business model. Its constraints are technician time, correct donor supply and reliable collection.

We would measure time to a usable inspected offer, mismatch rates, completed handovers, confirmed repairs and unresolved cases. We would baseline the repairer's current workflow first. We do not infer carbon savings or kilograms of avoided waste from offer counts.

How we built it

React and JavaScript render the app. Vercel serves the public vercel.app URL through a fixed proxy to the Cloudflare Worker app and API. A dedicated Cloudflare D1 database persists workbenches, repair records and rate limits. Zod validates server inputs, esbuild bundles the code, Lucide provides icons and native system fonts keep the English-only interface lightweight. Better Design iOS references and Lumen glass and spacing tokens informed the minimal glossy design. There are no external runtime font or analytics calls.

Coordinator and donor access use separate random capability keys. Server records store key hashes. Public request pages omit offers, donor aliases, receipt keys and inspection history. Real donor receipt keys and handover codes are omitted from coordinator reads. Private access files let users return on another device, and Settings & access supports owner-only key rotation, workbench renaming, retention renewal and active-database deletion. Previous coordinator keys stop working after rotation. There is no email recovery in this pilot. Browser local storage is not encrypted.

Prepared SQLite statements bind user input. Revision-based updates reject stale or concurrent writes rather than silently overwriting an offer. The API rejects cross-origin writes, invalid schemas and oversized JSON. Rate limits, pilot caps, restrictive browser security headers and expiry bound the service. Demo workbenches expire after seven days and real pilot workbenches after thirty days unless renewed by the owner, with daily application cleanup. Hosting backup retention may extend beyond that cleanup.

What is distinctive

Parts marketplaces and community repair platforms already exist. The established company iFixit provides parts and repair information. This independent student project is not affiliated with iFixit, Inc. Restarters supports community repair, sourcing guidance and recorded outcomes. We do not claim to be the first or only parts-matching tool.

Our chosen focus is the small diagnosed-request to donor-offer to technician-check to private-handover-receipt to repair-result workflow. The field comparison preserves uncertainty, the receipt separates donor and coordinator access, and unsuccessful outcomes remain visible. Its value is a clearer local process, which still needs a real pilot to validate.

Challenges and what we learned

The difficult part was deciding what the software should refuse to conclude. Exact text does not establish a safe fit. A donation does not establish a repair. A handover code does not establish identity or physical delivery independently. We built explicit human checks and described their limits.

Separate access roles and concurrent updates also mattered. A donor must not gain coordinator authority, and a new offer must not disappear when another window saves. Tests cover those boundaries. Separating server validation from browser code kept server validation out of the browser bundle. Mobile review also prompted larger secondary labels and a stacked part comparison.

Validation and accessibility

All 16 automated domain/API tests pass, including owner-management isolation, key rotation, typed deletion, retention renewal and the explicit proxy-origin boundary. They cover mismatch and unknown-field blocking, inspection requirements, wrong codes, owner-confirmation gates, expired reservations, failed outcomes, cross-workbench access, private receipts, withdrawal, stale revisions, input validation, SQL parameter safety, rate limits and cleanup. The dependency audit reported zero known vulnerabilities at review time.

The live Vercel walkthrough created an empty private workbench, saved a clearly marked fictional QA request, submitted an offer from the public donor form, reviewed the label comparison, reserved the fictional part after recorded inspection, used the separate donor receipt code for handover and saved a tested QA outcome. The Outcomes page counted that outcome. These are software tests, not physical repairs. Real users start empty. Choose Open demo workbench on the landing page to create a separate server-backed example session with three fictional requests and three offers. The demo includes a label match, a mismatch and incomplete details; its outcomes never count as real impact.

The layout uses native labeled forms, keyboard focus, responsive navigation, text alongside status colors, an English-only interface, reduced-motion support and iOS-style glass on navigation and temporary surfaces. A 390px browser frame has no horizontal overflow. Physical-phone and assistive-technology sessions, a local pilot, heavy-load testing and an exhaustive security audit are still outstanding. Software checks do not guarantee a judging score.

What we would do next

Interview one willing local repairer, document real part-waiting cases with consent and run the bounded pilot. Learn where donors misread labels and where collection fails. Improve language support and recovery before scaling. Add inventory and independent owner confirmation only if the pilot demonstrates a need.

AI and third-party disclosure

Original application code, test fixtures and documentation were created during the event with ChatGPT/Codex assistance for research, coding, design and review. Open-source dependencies are credited in the public repository. AI is not used to guess compatibility or required to operate the app. QA cases and part references are explicitly fictional. The edited walkthrough uses actual working-website captures, Hyperframes composition and local Kokoro synthetic narration. Gallery images are actual browser captures; the separate project thumbnail is AI-generated.

Sources: Open Repair Alliance supporting data, Restarters spare-parts guidance, Restarters impact records, iFixit parts.

More: Research and pilot plan, Product and technical specification, Validation evidence.