This policy covers https://www.genfashion.app and the GenFashion try-on widget wherever a shop has installed it. It is written to describe what the software actually does. Where a protection is not built yet, it says so rather than describing an intention.
The operator of this deployment is BuildFrame Technologies Private Limited, C-1208, ACE PLATINUM, ZETA 1, Greater Noida, Uttar Pradesh 201306, India. Privacy questions and requests go to hello@buildframe.tech.
1. Two different relationships
If you are a shopper who used try-on on a shop's product page, the shop decides to offer the feature and is the controller of your photograph. BuildFrame Technologies Private Limited processes it on the shop's instructions, as its processor. Your rights are exercisable against either of us and we will not bounce you between the two — write to hello@buildframe.tech and we will act or route it.
If you run a shop and hold an account here, BuildFrame Technologies Private Limited is the controller of your account data.
2. What a shopper's photograph goes through
In order, on every try-on:
- Downscaled in your browser to 1280px on the long edge before anything is sent. The original full-resolution file never leaves your device.
- Screened before any image model sees it. An automated check looks for sexual, violent and self-harm content, and for whether the image shows a person who appears to be an adult. If screening cannot reach its provider, the try-on is refused rather than allowed through.
- Sent to an image model together with the garment images, to generate the result.
- Stored in a private bucket, never a public one. Reads are short-lived signed links that expire in ten minutes.
- Deleted automatically. See retention below.
We record the outcome of the screening step — the categories that fired and the confidence scores — so that a refusal is auditable. The image itself is never attached to that record.
3. Retention
| What | Kept for |
|---|---|
| Shopper photograph | 1, 3 or 7 days, chosen by the shop |
| Generated try-on image | Same window as the photograph |
| Generation record (no image) | Retained for billing and abuse investigation |
| Screening verdict (no image) | Retained as an audit record |
A sweeper runs hourly. It deletes the stored bytes first and marks the record afterwards, so a row is never reported as deleted while the file is still there. Files are stored with caching disabled, because a cached copy would otherwise keep serving from a CDN edge after deletion.
One honest exception. Photographs saved before 7 September 2026 were stored differently and carry no expiry date. They are not reached by the sweeper. If you uploaded a photograph before that date and want it gone, write to hello@buildframe.tech and we will remove it by hand.
4. Your photograph is never used for training
Not by us, and not by our model providers under the terms we contract on. We do not sell photographs, we do not license them, and we do not use them to improve a model.
5. Who else processes your data
| Processor | What it handles |
|---|---|
| OpenAI | Image generation, and the content screening in step 2 |
| Supabase | Database and the private image bucket |
| Vercel | Hosting, and the logs a server necessarily writes |
| Resend | Transactional email — confirmation, password reset, support replies |
| Stripe, Razorpay | Payment for credits. Card details go to them, never to us |
| Only if you choose "Sign in with Google" |
If a shop installed try-on through Shopify or WooCommerce, that platform sees the traffic to its own storefront as it would for any page.
6. The shopper identifier
The widget stores a random identifier in your browser so it can enforce a fair-use limit on how many try-ons one person runs per hour. It is generated locally, means nothing outside that counter, and is not linked to your name, email or order. Clearing site data resets it.
7. Your rights
You can ask for a copy of what we hold, ask for it corrected, ask for it deleted, or object to the processing. Write to hello@buildframe.tech.
Say plainly how erasure works today. There are two paths and they differ in who starts them.
If you ask us directly, it is a person: someone reads your request, runs the erasure, and confirms when it is done. There is no self-service delete button on a shop's storefront.
If the shop you used has integrated our API, it can erase you on request without waiting for us — the deletion runs against our records immediately and returns a receipt saying what was removed.
Either path removes you: the photograph, the result image made from it, and the identifiers tying a record to you. It does not remove the shop's record that a try-on happened and what it cost. A subject request is not a licence to erase someone else's billing history, and we would rather say so than imply a completeness we do not deliver.
Photographs otherwise expire on the schedule in section 3 whether or not you ask.
8. AI-generated images
Every try-on result is a synthetic image generated by a model. It is not a photograph of you wearing that garment, and it is not evidence of fit.
Every result carries machine-readable provenance in the image's own metadata, marking it as generated by a model and naming the model that made it. There is no setting that removes it, for us or for the shop.
The visible "AI MODIFIED" badge is separate, and a shop can switch it off. It is composited by default; a shop can disable it for its account, or per request through our server API. It cannot be disabled from the widget that runs in a page, because that is driven by a key which ships in the page source and anyone reading it could otherwise strip the disclosure. Where the shop has set a logo, that is composited too.
Both are recorded against the generation from what the compositor actually did rather than what it was asked to do, so a badge that failed to render is not recorded as applied.
The provenance metadata is deliberately the cheap version, and it matters that you know which. We write an unsigned text field into the file recording that it is machine-generated and naming the model. That is not C2PA: C2PA is a signed manifest bound to a certificate a verifier can trace to an issuer, and ours is neither signed nor bound to anything. Anyone can strip it or forge it. It is worth having and it is not proof, and this page has had to retract an over-claim on exactly this point once before.
9. Children
The service is not for under-18s. The screening step in section 2 attempts to refuse images of people who do not appear to be adults, but it is an automated estimate on a confidence threshold, not a proof of age, and it will sometimes be wrong in both directions. If you believe a child's photograph has been uploaded, write to hello@buildframe.tech and we will delete it on receipt, ahead of the retention schedule.
10. Changes
Material changes are announced on this page with a new date at the top. This policy took effect on 2026-09-12.
13 September 2026. Two sections were corrected because the software had moved past them and the page had not. Section 7 said there was no automated erasure path; there is one, and shops on our API can run it themselves. Section 8 said results carried no visible AI label and no provenance metadata; both are now written into every image. Both corrections expand what we do — the page was understating the product, not overstating it — but a privacy policy that is out of date is wrong in whichever direction it drifts, and this one was published to search engines the same day it was found.