Submission guidelines

Write the pitch you wish other founders wrote.

A complete guide to a Code & Tell submission that gets approved on the first pass, ranks for the right buyers, and ages well as your product evolves. Written for the operator who would rather ship than read about shipping, but wants to do this once and do it right.

Before you start

You need three things in front of you. A working product with a public URL, a demo (a Loom or YouTube video, or at minimum a real screenshot), and a clear answer to a single question. Who, exactly, is this for? Not "businesses". Not "anyone with a problem like this". A specific role, at a specific kind of company, at a specific stage. If you can't answer that yet, the submission isn't the bottleneck. The pitch is. Spend an hour on the audience question first, then come back.

Most rejections we send aren't because the product is bad. They're because the audience is fuzzy. A fuzzy audience produces a fuzzy origin story, a fuzzy problem statement, and a listing that doesn't earn the right buyer. Fix the audience and the rest of the form gets easier.

The basics

Product name

Use the name you actually go to market with, not a working title. If your product has a parent brand and a sub-brand, use the sub-brand if that's what buyers will search for. We index the name for predictive search, so the spelling and capitalization you submit is the spelling and capitalization buyers see.

One-line tagline

Eight to one hundred and forty characters. The tagline is the first thing a buyer reads on a category page. It needs to do one job. Tell a buyer in plain English what the product is, in a way that lets the wrong buyer keep scrolling and the right buyer click. "AI-powered platform for modern teams" fails on every dimension. "Reconciles Stripe payouts against revenue accruals for finance teams at SaaS companies" passes.

Avoid buzzwords that aren't load bearing. "AI-powered" is fine if AI is what makes the product work. It's filler if the product is a CRUD app with a chatbot bolted on. Buyers can tell.

Website URL

The canonical product URL. Not a tracking link, not a pre-launch landing page. If the product is gated behind a sign-up wall, that's fine, but the page we link to needs to clearly describe the product.

Category

Pick the one that fits best. Not the one with the most traffic, not the one your competitor sits in. If your product genuinely spans two categories, pick the primary one and mention the secondary use case in the problem statement. Category misuse is the single fastest path to rejection because it breaks discovery for the buyers searching the categories you don't actually serve.

Pricing model

Free, freemium, paid, open source, usage-based, or enterprise. Pick the model, not the exact dollar amount. Buyers want to know the model before they click. If your model is more nuanced (free tier plus enterprise contracts, for example), pick the dominant model and explain the rest in the audience or problem section.

Logo URL

Optional but recommended. A square, transparent PNG hosted on your own domain works best. We don't crop or resize destructively, but extreme aspect ratios will look off in the directory grid.

Your pitch, the part that matters

Origin story

Two to five sentences. Why this product, why you, why now. The good version is concrete. It names the company you were at when you noticed the problem, the workaround you tried that didn't scale, and the moment you decided someone had to build the thing. The bad version is a marketing arc. "We believe every team deserves" is a bad version. "I was running RevOps at a forty person SaaS and spent every Friday afternoon stitching pipeline data across three tools, and the last spreadsheet I built before quitting is now this product" is a good version.

Write it in your voice. Don't let an agency write it. Don't let a model rewrite it. Buyers can tell, and so can we.

The problem you solve

One to three sentences describing the specific problem your product solves, for the specific audience your product serves. The test is whether a competing product could lift this paragraph and still describe themselves accurately. If yes, your problem statement is too generic. Rewrite.

Specifics that work well. The team or role that owns the problem today. The current workaround they use. The cost of the workaround in time, money, or risk. The way your product changes that. You don't need every one of those in every paragraph. You need enough specificity that the wrong buyer puts the page down.

Who is it for?

Be uncomfortably specific. "Heads of finance at fifty to five hundred person SaaS companies who close their books on a calendar month" beats "businesses". "Solo founders shipping consumer mobile apps in the first ninety days post-launch" beats "indie hackers". The specific version reads narrow and feels risky. The narrow version is exactly what filters the directory in your favor when a buyer who matches that profile shows up. The generic version dilutes the match and you get traffic that doesn't convert.

Best fit

Company size

Pick all that apply, but not all of them. A product that's genuinely fit for solo founders, mid-market, and enterprise probably isn't optimized for any of them. The chips are filters. Picking three sizes you serve well beats picking six you serve adequately.

Roles

Same logic. The roles you list show up as filters and as visible chips on your product page. They tell a buyer at a glance whether this product was built with their job in mind. Be honest. A product built for the head of sales isn't the same product as one built for an SDR, even if both technically use it.

Demo and links

YouTube or screenshot

Both is best. A two minute demo on YouTube plus a hero screenshot gives a buyer a fast read on whether the product looks like the kind of thing they would put in front of their team. If you only have one, pick the one that shows the product working in a real workflow rather than the marketing trailer.

If your product is API-first or developer-focused, a code-driven demo or a recorded terminal session counts. The point is to show the thing operating, not to win a video production award.

Affiliate or referral link

Optional. If you have one, paste it. We use it on every outbound click and you keep the referral revenue. We never insert an affiliate link of our own. We never claim revenue from your program.

What gets rejected

  • Marketing speak with no substance. If the listing could describe ten other products in your category, it's too generic.
  • Products that don't exist yet, or are pre-alpha with no working demo. Pre-orders, waitlists, and "launching soon" aren't products.
  • Listings that misrepresent pricing, capabilities, or maturity. We check.
  • Categories used as keyword stuffing. Pick the one that fits best, not all of the ones you wish you fit.
  • Submissions written by a third party that hasn't actually used the product. Agency-written pitches are usually obvious within two sentences.
  • Hidden affiliate or tracking redirects on the website URL. The link we publish has to be the canonical product URL.
  • Origin stories written in third person, marketing trailer voice, or pure feature-dump format.
  • Products that are clearly clones of an existing listing with no meaningful differentiation. Build something new or position the existing product differently.

