1. One rule sits above the others
Everything below comes from a single idea: the customer comes first. Before your roadmap, before our commission, before anyone’s pride in a piece of code. We are customer first, and if you sell here you need to be too.
That is not a slogan for a wall. It decides what we list, what we turn down, and what we remove. The practical version is this: when a customer’s interest and your convenience pull in opposite directions, side with the customer. Do that and we will back you, including when it costs you something.
2. We will notice
This is said plainly rather than as a threat. The people reviewing your product have built themes and plugins, run a marketplace, hosted other people’s sites and answered support tickets at two in the morning. We are web and design people. We have made most of the mistakes on this page ourselves.
So we notice when a settings screen was designed and when it was merely accumulated. We notice a demo that only works with the sample content loaded. We notice a changelog that has said “bug fixes and improvements” for eleven releases running. We notice screenshots from two versions ago. We notice when the marketing page promises something the plugin does not do yet.
None of that is a trap. It is simply the level of attention your product will get here, and it is the same attention a good customer gives it in their first hour.
3. Security is the entry fee, not a feature
Every product here that ships code carries a free Patchstack managed disclosure programme, enrolled per product, and we check the link before anything goes on sale. The reasoning is in Part C of our terms, clause 6.6, and it is worth reading rather than skimming.
The short form: all software has vulnerabilities. The question is never whether one exists in your product, only how it reaches you when somebody finds it. Without a disclosure route a researcher has poor options, and the worst of them ends with your customers compromised and you finding out from Twitter.
Beyond the programme itself, what we look for:
- Reports treated as gifts. Someone spending their evening finding a flaw in your code and telling you privately has done you an enormous favour. Thank them, fix it, credit them.
- Capability and nonce checks on every write. The number of products that authenticate and then forget to authorise is genuinely depressing.
- Output escaped, input sanitised, queries prepared. Unglamorous and non-negotiable.
- No obfuscated code. If we cannot read it, we will not sell it. Licence enforcement is fine; a base64 blob is not.
- No phoning home without consent. Tell the user what you collect and let them decline. Silent telemetry is a breach of trust and often of law.
- Dependencies kept current. A four-year-old bundled library is your vulnerability, not the library author’s.
- A real update path. A security fix nobody can install is not a fix.
4. Confidence is built before the buy button
A customer parts with money on the strength of a page. Everything on it is a promise, and every promise you cannot keep comes back as a refund, a support ticket, or a quiet decision never to buy from you again.
We offer a 14-day no-quibble refund on everything. That is deliberate, and it has a consequence for you: if your listing oversells, the refund rate tells us before any review does. A product that converts well and refunds badly is a product with a description problem.
So write the listing you would want to read:
- Say what it does not do. The single most trust-building sentence on any product page. It costs you a few sales and saves you every angry one.
- Real screenshots of the current version. Not mockups, not a marketing render of a screen that does not exist.
- Requirements stated up front. PHP version, WordPress version, anything the product needs alongside it, anything it conflicts with.
- Licence terms a human can parse. How many sites, how long for updates, what happens when it lapses. “One year of updates and support, the product keeps working afterwards” is clear. Vagueness here is the most common cause of a furious customer.
- A changelog that says something. What changed, what broke, what a user has to do about it.
- No dark patterns. No countdown that resets, no pre-ticked upsell, no renewal price hidden three clicks deep. We will find it, and we will ask you to remove it.
5. The first five minutes decide everything
Nobody buys a plugin because they want a plugin. They buy it because they want a problem gone. The gap between activation and that problem being gone is the single number that governs your refund rate, your support load and your reviews.
- Work on activation. Ship defaults that are correct for the common case. A product that does nothing until fourteen settings are configured has handed its job to the customer.
- One obvious next step. If setup is genuinely needed, make the path to it unmissable and short.
- Error messages that say what to do. “Something went wrong” is not a message, it is a shrug. Say what failed, why, and the next action.
- Do not nag. No review prompt in week one. No upgrade banner on every admin screen. No dismissed notice that comes back next week.
- Make uninstalling clean. Leave the database as you found it, or offer the choice. How you behave on the way out is remembered.
6. Interface craft
This is the part most products treat as optional and it is the part that separates a tool people tolerate from one they recommend.
- Use the WordPress admin components. Your settings screen does not need to be a brand experience. Customers already know how WordPress works, and every departure from it is something they have to learn for no benefit.
- Scope your CSS. A plugin that restyles the whole admin, changes the base font size, or drops a site-wide notice is behaving as though it is the only thing installed. It never is.
- Left align reading text. Centred paragraphs look tidy in a mockup and are measurably harder to read at length, because every line starts in a different place. Centre a short heading if you must. Never centre a paragraph somebody has to read.
- Consistency beats cleverness. Pick a spacing scale, a type scale and a set of colours, then hold the line. Most interfaces that feel amateur are not ugly, they are inconsistent.
- Respect the front end. Do not inject markup into a theme’s layout without a filter to turn it off, and do not assume your styles win. Somebody has spent a long time on that design.
7. Accessibility is quality, not compliance
We hold this site to WCAG 2.2 Level AA and we publish where we currently fall short, because claiming perfection would be worse than useless. We expect the same honesty from the products we sell.
Plenty of developers use screen readers, keyboards and magnification. Your admin screens are somebody’s workplace. The basics carry most of the weight: every control reachable by keyboard, a visible focus style, labels properly associated with inputs, contrast you have measured rather than guessed, and never colour alone to carry meaning. If your product outputs markup on the front end, that markup becomes your customer’s accessibility problem, so make it good markup.
8. Weight and performance
Your product shares a site with twenty others. Behave accordingly.
- Load assets only on the screens that need them, front end and admin.
- Do not autoload large options. It is a tax on every single request, including the ones that have nothing to do with you.
- Cache expensive work, and give people a way to clear it when it goes stale.
- Test with a realistic amount of data. Everything is fast with twelve rows.
9. Support is part of the product
Tickets about your product come straight to you rather than into a general queue, because you are the person who can actually fix it. Our terms ask for a response within 24 hours. Tone matters as much as speed: the customer is not stupid, they are stuck, and often your interface is why.
Treat the support queue as your best source of product research. Three people asking the same question is not three support tickets, it is one design fault with a trail leading to it.
10. What gets turned down
Said plainly so nobody wastes ten working days finding out:
- No active disclosure programme for that specific product.
- Obfuscated or unreadable code.
- A description that does not match what the product actually does.
- Code you do not own or have no right to license.
- Data collection the user is not told about.
- Dark patterns in pricing, renewals or upsells.
- Abandonware. If the last real update was two years ago, it is not a product, it is a liability with a price on it.
11. What we do in return
We take the money, so the sales tax is ours. As the marketplace receiving the payment we are the party treated as taking the sale for tax purposes, which means VAT, GST and US sales tax are ours to charge, collect and remit in the countries we sell into. They are not yours to calculate, file or register for. You are not registering in twenty jurisdictions to sell a plugin.
What stays with you is your own tax. Personal and corporate tax on what we pay you is your responsibility where you are based, and we do not account for it, do not withhold it and do not file anything for you. Treat our payouts exactly as you would income from any other customer.
You keep the relationship with your customer. We sell on your behalf; we do not buy your product and resell it as ours. What we list is what our vendors choose to offer, and the point of the range is that our community finds what it needs in one place rather than across a dozen sites. We are the storefront and the reach, never a middleman who inherits your list. You receive 70% of the sale price excluding VAT, less gateway and currency conversion charges. We handle cross-border selling, the checkout, the refunds and the promotion.
And we read your product properly before we sell it, which is worth more to you than it sounds. An honest second opinion from people who have shipped is not easy to come by.
12. Talk to us first
If you are unsure whether something fits, ask before you build around the assumption. We would far rather have a five-minute conversation now than turn down a good product for a reason you could have designed out. Get in touch, and read Part C of the terms before you submit.