SubmitX — Devpost project page

Inspiration

Launching an indie product means submitting it to a hundred directories, and there is no way around it: directories are where the early backlinks and the first trickle of traffic come from. Every founder does the same thing — opens a spreadsheet of directory URLs, fills in the same product description forty times, and gives up somewhere around number twelve.

Two things bothered me. First, the work is pure repetition with no judgement. Second, there is no feedback: after filling forty forms you have no idea which ones actually published you.

SubmitX came from treating directory submission as an engineering problem rather than a chore.

What it does

Submit a product once, and it handles the submission across a curated network of AI and startup directories.

• Automated submission across a hand-picked directory list
• A launch board for coordinating a launch instead of tracking it in a spreadsheet
• Verified backlinks rather than assumed ones
• A report of what was submitted where, and what actually went live

How I built it

The naive version of this product is a form-filling bot, and a form-filling bot does not work. Real directory forms differ wildly, so the architecture is built around handling that difference.

1. Three-way classification. Every directory is classified by what submission actually requires: a plain form that can be submitted directly, a form behind a login, or a manual process. Pretending everything is automatable produces silent failures; classifying honestly produces a realistic report.

2. Form probing. For direct-form sites, the crawler loads the page and extracts the field structure — labels, types, option lists, required markers. The mapping from product fields to form fields is the core problem, and it is solved with a rule layer plus a model fallback for anything the rules do not cover.

3. Idempotency. Submitting twice to the same directory should be detected and skipped, not repeated. Every submission is keyed by product plus directory and checked before any work starts. Without this, a retry after a partial failure creates duplicates that get accounts flagged.

4. Verification. A submission is not a backlink. After submitting, the system checks whether the listing actually exists, which is what makes the report trustworthy — and which is also the part that most tools skip.

5. Plan-level quota accounting. Different plans allow different submission volumes, which has to be enforced at the point of work, not at the point of the API call, or users end up with partial batches.

Challenges I ran into

Silent failure is the default failure mode. A form submission that appears to succeed and actually did nothing is far worse than an error, because the user believes the work is done. I had to build verification into the pipeline rather than treating it as a reporting feature.

Every directory is a different shape. Labels are inconsistent ("Your name" versus "Contact person"), dropdowns have hundreds of options with no search, and some sites hide the real form controls behind custom widgets. The rule layer handles the common cases; the model handles the long tail. Getting that split right is what keeps the cost per submission reasonable.

Automating submissions gets you blocked. Some sites forbid automated submission outright, and detecting that after the fact is too late. Direct submission is restricted to sites where it is acceptable; everything else is classified for manual handling. This is a smaller number than it first appears, and being honest about it makes the product more useful rather than less.

Accomplishments that I'm proud of

• Getting verification genuinely working, so the report reflects reality instead of hope.
• The idempotency layer. Duplicate submissions are a permanent, invisible problem otherwise.
• Classifying honestly instead of claiming universal automation. The product tells you what it cannot do.

What I learned

A batch job's real cost is its failure modes. Submitting to a hundred sites is easy when everything works. The engineering is in the tenth site behaving differently, and in making sure that does not corrupt the other ninety-nine.

Verification is a feature, not a report. Users do not want a log of what the bot did. They want to know what exists on the internet now. Those are different questions and only the second one is useful.

What's next for SubmitX

• Handle the login-required sites. A meaningful share of directories need an account first, and doing that cleanly and safely is the biggest remaining gap.
• Indexing checks. A backlink is not a ranking signal until it is indexed; checking that is the natural next layer of verification.
• Directory health monitoring. Directory forms change and URLs die. Tracking which ones still work keeps the report honest over time.
• Rank tracking. Show whether the backlinks actually moved the needle, since that is the reason anyone does this.

Built With

• react