Editing and versioning

You can edit any time from the founder dashboard. Edits to a pending or rejected listing update the listing in place and put it back into the review queue. Edits to an approved listing become a versioned update. The current public page doesn't change until the new version is approved, which protects buyers from in-flight rewrites and protects you from accidentally publishing an unfinished pitch.

Versioning is also how we keep the directory honest as products evolve. A SaaS that was a CRM in year one and is a revenue intelligence platform in year three shouldn't be able to silently rewrite the old listing as if the previous positioning never existed. The version history stays. The current page reflects what the product is today.

How long review takes

Most decisions land within a couple of business days. Faster if your submission is clean. Slower during launches or holidays. If you have a launch date and need a guaranteed turnaround, email us through the contact page and we'll do our best.

What happens after approval

Your listing goes live on the directory, on its category pages, and is indexed for predictive search. We notify you by email. The page is public from that moment, and any blog content we generate that references your category may link to your listing where it makes editorial sense. You can update view counts and listing performance from your dashboard.

What we never do

We never rewrite your origin story or your problem statement without your permission. We never sell better search ranking. We never insert an affiliate link of our own. We never share your contact details with other founders or buyers without your explicit opt-in. We never paraphrase your pitch into the same flat voice every other directory uses.

Picking the right category and industry

Two of the highest-leverage choices on the form are also two of the easiest to get wrong. Category describes what your product does. Industry describes who it's built for. A horizontal CRM picks the CRM category and the "horizontal" industry. A vertical SaaS for clinics picks the right functional category (scheduling, billing, EHR, whatever fits) and the healthcare industry. The mistake we see most often is founders picking a category that has more search volume rather than the one that fits, on the theory that more traffic equals more leads. It doesn't. Traffic from the wrong category bounces. Traffic from the right category converts.

If your product genuinely spans two categories, pick the dominant one and use the problem statement to flag the secondary use. If you serve two industries, pick the one your best customers come from today, not the one you wish they came from. The directory rewards founders who pick honestly, because honest picks compound across the search surface, the category page, and the industry page.

A worked example

To make the abstract concrete, here's a before-and-after on a listing we sent back for edits and approved on the second pass.

Before. Tagline: "AI-powered platform for modern revenue teams." Origin story: "We believe revenue teams deserve better tools. Our team has decades of experience in SaaS." Problem statement: "We help businesses close more deals." Audience: "Revenue teams." This listing got rejected. Every line could describe a hundred other products. Nothing in it disqualifies a wrong buyer.

After. Tagline: "Stitches Salesforce, Outreach, and Gong into a single weekly pipeline review for RevOps leads at twenty to two hundred person SaaS companies." Origin story: "I ran RevOps at a sixty person SaaS and spent every Friday afternoon copy-pasting between three tools to build the deck the CRO wanted on Monday morning. After the third quarter doing it I built the script that became this product. The first paying customer was the CRO who kept asking for the deck." Problem statement: "RevOps leads at growth-stage SaaS rebuild the same weekly pipeline view across Salesforce, Outreach, and Gong every week. We pull the data once, format it the way a CRO actually reads it, and ship the deck on Sunday night." Audience: "RevOps leads, Heads of Sales, and CROs at twenty to two hundred person B2B SaaS companies running a Salesforce, Outreach, and Gong stack." Approved on the next read. Wrong buyers self-select out. Right buyers know within ten seconds that this is theirs.

Common mistakes, in order of how often we see them

  • Audience too broad. "Businesses" and "teams" do not exist as buyers. Pick a role at a company size at a stage.
  • Origin story written in marketing trailer voice. If it starts with "We believe", rewrite.
  • Problem statement that could lift verbatim into a competitor's listing. If yes, it isn't a problem statement, it's a positioning placeholder.
  • Best-fit chips picked greedily. Picking every team size and every role tells the reviewer you haven't decided. Pick the ones you're best at.
  • Category picked for SEO rather than fit. The wrong category breaks search and starves the right category.
  • Demo missing or replaced with a marketing video. We need to see the product working, not the brand video.
  • Listing submitted by an agency or marketing manager rather than the founder. The dashboard is built around the founder. Listings without a founder in the loop go stale fast.

After approval, the first 30 days

Once your listing goes live, a few things are worth doing in the first month. Share the canonical Code & Tell URL of your listing on the launch channels you already use. Check the dashboard to see which buyers are landing on your page and which categories they came from. If a category is sending traffic that doesn't fit, your audience description probably needs tightening. If a category isn't sending traffic that should fit, the problem statement probably needs tightening. Editing is encouraged. Iterating is the point.

If your product changes meaningfully (new pricing tier, new ICP, repositioning), open the listing in the dashboard and submit a new version. The old version stays in the public history. The current page reflects what the product is today. We re-read versioned updates with the same eye we read the original submission.

How this fits the rest of the site

The submission is one piece of the system. The about page covers the philosophy and why the directory looks the way it does. The how it works page walks through the founder and buyer experiences end to end. The directory, categories, and industries pages are where your listing actually shows up. The blog is where we make broader arguments about how software gets bought. Reading two or three of those before you submit is fifteen minutes well spent.

Ready to submit?

Open Submit a product, walk through the form, and ship it. If you have questions before you start, the how it works page covers the full lifecycle. If you want to read more about why the directory is built this way, the about page covers the philosophy.