Projects
A project is four things. The first two are the pair that get blurred together, and the difference decides whether a run stalls.
Facts are what is true about the product. The pack is what a form asks for. A missing fact costs you a platform you would have qualified for; a missing pack field stops you halfway through the form, with a tab open.
What is true about the product: its stage, how it charges, every audience and form factor it belongs to, whether there is a live URL, a pricing page, a privacy policy, a public repo, a square logo, a cover image, a demo video. Facts decide what the product qualifies for, and nothing else reads them.
What a submission form asks for: the name and URL, a tagline at three lengths, the long description, categories, a maker bio, a first comment, the logo, the cover, the gallery, the demo video. The pack is copy, in your voice, and it is what gets typed into the form.
The platforms for one project in the order they should be worked, each with a reason, plus the checklist of what has to exist before any of it can go out. It is free to write and free to rewrite, and it shows on your dashboard as something that ticks itself off.
One row per platform per project: the status, when it went out, the listing URL, when it goes live, and any note. This is the record that answers "did I ever submit to that one" without anybody having to remember.
Filling the pack
Assets are the commonest reason a run stalls: most platforms want a square logo and many want a cover image. The asset fields take a path on your machine as readily as a URL, because a submission form uploads a file rather than fetching one.
Pack copy gets pasted into a listing under your name, so it has to read as yours. The tools flag an em dash rather than rewriting your words. The submission pack page shows every field with its limits, and one of the guides is the prompt for finishing it before it blocks you.
NextLimits and errors