ZeDaq.ai
Shopper using virtual try-on for a tailored suit

How to Brief a Developer to Add Virtual Try-On

By the ZeDaq.ai team · · 4 min read

On this page
  1. What should the brief say about your store?
  2. Should you ask for the widget or the API?
  3. What scope should you write down?
  4. What should the acceptance checklist include?
  5. What should you ask the developer to report back?
  6. What does a short brief look like?
  7. What questions should you ask before you hire?

To brief a developer to add virtual try-on, give them four things: your platform, which integration route to use (script widget or REST API), the product pages in scope, and a clear definition of done. A one-page brief like this prevents most delays and extra cost.

This guide is for store owners handing the work to a freelancer or agency. It builds on the try-on API guide for developers, and gives you a template you can copy.

What should the brief say about your store?

Start with facts the developer can't guess:

  • Platform: WooCommerce, Wix, Squarespace, BigCommerce, PrestaShop or a custom build.
  • Theme or template: the name, and whether it is a custom theme.
  • Which products: all clothing, or one category first.
  • Who can access what: admin access to the theme, and where the product template lives.

If you are on PrestaShop, read try-on options on PrestaShop first, so the brief doesn't ask for something that isn't available.

Should you ask for the widget or the API?

This is the most important decision in the brief.

Script widget REST API
Effort Paste one script tag into the product template Build your own interface and server calls
Interface Provided: adds "Try it on" and "Find my size" You design it
Control Limited to its settings Full
Best for Most stores Custom apps and special flows

ZeDaq.ai offers both. The widget needs a key locked to your domain in Dashboard → API keys. The API is POST /api/v1/tryon with an x-api-key header, documented in the API reference. The article on the widget versus API choice explains the trade-offs. For most stores, ask for the widget, and see adding try-on with one script tag.

What scope should you write down?

Be exact about what is in and out. A useful scope lists:

  1. Which page templates get the feature (product pages only is a good start).
  2. Which products show the button, and how they're marked as upper body, lower body or dresses.
  3. Whether the size chart is entered by you or by the developer.
  4. Whether staging is available for testing.
  5. Anything out of scope, such as redesigning the product page.

Also give the developer your size guide as body measurements, one chart per garment type, so they don't have to guess.

What should the acceptance checklist include?

Define done before work starts. A simple checklist:

  • The button appears on in-scope product pages and nowhere else
  • The key is locked to the live domain, not left open
  • A test photo returns a try-on image on a real phone
  • The size result uses your chart's labels
  • The page still works with the script blocked
  • Page speed is checked before and after, see measuring a widget's impact on page load

What should you ask the developer to report back?

Ask for a short handoff note:

  • Where the script or code was added, and how to remove it
  • Where the API key is stored
  • What was tested, on which devices
  • Any known limits

This lets anyone on your team maintain the work later.

What does a short brief look like?

Here is a template you can copy and fill in:

  1. Goal: add a try-on and size-finder button to product pages for our clothing range.
  2. Platform and theme: name both, and say who has admin access.
  3. Route: the script widget, unless we agree the API is needed.
  4. In scope: product page template, button placement, garment type per product.
  5. Out of scope: page redesign, checkout changes.
  6. Done means: every item on the acceptance checklist passes on a real phone.
  7. Handoff: a note on where the code sits and how to remove it.

Keep it to one page. A developer who can read the whole brief in two minutes is more likely to follow it.

What questions should you ask before you hire?

Ask whether they have added a third-party script to your platform before, how they test on mobile, and how they handle a rollback. Be wary of anyone who promises results you can't verify. A developer's job is to integrate it correctly, not to predict sales.

Get an API key for your developer

FAQs

How long does a try-on integration take?

It depends on the route and your theme. The widget is a short job for an experienced developer, while a custom API build takes longer. Ask for an estimate after they've seen the brief.

Can I do it myself instead?

If you can edit your theme, the widget setup is a paste-in step. The brief is for when you'd rather hand it over.

Do I need to give the developer my account password?

No. Share the API key from the dashboard or invite them as a collaborator in your platform, and keep your own login private.

Who writes the size chart?

You do, because you know how your brand fits. The developer can enter it, but the measurements should come from you.

Try ZeDaq.ai free

Virtual try-on and Find my size for your store, plus client, order and invoicing tools for tailors, in one subscription.

Related articles