The seller guide.

Before anything else, two questions decide whether this is worth your weekend.

Do you have the right to sell it?

The work has to be yours, or licensed in a way that permits resale. This is the one thing that cannot be fixed by editing, and it is the most common reason a promising item is rejected outright.

The trap is dependencies. A licence that lets you use a component does not always let you redistribute it inside something you sell. Go through everything in your zip and check each licence. Linking to a package is different from bundling it.

Does it solve one problem completely?

Items that keep selling tend to do one thing thoroughly rather than five things partially. Buyers arrive searching for a specific problem, not browsing for a suite.

The unglamorous middle of an application is where sustained sales come from: authentication, billing, admin panels, imports, reporting. Nobody is excited about them, everybody needs them, and nobody wants to build them again.

What you upload is what a buyer downloads. Most rejections come from this step, and almost all of them are avoidable.

Install your own zip on a clean environment

Not your development machine. Something empty. Follow your own instructions exactly, as though you had never seen the project.

This single exercise catches more problems than everything else on this page: the file that was always on your machine and never made it into the zip, the database step you forgot you did months ago, the config that only works because of something in your environment.

Search the zip for your own credentials

Every time, without exception. API keys, database passwords, SMTP details, tokens. The single most common security finding at review is a developer's own key left in a config file.

Include real documentation

Requirements at the top, then numbered installation steps with the exact commands and what the reader should see after each one. Then a troubleshooting section listing the errors people actually hit, using the exact error text, because that is what they will search for.

Keep it inside the zip as HTML or markdown, not only on a hosted site. Buyers keep downloads for years and links move.

Structure it so somebody else can maintain it

It does not have to be beautiful. It has to be readable. What gets flagged is the unreadable extreme: everything in one file, no structure, obfuscated sections, large blocks of dead code left in.

• Installs clean on an empty environment, following your own instructions
• No credentials, keys or personal paths anywhere in the files
• Requirements, install steps and troubleshooting all included
• Every bundled dependency is licensed for redistribution
• No placeholder content or commented-out experiments

Buyers decide in well under a minute, and they check things in a fairly predictable order. Build the listing in that order.

The live preview comes first

Most buyers click preview before reading a word. If it is slow, broken on a phone, or full of placeholder text, nothing else on the page gets a chance.

Open your own preview on a phone, on a normal connection, and watch it the way a stranger would.

Screenshots are evidence, not decoration

A buyer is looking for proof the thing exists and is finished. Show real screens with real content. Empty states, lorem ipsum and cropped browser chrome all read as unfinished.

Your thumbnail is doing a different job: it competes in a grid. It should be legible at the size of a playing card.

Put the requirements near the top

PHP version, database, framework, extensions, anything that must exist first. Be honest about what the item does not do.

This feels like it costs you sales. It does, and they are the sales that would have become refund requests and one-star reviews. Everyone else trusts you more for it.

Write the description for someone deciding, not someone sold

By the time they read it they are looking for a reason to say no. Answer the objections directly: what it needs, what it does not include, what happens after they buy.

New sellers almost always price too low, on the theory that cheap sells. It does not work the way they expect.

Support cost does not scale with price

A buyer who paid $9 asks roughly as many questions as one who paid $49. Price low enough and you are running a support desk for a rounding error, which is how sellers burn out and stop replying, which is what actually kills a listing.

Price against what it replaces

Not against the cheapest thing in the category. If your item saves a developer two days, it is competing with two days of their time. Then check comparable items, and be honest about comparable: something with four years of updates and an author who answers in an hour is not your comparison as a new seller.

Set Extended deliberately

Extended is for buyers whose own end users pay. They are earning from your work. A common shape is three to five times the Regular price. Setting it too close to Regular leaves money on the table from the buyers who can most afford it.

The full rules are in the licence terms, and the one question that decides the tier is whether the end product charges its own users.

You can raise it later

Existing buyers are unaffected; their licence and updates are theirs. Many sellers launch slightly low and move up once the first reviews land.

Set the support window honestly

Whatever window you choose is a commitment you are being paid for. Choose one you will still be willing to honour in six months. You can offer renewal at your own price when it lapses, and it extends from where the last window ended. See the item support policy.

Every buyer gets a purchase code. Your item can verify it against our API, and doing so takes an afternoon at most.

What it does and does not do

Being straight with you: no licence check running on somebody else's server can be made uncrackable. Your code is on their machine.

What it genuinely achieves is worth the afternoon anyway. It keeps honest buyers honest, it makes casual copying more effort than paying, and it stops one licence quietly becoming fifty across an agency, which is where sellers lose the most.

The one mistake that hurts your own buyers

Fail closed and you have built a way for your item to break every customer site at once. Our API has a bad ten minutes and every install goes dark. Your buyers do not know it was us; they know your item broke their site.

Treat an unreachable API as "carry on", never as "shut down." A definite negative, where we reply that the licence is invalid, is a real answer. No reply at all is not an answer and should change nothing.

