Buyers are buying clarity, not vibes
A polished marketing screenshot with a hollow README wastes everyone's afternoon. Listing-ready kits answer four questions in under five minutes of reading:
What problem does this solve? What stack is included? Which environment variables are required versus optional? What are the exact steps from clone to first run?
If those answers are missing, price becomes irrelevant. Serious buyers bounce. Reviewers bounce harder.
Marketplace trust compounds. One clear listing teaches buyers that Twenty kits come with a runnable story. One hollow listing teaches them to assume the opposite.
The file set that signals seriousness
Twenty's listing quality audit looks for the boring essentials on purpose. A README that explains how to run the project. Real source code, not an empty shell. An `.env.example` with placeholders instead of live secrets. Prefer a LICENSE, a .gitignore, and a language manifest such as `package.json`.
Those files are not bureaucracy. They are how a stranger reconstructs the author's laptop state without a Zoom call.
Write the README for a tired buyer at 11pm. Lead with prerequisites, then install, then env, then migrate, then run, then where to click. Save architecture essays for later sections.
Setup instructions on the Twenty product page are required separately from the README. The marketplace field is what buyers see next to the Buy button. Treat it as a first-class artifact: env names, migrate command, webhook path, and first-run URL.
ZIP hygiene failures we see constantly
Shipping `node_modules` bloats archives and hides supply-chain surprises. Shipping `.next`, `dist`, or `build` tells buyers you packaged output instead of source. Committing `.env` or `.env.local` is a hard stop - even if the keys are "just test keys."
Sellers sometimes include screenshots inside the ZIP. Prefer uploading screenshots through the listing UI so the archive stays buildable source.
Also watch for accidental vendor lock-in in sample env files: hard-coded personal Stripe price ids, private Slack webhooks, or API keys that still work. Placeholders should look like placeholders.
What "good enough for review" feels like
A reviewer should be able to skim the README, copy `.env.example`, and understand which third-party dashboards they must visit. They should not need to reverse-engineer package scripts to find the database step.
If your kit is a module rather than a full app, say that in the first paragraph. Buyers who expected a complete SaaS shell will refund; buyers who wanted an auth drop-in will thank you.
Self-check in two minutes
From the repo root:
git ls-filesPaste that list into the free repo health scanner. It applies the same listing-quality rules used in review, plus ZIP hygiene checks, without uploading your archive. Full malware scanning still runs when you submit a real listing for human review.
If you are evaluating kits as a buyer, skim Choosing a kit and estimate hours with the setup-time estimator before you pay. A kit that cannot explain itself in writing rarely becomes easier after checkout.
