You built a portfolio site, a side project, or a personal tool that real people might use. You want it listed. Then you open the submission form and freeze: every example looks like a funded SaaS with "start free trial" language. Copy that tone onto a personal project and you sound like spam, even when the work is honest.
Agencies have a different spam pattern. We already covered how service businesses stay credible in list an agency or service site without looking like spam. This article is for makers listing portfolios, experiments, open-source demos, and one-person products. The goal is the same (pass review, earn useful clicks) but the proof and the CTA should look different.
Portfolio vs SaaS: write for what you actually shipped
SaaS listings sell a recurring product. Portfolio listings present a body of work or a specific build. Mixing those voices is the fastest way to look fake. If the site is a designer portfolio, say who you help and show selected work. If it is a shipped side tool with users, say what the tool does and who it is for. Do not invent a growth narrative you do not have.
Buyers browsing a project directory scan for clarity. They forgive small scale. They do not forgive hype. "Personal finance tracker I built for myself, now free for anyone" beats "AI-powered revolutionary platform disrupting money." The first line should name the artifact. The second line should name the audience. The third line can name the status: live, beta, archive, case study only.
Category choice matters. A portfolio that also sells freelance services sits between "project" and "agency." Pick the label that matches the page you submit. If the homepage is case studies and a contact form, you are closer to a portfolio or service listing. If the homepage is a product with signup, treat it as a product. For how buyers read those labels, see website list vs project directory: what buyers expect.
Proof that works for personal projects
GitHub and public repos
A public repo is strong proof when the README explains the project in plain language, shows a screenshot or GIF, and lists how to run it. Link the repo in the listing description if the directory allows external references, or put it one click from the submitted URL. Empty repos, private mirrors, and "coming soon" placeholders do the opposite of proof.
Commit history helps when it looks human. A single dump commit with no description is weaker than a short history of real fixes. You do not need hundreds of stars. You need evidence that the project exists outside the directory form.
Case studies and before/after
For portfolio work, a short case study outperforms a wall of logos. State the problem, your role, the constraint, and the outcome. If you cannot share client names, describe the industry and the deliverable. Screenshots of the live site or the design system beat adjective-heavy claims.
Side projects can use a mini case study too: why you built it, what broke, what you would change. That tone reads as maker honesty. It is the opposite of agency brochure copy, and reviewers notice.
Live demos over mockups alone
If the project is interactive, give visitors a path to try it without email gates when you can. A read-only demo, a public instance, or a short Loom-style walkthrough on the page reduces bounce. Static mockups are fine for design portfolios if the craft is the product. They are weak for tools that claim to "save hours" with no way to verify.
CTAs that fit personal work (skip "start free trial")
"Start free trial" signals a product company with onboarding, billing, and retention. On a portfolio or hobby tool it feels pasted from a template. Prefer CTAs that match the real next step:
- Contact or email for freelance and portfolio inquiries
- View on GitHub for open-source and code-first projects
- Open the live demo for interactive tools
- Read the case study when the page is documentation of past work
- Join the waitlist only when the listing admits early access
Keep one primary CTA. Multiple competing buttons ("Buy now," "Book a call," "Star on GitHub," "Join Discord") make a personal page look like a funnel farm. Soft secondary links are fine in the footer or a resources section.
Pricing language needs the same honesty. If the tool is free, say free. If donations keep the lights on, say that. If you freelance and the site is a portfolio, do not hide a productized service behind fake SaaS packaging. Reviewers reject listings that look like bait for a different business than the URL shows.
Spam patterns personal listings fall into
Keyword stuffing the title with every skill you have. Using a brand-new domain that only exists to collect directory links. Submitting ten near-identical microsites that are thin AI pages. Claiming "10k users" with no public footprint. Embedding affiliate cloakers as the project URL. Those patterns get filtered whether you are an agency or a solo maker.
Another quiet problem: submitting a Linktree-style hub as the project. Directories want a destination with substance. A hub of social profiles is not a project page. Same for a Google Doc that you might unshare next month.
Do not copy agency positioning if you are not selling retainers. "Full-service digital partner" on a student portfolio reads as spam. "Frontend portfolio focused on accessibility audits" reads as a real niche. Specificity is the anti-spam signal for personal work.
Finally, match the URL to the story. If the listing is about one tool, do not point to a personal blog homepage where that tool is a footnote. Point to the project page. If the listing is the portfolio itself, the portfolio root is correct.
A submission pass that keeps you out of the spam pile
Before you hit submit, read the listing out loud. Does every sentence describe something visible on the destination page within ten seconds? Remove claims that only exist in your head. Add one concrete proof: repo, live URL, case study, or named stack.
Check the tone once more against SaaS templates. Swap growth jargon for maker language. Replace "unlock synergies" with what the project actually outputs. Replace "enterprise-ready" with the scale you can support (solo maintenance, best-effort support, no SLA).
Then create an account and submit with the clean URL, the honest category, and a CTA that a stranger would believe. Update the listing when the project matures into a real product. Until then, sound like the person who built it, not like a fake startup press release.