Give the check your item id

Your publishable key identifies you, not the item, so the same key goes into everything you sell. That means the check also has to say which of your items is asking. Each item has an id, on the Licensing panel of its page in your dashboard, and you pass it alongside the key.

Leave it out and the SDK refuses to activate at all, which is deliberate. If a code only had to match the seller, someone who bought your twelve dollar item could use that code to unlock your two hundred dollar one. With the id in place a purchase code only ever works on the item it was bought for.

Get the id before you zip, not after

The id belongs to the item, so the item has to exist before there is an id to copy. That catches people out, because the id then has to go inside the zip you upload to that same item.

The order that works:

1. Create the item in your dashboard and save it as a draft. A draft needs only a title, so this takes a moment.
2. Open the Licensing panel on that item and copy the id.
3. Paste it into your script alongside your publishable key.
4. Zip your script with the id already inside, and upload it to that item.
5. Finish the listing and submit for review.

The id never changes, so you paste it once and it keeps working through every version you release. A different item gets a different id, so do not carry one across when you duplicate a listing.

Practical rules

• Check on install and occasionally after, never on every page load
• Store the signed token and work from it between checks
• Use a short timeout, so a slow response never hangs a page
• Log failures quietly for yourself rather than showing them to the buyer
• Keep your API key server side, never in the zip you distribute
• Copy the item id from the dashboard; one wrong character locks out every buyer

The PHP SDK already does all of this, which is the main argument for using it rather than writing your own. The API underneath is plain HTTPS and JSON, so any language works. See the API documentation.

Every item is reviewed by a person before it goes live. Rejection is normal, most published items here were rejected at least once, and there is no penalty for resubmitting.

What review actually checks

• Whether you hold the rights to everything in the package
• Security: injection holes, unvalidated uploads, unsafe defaults, committed secrets
• Whether the page matches the package
• Completeness: install instructions, schema, nothing missing
• Whether another developer could install and maintain it

If it comes back

The rejection always states the reason. Fix it and resubmit; there is no limit on attempts and no mark against you.

If a reviewer has flagged something deliberate as a bug, reply and explain why it is deliberate, specifically. Reviewers do change their minds.

This is the part new sellers underestimate, and it is the part that decides whether an item still sells in a year.

Answer your comments

Buyers scroll to the comments before they buy, looking for two things: whether the author replies, and how long they take. An item with a handful of prompt, useful replies outsells a technically better item where the last three questions went unanswered.

This is not admin work. It is the part of the listing you cannot fake, and it is the one thing a competitor cannot copy from you.

Know what support covers

Bugs, installation on environments you support, questions about shipped functionality, and problems your own updates caused. It does not oblige you to do custom development, install the item for the buyer, or fix code they wrote on top of yours.

Many sellers take that work as a separate paid job. Offering it is reasonable; being obliged to do it for free is not. See the item support policy.

Ship small updates

An item that keeps up with the versions its buyers are on holds its sales for years. One that was excellent for a framework two majors behind stops selling regardless of quality. Regular small updates are the strongest signal that an item is alive.

Updates are free to everyone who holds a licence, forever, whatever their support status. Nothing is ever pushed to a buyer's server; they download and apply it deliberately.

Cut your support load with documentation

Track your requests for a month and most will be the same handful of questions. The troubleshooting section you write once removes them permanently. It is the highest return work available to a seller.

You keep between 70% and 85% of each sale, depending on your level, and the rate is recorded against each sale as it happens. Moving up improves what you earn from that point on and never recalculates what you already earned.

How the money moves

• Earnings clear 14 days after the sale, then become withdrawable
• The clock runs per sale, so on steady sales money clears every day
• Minimum withdrawal is $20
• Withdraw to a Domzivo wallet, a Nigerian bank account in naira, or USDT on TRC20 or BEP20

The hold exists so a refund can be settled against a balance rather than chased after payment. Naira converts at the live rate with no markup applied on the way out.

Full detail is in the payout policy.

Items rarely take off at launch. They accumulate: a few sales, a few comments answered, an update, a review, better placement, more sales.

Sellers who quit at eight weeks quit right before the curve. The ones still selling after a year are usually the ones still shipping small updates.

Your level moves on its own

Levels are based on lifetime earnings, meaning your share after the platform fee across everything you have sold here. There is nothing to apply for, and levels never go down.

Your badge shows on your store and on every item. For a buyer choosing between two similar items, it answers the question they actually have: whether the person who will answer their support questions has done this before and is still here.

A second item is easier than the first

You have the packaging, the documentation habit, the licensing integration and the listing pattern already. Sellers with several related items also cross-sell to each other's buyers without doing anything.

Niches are not too small

"A booking system" competes with everything. "A booking system for driving instructors, handling test dates and block bookings" competes with almost nothing, and the people who need it will pay properly, because the alternative is a custom build.

Nothing here is exclusive, so keep selling wherever else you sell. See why sell with us for the commercial side, and the seller terms for the rules.