# Preparing a Product for Review

https://dev.wisecp.com/es/preparing-a-product-for-review

Every product you submit is reviewed by hand: what completes each section, what the review looks at and which gaps come back most often.

## Overview

Submission is not automatic. Every product and every new release goes through the WISECP team's quality review and a baseline security assessment.

The readiness meter in the editor is a copy of the rule, not the rule itself. On submission the server counts the sections again and refuses anything incomplete.

Review is a quality gate, not a design audit. Most requests that come back concern what a buyer reads before purchasing rather than the product itself.

## Prerequisites

- **A submittable state**: Only a draft or a product that came back for changes can be sent. One in review or cancelled cannot.
- **An active subscription**: Submitting and resubmitting need Premium Developer.
- **Verified identity**: When documents are requested, upload them to your account. The product does not enter the queue until they are approved.
- **An installable package**: One archive carrying the whole product. Directory layout and what must never go in: [Packaging a Module for Distribution](https://dev.wisecp.com/en/packaging-a-module-for-distribution).

## Structure

A section is complete only when its own answer is. The table below says what completes each one.

| Section | What completes it |
| --- | --- |
| Product identity | Title, category and a one-line summary |
| Product pitch | At least 120 characters of description in your primary language, a logo and at least one screenshot |
| Pricing | The free model, or a commercial model carrying at least one priced offer |
| Licensing | No check declared, or a declared check whose test has passed |
| Compatibility | Version number, oldest supported WISECP, and the purchase address on a paid product |
| Installation file | The complete package for that version |
| Review | Three confirmations: distribution rights, testing, installation documentation. Not asked once the product is live |

Licensing is a step of its own and does not follow the price: a free product may require a check, and a paid one may ship without any. The highest supported WISECP version is not asked for — leaving it empty means there is no upper bound.

## Walkthrough

### Before you submit

1. Read the description as a buyer would: what the product does, who it suits, what it needs.
2. Take screenshots from the product's real screens; a cover image alone is not enough.
3. Write the compatibility range from versions you actually tested. The upper end is a gate: installations above it cannot download the package.
4. Leave the package for last, so the archive already carries the licensing you configured above it.

### Submit

1. Tick the three confirmations in the review section.
2. Select **Submit for Review**. The product enters the queue and the editor becomes read-only.
3. You may withdraw it until a moderator picks it up; after that the decision is awaited.

### After the decision

1. When changes are requested, the reason appears on the record. Correct what it names and send the product again.
2. An approved product goes live; every later update goes through its own release submission.
3. While live, description, artwork and price stay editable, and every section opens directly. A new package can still be uploaded from here, but sending it takes the card out of the catalogue until the decision comes back; a version number and a licence change normally travel with a release.

## Reference

- **Distribution rights confirmation**: You state that the package holds no third-party content whose licence forbids distribution.
- **Testing confirmation**: You state that you tested the product across the range written in the compatibility section.
- **Documentation confirmation**: You state that installation and configuration steps are available somewhere the buyer can reach.
- **Verified fields**: The licence check, the package and the version number are what a moderator verified. Changing them means a new submission, which is why the editor warns before it accepts one.
- **What review covers**: Quality review and a baseline security assessment. It is not a full security audit of the product; responsibility stays with the developer.

## Example

A refused submission names each missing section. The reading below shows the three most common gaps.

```bash
Product identity  complete
Product pitch     missing   -> description 96 characters (120 required)
Pricing           missing   -> commercial model selected, no priced offer
Licensing         missing   -> check declared, test never passed
Compatibility     complete
Installation file missing   -> no package uploaded
Review            complete
```

The character count is measured on the text a visitor reads, after formatting tags are stripped. Empty paragraphs do not reach the threshold.

## Pitfalls

> **Declaring a licence check without testing it**
> 
> A declared check must have passed its test, whatever the product costs. An untested one does not complete the section and the submission is refused.

> **What must stay out of the package**
> 
> The archive carries the product itself: your configuration file, database dumps, personal keys and development leftovers do not belong in it.

> **Downloading requires a WISECP licence**
> 
> Even a free product is handed only to an account with an active WISECP service. The buyer needs a system to install it on.

## Related Articles

- [Publishing a Marketplace Product](https://dev.wisecp.com/en/publishing-a-marketplace-product)
- [Marketplace Product Licensing](https://dev.wisecp.com/en/marketplace-product-licensing)
- [Shipping a Marketplace Release](https://dev.wisecp.com/en/shipping-a-marketplace-release)
- [Packaging a Module for Distribution](https://dev.wisecp.com/en/packaging-a-module-for-distribution)
- [Becoming a Certified Developer](https://dev.wisecp.com/en/becoming-a-certified-developer)