Counterfile - the release candidate that did not earn a launch

The uncomfortable part came after the build

Most product case studies begin once the product succeeds. This one begins when the code stopped being the hard part.

Counterfile was a local-first evidence desk for Shopify merchants preparing a chargeback response. It organised merchant-held material, separated a missing local item from a file Shopify Admin might reject, and produced a review copy plus upload plan. It did not submit a dispute, predict an outcome, read a Shopify store, or offer legal advice.

That boundary was deliberate. A chargeback tool that cannot see the live Admin state should not cosplay as a system of record.

Counterfile

Shopify chargeback handoff preflight

SAMPLE / GENERATED DATA

Primary findingDelivery confirmation

Required evidence is missing.

Local review completeness8 / 9 checks

One local gap remains.

Shopify upload fitBlocked

Two fictional .txt files are not direct-upload ready.

What was actually built

The release candidate had more than a landing page:

• a labelled generated sample, visible before any paywall;
• a concrete missing item - Delivery confirmation - rather than an abstract risk score;
• two fictional .txt attachments correctly separated as local evidence that was not fit for direct Shopify upload;
• three distinct concepts: local evidence completeness, Shopify upload fit, and overall handoff readiness;
• browser-local case storage with IndexedDB attachments;
• encrypted portable backups using PBKDF2-SHA-256 and AES-256-GCM;
• a server-verified one-time entitlement path and a mock purchase mode for deterministic tests;
• unit, browser, accessibility, deterministic-build, performance and security gates.

The product was technically coherent enough to launch. That sentence is often where a portfolio changes the subject. Here it is where the investigation starts.

The hypothesis

The original claim sounded plausible:

Some Shopify Payments merchants still assemble evidence across Admin, carriers, support threads and local folders. A small preflight could catch a missing item or an upload-format problem before submission. A one-time $29 price might be easier to accept than another subscription.

Pain around chargebacks is real. But pain is not the same as demand for this intervention.

Shopify already collects available evidence and manages the response flow. Shopify Protect removes much of the job for an eligible subset. Existing apps such as Chargeflow and Disputifier sell automation and recovery rather than a second manual desk.

The remaining segment therefore became narrow: merchants handling non-Protect cases themselves, still adding evidence manually, still exposed to local gaps or file-fit failures, and preferring a private preflight over an integrated automation service.

That segment may exist. The research did not establish that it is large, reachable or willing to pay.

The study that was prepared - and not run

I preregistered a moderated test with eight qualified Shopify Payments merchants. The tasks were concrete: describe the last case, find the sample's missing delivery proof, notice the upload blockers, distinguish completeness from readiness, and choose Counterfile against the current process.

Then the operational constraint arrived: the owner could not conduct, schedule or attend interviews. The validation budget was exactly zero. There was no organic route to enough qualified merchants without public recruitment.

The correct status is NOT RUN - SUPERSEDED, NOT FAILED.

No merchant was recruited, contacted, scheduled or interviewed. Calling this a failed interview study would invent an event. Calling the product validated would invent eight people.

The synthetic preflight was a test, not a focus group

A deterministic harness exercised eight simulated profiles (SIM01-SIM08). Five passed the synthetic screener; three were screened out. It tested exclusion branches, moderator non-interference, competitor alternatives, Shopify Protect routing and the risk that “completeness” would be misread as a win score.

Every generated record carried the same permanent label:

SIMULATED / NOT EVIDENCE
Need: UNPROVEN
Real qualified sessions: 0 / 8
Decision gate applied: false

The harness did useful work: it proved that the protocol machinery could refuse unsafe conclusions. It did not prove that a merchant has the problem, understands the interface, would use the tool or would pay $29.

A synthetic customer is excellent at arriving on time. This is one of the reasons not to mistake it for a customer.

What desk research changed

The strongest falsification signal was not “merchants do not hate chargebacks.” Many plainly do. It was that the proposed product sat between increasingly capable native workflows and apps selling a more complete outcome.

Three things compressed the opportunity:

1. Shopify already owns the submission context. Counterfile could only prepare and compare; it could not know the live Admin state.
2. Protect and automation remove cases from the addressable job. The more effective they become, the less often a second manual desk is opened.
3. The substitute is often not another checklist. It is Shopify Admin at $0, an internal spreadsheet at $0, or a recovery service paid from recovered funds.

The product still had a defensible privacy boundary: no store integration, no case upload, local processing. But privacy is a reason to prefer a solution only after the underlying job is frequent and costly enough. It is not a market by itself.

The verdict

Counterfile does not currently look necessary for the mass Shopify merchant.

A residual product is theoretically possible for privacy-sensitive operators handling manual, non-Protect disputes. Under the actual constraints - zero budget, no interviews, no organic access to qualified merchants - the probability of building a standalone paid business from that residual segment is low.

The formal state remains:

Need                 UNPROVEN
Business priority    LOW
Recruitment          BLOCKED
Real sessions        0 / 8
Validation spend     0
Product deployment   none
Participant contact  none

This is not an INVALIDATED verdict masquerading as certainty. It is a decision not to keep paying with engineering time for evidence the project cannot currently obtain.

What happens to the work

The repository and protocol remain a dormant option, not an active company. I would reopen it only if one of three things changes:

1. organic access appears to at least ten qualified merchants;
2. independent merchants repeatedly describe the same local-gap/upload-fit problem without being shown Counterfile;
3. the preflight becomes one feature inside a broader merchant-operations product rather than a standalone purchase.

Until then, no recruitment campaign, public prototype or payment flow needs to be manufactured to make the case study end happily.

What I learned

Release-ready and market-ready are separate ledgers

Tests can establish that software behaves as specified. They cannot establish that the specification deserves a market.

Synthetic participants should test the research machinery

They are useful for branch coverage, safety checks and wording failures. The moment they become quotes, conversion or demand, the research has started interviewing itself.

Competitor research should try to kill the premise

The useful question was not “who else has a chargeback product?” It was “what has already removed the job Counterfile expects to be paid for?”

A stopped product can be a stronger case study

The valuable deliverable was not another checkout page. It was a clean boundary between what existed, what was tested, what was merely simulated, and what could not honestly be claimed.

The code reached release candidate. The need did not. Nothing had to pretend otherwise.