PatternProof

Most AI try-on helps you decide what to buy. PatternProof helps two people agree on what to make, a feasibility-checked Cut Card, frozen and approved before fabric is cut.

Comment

Inspiration

Most AI try-on helps you decide what to buy. We built the opposite: a tool that helps two people agree on what to make.

Virtual try-on exists to answer "should I buy this finished garment?" But in much of the world, clothing is made, not bought.

India alone has ~12 million custom tailors: one in six of all manufacturing workers, 99% of them informal, and 72% of them women. The occupation tripled from under 4 million in 2005, and it is now nearly 3× larger than the next-biggest manufacturing occupation. (Source: India's Periodic Labour Force Survey, July 2023–June 2024, analysed by Data For India.)

Every made-to-measure technology company is solving measurement: body scanning, 50+ dimensions, tailor-level accuracy. But measurement isn't where this breaks.

In a classic study in Applied Ergonomics, Ashdown & DeLong found people detect a waist fit difference as small as 0.5 cm. Critically, they also found that "individuals vary in their tolerance for fit variations at different locations on the body," with waist and crotch preferences diverging significantly between people. (Ashdown SP & DeLong M, "Perception testing of apparel ease variation," Applied Ergonomics 1995;26(1):47–54, PMID 15677000.) A 2023 Heliyon study reached the same place from the other direction: fit-satisfaction prediction improves when you segment by psychographic preference rather than body measurements alone. (PMCID PMC10362334.)

People can feel a half-centimetre difference, and they disagree with each other about which half-centimetre is right.

That is not a measurement problem. No tape measure resolves a disagreement about preference.

So the real transaction is this: a customer holds up a phone with a photo and says "like this." The tailor squints, interprets, and guesses. That guess is the product, and the fabric gets cut either way.

Off the rack, you can return it. Custom-made, you cannot. Irreversibility makes preview more valuable, not less.

What it does

PatternProof turns a customer's inspiration into a tailor-feasibility-checked, customer-approved Cut Card, agreed before fabric is cut.

It is not a fitting room. It is pre-production consent: a shared visual both parties freeze and approve before scissors touch cloth.

Try it in 60 seconds. No account, no email, no credential.
Live journey https://patternproof-nu.vercel.app/create
Immutable approved Cut Card https://patternproof-nu.vercel.app/s/demo-olive
Technical evidence ledger https://patternproof-nu.vercel.app/proof

The flow, end to end

  1. Private, consent-bound intake. One click opens an isolated Supabase anonymous session, with no email and no password. The browser gets single-purpose private upload grants. Every JPG/PNG is validated, pixel- and byte-limited, orientation-rotated, converted to sRGB JPEG, stripped of embedded metadata, and SHA-256 hashed.

  2. A quality gate that runs before we spend anything. Our T4 testing found the provider will happily return a technically successful render from a dark, partial-body photo, an image no one should show a customer. So the app inspects the normalized body image first: minimum edge 512/384 px, grayscale mean ≥ 70, and category-specific framing ratios. Bad input is rejected before any billable provider call, with specific guidance on what to fix.

  3. YouCam Clothes VTO V3 renders the garment on the customer's own body. Server-side only, using short-lived signed input URLs. Every returned asset is host-allowlisted, bounded, normalized, hashed, and privately re-hosted. We never depend on a third-party URL staying alive.

  4. Optional evidence chain. Before the core preview, Background Removal can rescue a noisy garment reference. After it, one provider-defined Fabric VTO direction can be applied before human review. Both keep distinct provenance hashes.

  5. Human veto: the feature that makes this trustworthy. Generative try-on will cheerfully render garments that cannot be constructed. So the tailor marks every customer non-negotiable as Can make as shown, Can make with adjustment (a customer-visible note is mandatory), or Not feasible, which blocks the customer review entirely. The customer never approves a beautiful impossible picture.

  6. Agreement Map. Requirement-linked, decision-coloured spatial notes anchored directly on the render, so "the neckline" means one unambiguous place on one image.

  7. Freeze and share. Starting review freezes the exact customer-visible snapshot and its digest. A 256-bit bearer link, expiring in 14 days, is bound to that snapshot. Only SHA-256 token hashes are stored, never the token.

  8. Customer veto and revision replay. The customer can request a change. Withdrawing review runs a fenced saga that copies the exact private inputs to a new version, verifies stored hashes, and atomically publishes an editable revision. Crashed or late copies land on a retryable deletion manifest.

  9. Approval is one atomic database operation. It verifies the token and the digest, locks the revision, records approval evidence, and consumes the token. After that the Cut Card is immutable.

  10. Post-approval motion proof. Image-to-Video V2 can generate a fixed five-second 480p presentation clip. It never enters the construction checksum and cannot alter the approved Cut Card.

  11. Hand-off to how tailors actually work. Print-usable Cut Card with a QR code, plus WhatsApp hand-off: the real channel, not a channel we wish existed.

  12. Audited body-photo erasure. After approval or archival, the shop can erase the body photo. The object goes, new signed body URLs stop, completion is recorded, and the frozen agreement snapshot and digest remain as integrity evidence.

How we built it

Stack: Next.js 15 (App Router) + React 19 · Supabase (Postgres, RLS, RPC, private brief-images bucket, anonymous + magic-link auth) · Vercel with one authenticated daily maintenance cron · Perfect Corp YouCam APIs.

YouCam integration: four features, exact unit accounting

Feature Role Cost Integrity boundary
Background Removal Optional rescue for a noisy garment reference 1 unit Runs before core preview; original and rescued hashes keep distinct provenance
Clothes VTO V3 Required body-specific visual-intent evidence 2 units Privately re-hosted; becomes the visual key in the frozen agreement
Fabric VTO Optional provider-defined visual direction 2 units Pre-review only; never claims uploaded-swatch fidelity, colorimetry, or drape
Image-to-Video V2 Optional post-approval presentation proof 5 units Post-approval only; never enters or changes the construction checksum

A complete four-feature chain is exactly 10 internally accounted units. Costs are not estimated. They were read from the authenticated GET /s2s/v2.0/credit/feature-cost endpoint. Every provider call is server-side, idempotently admitted, bounded by a global circuit breaker, and never automatically retried after an ambiguous vendor POST.

We validated before we built

Day 1 was a hard gate: no product code until the API proved itself. Full record in D1-RESULTS.md, written as an evidence document rather than a marketing one.

Test Result
T0 Auth + round trip PASS. Bearer API-key auth; POST /s2s/v2.0/file/cloth-v3 → POST /s2s/v2.0/task/cloth-v3 → poll
T2 Clean baseline PASS. Recognizable output in 12.8 s
T3 Messy reference (kill gate) PASS 3/3. Garment worn by another person (22.7 s), angled/cropped (13.2 s), and low-light (22.2 s) all recognizably transferred
T4 Poor body photo Provider returned technical success on an unusable image, so we built a pre-provider rejection gate
T5 Unit cost 2 units per successful Clothes VTO V3 result, from the official feature-cost API
T6 Signed URLs PASS. Supabase expiring signed inputs accepted; canonical inputs stay private
T7 Latency + repeat Median 22.2 s. Identical input returned byte-identical output: SHA-256 b53062e7…, 141,631 bytes

That last line is our favourite result. A repeated identical request produced a byte-identical image. We still built a full content-addressed cache with database reservations, leases and a usage budget. Observed determinism is not a guarantee of provider cache policy, and a Cut Card that re-rendered differently on reload would destroy the entire premise of a frozen agreement.

Security and privacy posture

  • Browsers are untrusted: they never receive the YouCam key or the Supabase service-role key.
  • Row-level security on every table; cross-tenant object paths cannot produce signed URLs.
  • Customer review links are unguessable, expiring bearer links, not public galleries.
  • 24 ordered, additive migrations with a release sentinel; /api/health returns 503 if configuration, the private bucket, or the expected migration is missing.
  • A release security gate greps for credential patterns across the repo before any public push.

Verification

150/150 automated tests, TypeScript, ESLint, an optimized 20-page production build, HTTP health, and a real Chrome navigation audit at 1440×1000 and 390×844: zero console errors, zero horizontal overflow, and every next/final action above the mobile fold.

Challenges we ran into

1. Our best idea was unbuildable, and we killed it. We originally planned to render the customer's own fabric swatch onto the garment. Research indicated Fabric VTO takes a predefined template rather than an arbitrary upload, so we dropped the claim entirely rather than overpromise. PatternProof makes no uploaded-swatch fidelity, colorimetry, or drape claim anywhere.

2. Three statistics in our own research notes turned out to be fabricated or mis-attributed. A "35% BGMEA survey" that no authoritative source carries. A "73% Ministry of Textiles" figure that traced to a fashion brand's blog. And a "2–3 billion people" number that we had invented ourselves and never checked. All three were caught and retired before submission. Everything cited above was fetched and read at source.

3. The provider succeeds on inputs it shouldn't. T4 showed a technically successful render from an unusable photo. Provider success is not product success, so the quality gate had to live in our application, ahead of the spend.

4. Generative try-on renders impossible garments. A beautiful AI image the customer approves and no tailor can construct makes the expectation gap worse, not better. This is what forced the three-state human feasibility check, and it became the product's strongest trust feature.

5. Withdrawing a review is a distributed transaction. Cloning exact private inputs into a new version, verifying stored hashes, and publishing atomically, all while surviving crashes and late writes, required a fenced saga with a retryable reconciliation manifest.

6. We had no access to tailors or customers. So we did not invent any. See below.

Accomplishments that we're proud of

  • A category, not a feature. "Another virtual try-on" is a crowded space. Pre-production consent for made-to-order clothing is not. That combination is specific: body-specific generative VTO, the customer's own inspiration reference, image-anchored two-party discussion, and versioned approval before an individual garment is cut.
  • T3 passing 3/3, which meant real customer inspiration photos stayed in scope instead of a curated library.
  • Byte-identical reproducibility on a generative pipeline, with a cache built anyway.
  • A human veto that can say no. Our public sample deliberately includes a not-feasible scenario, because a demo where everything succeeds proves nothing.
  • Zero-login judging. No account, no email, no credential. A judge with 60 seconds sees the whole product.
  • Original problem research. RESEARCH.md documents 108 manually screened 1.0–2.0 public tailoring complaints across 41 de-identified businesses and three city samples. Both reviewers and businesses are de-identified, because naming a real micro-enterprise as a failure example would harm exactly the informal, majority-women workforce this product exists to serve.
  • We report what we do not solve. RESEARCH.md is explicitly a purposive negative-review study: not a prevalence estimate, not user validation, and not proof of impact. It also names the complaint categories PatternProof does nothing for.

What we learned

Search results confidently invent authoritative-sounding provenance. Three fabricated claims survived multiple review passes in our own notes. We adopted one rule that saved the submission: if it wasn't fetched at source, it doesn't ship. We applied the same rule to code, so no endpoint, parameter, or response shape was written from memory or a search result.

The failure in custom tailoring is expectation, not measurement. An entire industry has been aiming at the wrong target for a decade. You cannot fix a disagreement about preference with a better tape measure.

Provider success is not product success. The most important engineering decision we made was deciding what to reject before spending a unit.

Honesty is a feature. The disclaimer on every render (visual intent reference, not a fit, construction, or fabric-drape guarantee) is not a weakness. Generative VTO can make intent concrete; it cannot certify measurements, cloth behaviour, or construction feasibility. A trustworthy product separates those responsibilities out loud.

What's next for PatternProof

  • A real pilot. VALIDATION-PROTOCOL.md pre-declares what we would measure: time from brief to approval, revisions before cutting, share-link approval rate, and remake/alteration rate against a shop's own baseline. We have measured none of these yet, and we say so. There are no invented testimonials, personas, or pilot results anywhere in this submission.
  • Vernacular UI. 99% informal, 72% women, overwhelmingly not English-first. Hindi, Tamil and Bengali are the highest-value next build.
  • Offline-tolerant Cut Card for shops with intermittent connectivity.
  • Integration, not replacement. Tailor order-management software already exists. A stable brief.approved hand-off belongs in their workflow. We never intended to rebuild a POS.

References

  1. Custom tailoring workforce. Periodic Labour Force Survey (PLFS), July 2023–June 2024, with Census 2011 projections. Analysis: Data For India, The rise of custom tailoring.
  2. Fit perception thresholds. Ashdown SP, DeLong M. Perception testing of apparel ease variation. Applied Ergonomics. 1995;26(1):47–54. PMID 15677000.
  3. Measurements vs. preference. Dik NY, Tsang PWK, Chan AP, Lo CKY, Chu WC. Heliyon. 2023;9(7). PMCID PMC10362334.
  4. Formative problem research. RESEARCH.md in the repository. 108 screened public complaints, 41 de-identified businesses, three city samples. Purposive negative-review study with stated limitations.
  5. Integration evidence. D1-RESULTS.md (live YouCam validation), RELEASE-ACCEPTANCE.md (production acceptance matrix), and the live /proof ledger.

Built With

  • background-removal
  • clothes-virtual-try-on
  • css
  • eslint
  • fabric-virtual-try-on
  • generative-ai
  • github-actions
  • html
  • image-to-video
  • next.js
  • node.js
  • perfect-corp
  • postcss
  • postgresql
  • qrcode
  • react
  • rest-api
  • row-level-security
  • sha-256
  • sharp
  • supabase
  • tailwindcss
  • typescript
  • vercel
  • youcam-api
Share this project:

Updates