Core Return Desk: a working workflow that did not earn expansion

A narrow operational problem

Automotive repair shops sometimes pay a core deposit when buying a remanufactured part. The used part must be identified, returned to the supplier and matched to the eventual credit. A missed handoff or unmatched credit can leave money sitting between the parts shelf, a vendor statement and somebody's spreadsheet.

Core Return Desk modelled that job as a small local-first workflow. It tracked the physical core, shop tag, repair order, vendor, expected credit, return batch, slip and user-entered credit. It deliberately did not claim to know whether a supplier had accepted a return or issued money.

The useful question was not whether that workflow could be built. It was whether a standalone product deserved to sit beside the systems a shop already uses.

What was actually built

The frozen artifact includes:

• guarded CSV intake with explicit column mapping;
• strict date, amount, duplicate and spreadsheet-formula validation;
• row-by-row preview split into valid and blocked records;
• atomic import: valid rows enter together or nothing changes;
• one-action rollback immediately after import;
• versioned browser-local persistence;
• batch, return-slip and credit states;
• closeout and vendor-manifest CSV exports.

The screenshot matters because the artifact was exercised rather than described. It also has a strict limit: every row is a demo fixture.

The proof ledger

The final code gate recorded:

Vitest files             4 passed
Vitest tests             65 passed
TypeScript               passed
ESLint errors            0
Production build         passed

A browser run covered a 1280 × 900 desktop viewport and a 390 × 844 mobile viewport:

fixture preview          6 ready / 4 blocked
records after import     13
records after undo       7
records after re-import  13
records after reload     13
horizontal overflow      none
external import requests 0
failed requests          0
console errors           0
page errors              0

That run found one real defect before freeze: persisted records were being read during the first client render while the server rendered seed data. Reloading after an import therefore produced a React hydration mismatch. A deterministic first-render regression test was added, persistence moved behind hydration, and the browser pass was repeated with zero console or page errors.

The corrected ledger proves implementation behaviour. It does not prove operator demand.

The strongest disconfirming evidence

The broad premise weakened when incumbent systems were examined against the actual job.

Shopmonkey's core-return workflow already tracks core quantity, refundable amount, status, return reference and credit method, with stages from not ready through refunded. Tekmetric's core tracking already connects the core charge to the repair order, processes returns and reports vendor credits.

That did not prove every shop is satisfied. It changed the burden of proof.

A standalone desk would now need to find operators who simultaneously:

1. handle enough cores for reconciliation to matter;
2. do not already solve it inside their shop-management system;
3. reconcile across suppliers through CSV, paper or spreadsheets;
4. can adopt another desk without a costly integration;
5. are reachable through an economical channel.

The prototype showed a possible bridge. The research did not establish that this residual segment is large, reachable or willing to pay.

What did not happen

No shop owner, parts manager or service writer was recruited, contacted or interviewed for this project.

No real supplier export was uploaded. No public deployment, pricing page, checkout, outreach campaign or paid acquisition was launched. No credit was recovered. No revenue was generated.

The honest state is:

Product artifact        working locally
Market status           UNPROVEN
Real sessions           0
Public deployment       none
Customer data           none
Recovered money         none claimed
Active campaign         none
Decision                PARKED

This is not a claim that the problem is imaginary. It is a refusal to upgrade a coherent demo into a market result.

Why it was parked

Continuing to add integrations, dashboards or accounting language would have increased commitment without reducing the central uncertainty. The next legitimate step would be a bounded test with people who personally reconcile core returns in US repair shops.

Under the actual constraints, that campaign had no approved budget or recruitment path. The artifact was therefore frozen, tagged and bundled as a complete local archive. It can be reopened only if qualified operator access appears or the reconciliation workflow becomes one feature inside a broader repair-operations product.

Until then, stopping is the product decision.

What I learned

Persistence is part of the truth boundary

A local-first claim is not satisfied because an app calls localStorage. Initial server output, client hydration, atomic updates, rollback and corrupt-state fallback all have to agree.

A fixture can test mechanics without becoming a customer

The ten-row demo was useful because it repeatedly exercised valid, blocked, duplicate and unsafe spreadsheet cases. Its permanent job was protocol coverage. It never became evidence of a shop's behaviour.

Competitors change the proof required

Native core-return workflows do not eliminate every residual problem. They do eliminate the right to assume that a separate tracker is the default solution.

A finished artifact can support a stop decision

The code was made coherent enough that technical defects could no longer hide the product question. Once that happened, adding more code would have been easier than admitting the remaining evidence was weak.

Core Return Desk now sits in the complete project ledger as a working negative-result artifact: useful software, explicit limits, no borrowed traction.