Sulu Market seller guide
By Superluminal Engineering
A durable Blender product listing explains exactly what the buyer receives, where it works, how it is licensed, and how the creator will support it.
Published 2026-07-29 · Updated 2026-07-29
A strong Sulu Market product starts with a clear buyer, included files, tier boundaries, Blender compatibility, dependencies, license, price, and support promise. Test the exact archive in a clean environment and give every meaningful update a version and useful changelog.
1. Define the product contract
Start with one sentence that identifies the buyer, problem, and outcome. “A Blender add-on for technical artists that validates linked textures before farm submission” is more useful than “the ultimate workflow tool.” List what is deliberately outside scope.
Decide whether one product tier is sufficient. If multiple tiers exist, make each boundary objective: file variants, number of assets, seat or project rights, source availability, examples, or support level. Current delivery metadata can authorize a file for one or more tiers, so shared documentation does not need to be duplicated. The listing table must still tell buyers what changes.
| Contract field | Question it must answer |
|---|---|
| Product scope | What does the delivered product do today? |
| Buyer | Who has the problem and what Blender workflow do they use? |
| Compatibility | Which Blender versions, operating systems, and render engines were tested? |
| Dependencies | What else must be installed, downloaded, licensed, or online? |
| Tier | Which exact files and rights arrive at each price? |
| License | What may the buyer use, modify, and distribute? |
| Support | What will the creator help with, through which channel, and for how long? |
2. Package and test the release
Build from a clean release directory, not a working folder full of caches and credentials. Remove API keys, tokens, private URLs, customer files, development databases, editor state, absolute machine paths, and unlicensed samples. Confirm that filenames work on supported operating systems and that the archive opens without repair.
For an add-on, install it into a clean Blender profile and test enable, disable, restart, update, and uninstall behavior. Exercise the primary workflow on every Blender version you declare. Capture errors and expected output. For an asset, verify scale, transforms, materials, texture paths, linked data, modifiers, rigs, simulations, caches, and render-engine behavior. Open the file on a second machine or isolated account when practical.
The creator terms permit distribution metadata normalization for add-ons and extensions so delivered metadata can match marketplace records. Do not rely on normalization to repair functional code. The uploaded package remains the creator’s responsibility.
3. Write compatibility as data
Current authoring records a changelog and minimum and maximum Blender versions. Use a bounded range only when testing justifies it. If no upper-bound incompatibility is known, say which current releases were tested rather than inventing permanent future compatibility.
Compatibility notes should include more than Blender:
| Product type | Additional compatibility details |
|---|---|
| Add-on or script | OS, Python/native dependencies, required permissions, online service, conflicting add-ons |
| Model or rig | scale, units, topology assumptions, rig controls, modifiers, texture paths |
| Material or texture | renderer, color space, bit depth, UDIM layout, required nodes |
| Scene or template | render engine, linked libraries, caches, fonts, output settings |
| Tutorial | Blender version, prerequisite skill, included project files, captions or language |
Avoid marking versions as supported because the product merely opens. Test the core promised outcome.
From product folder to maintainable listing
Define the package, test it, state compatibility clearly, and support buyers after release.
- 1 · Define the product contract
Choose the product scope, included files, tier boundaries, license, dependencies, and support promise.
- 2 · Build and test the package
Remove secrets, verify clean installation, test declared Blender versions, and record expected outputs.
- 3 · Author the listing
Write answer-first copy, compatibility limits, file formats, changelog, screenshots, and a precise tier table.
- 4 · Price and publish
Model the current platform fee, review the final delivery, and publish only claims the package demonstrates.
- 5 · Support and update
Reproduce reports, issue versioned fixes, update compatibility fields, and keep the changelog useful.
4. Choose license, tiers, and price
Select a license the product can legally use. GPL, MIT, CC-BY, CC0, Editorial, Commercial, and custom terms have different obligations. Blender add-on licensing can involve GPL compatibility; read the current license reference and obtain qualified advice for unusual arrangements. A marketplace selector does not make invalid license terms valid.
Model the current platform fee before choosing a price. The live policy checked on 29 July 2026 uses the greater of 20% of the combined product-price and tip proceeds or $0.50. At $1.00, the minimum leaves $0.50 before other adjustments. At $10.00, the percentage component is $2.00. The minimum viable paid proceeds are $0.51. Taxes, refunds, chargebacks, reserves, withholding, and processor-account conditions can affect payout.
If using a public sale and coupon, the current terms say only the larger discount applies. The platform fee is calculated on the discounted product-price plus any tip. Test low-price discount cases before publishing them.
5. Create convincing media and documentation
Show the actual delivered interface or output. Caption Blender version, render engine, important settings, and whether an image is a close-up or composite. Do not use a concept mockup as proof that a feature exists. A short annotated workflow often answers more than a cinematic trailer.
Documentation should cover installation, first successful use, settings, expected output, known limitations, troubleshooting, update procedure, uninstall, license, and support. Provide a minimal example that a buyer can reproduce. This improves support quality and gives search systems concrete facts rather than generic adjectives.
6. Publish, support, and update
Before publication, download the seller copy through the marketplace path and compare its checksum or contents with the approved release. Review the listing as a buyer: select every tier, read every limitation, and verify that screenshots and documentation match the delivered version.
When a report arrives, request product version, Blender version, operating system, steps, logs, and a minimal file when safe. Reproduce before promising a fix. Publish corrections as a new version, state whether files or settings changed, update compatibility fields, and keep old instructions from masquerading as current.
Reviews require a qualifying purchase or entitlement and are limited to one review per license. Respond factually and mention when a review describes an older version. Do not trade compensation for hidden positive reviews or pressure buyers to remove accurate criticism.
Use Sell on Sulu Market for the current fee summary and commercial overview. Read the buyer guide from the other side of the transaction; it is the clearest checklist for whether a listing gives buyers enough information.