How to write a strong proof-of-effort project post

Make the current state legible

A strong early-stage post does not need to sound bigger than it is. It should explain what exists, what has been tried, what evidence has been collected, and which question the founder is trying to answer next.

Start with plain language. Name the user, the painful workflow or unmet need, the product shape you are exploring, and the next milestone. A reader should be able to understand the project without decoding pitch language or private context.

Keep the project description separate from proof of effort. The description answers what the project is and who it serves. Proof of effort answers why a serious collaborator should believe the founder has done real work.

Use proof that required effort

Useful signals are specific and recent. If the signal is still weak, say so plainly and separate confirmed evidence from assumptions.

Proof is not limited to revenue. In early projects, credible effort can be a prototype, a manual workflow, structured user interviews, a technical spike, domain research, or a small distribution test. The point is to show that the founder has left the idea stage and can describe what was learned.

Avoid pretending that soft signals are stronger than they are. A waitlist from friends is different from repeated inbound demand. A Figma mockup is different from a production system. Honest stage-setting helps applicants decide whether they are excited by the uncertainty.

• Customer calls or interview notes
• A prototype, repository, or design exploration
• Manual workflow tests, waitlist conversations, or letters of intent
• Revenue or distribution access only when it is real and current

Write the post in two layers

Use the public layer for the problem, user, project stage, and role context. Save sensitive customer names, unreleased code, detailed financials, private roadmaps, and investor materials for accepted-only disclosure.

A useful public post still has enough detail for filtering. Include country or operating region, sector, current tech stack, and the kind of collaborator needed. If the project is international, explain whether that means remote collaboration, cross-border customers, or region-agnostic software.

• Project description: product, user, problem, and stage
• Proof of effort: what was built, tested, learned, or validated
• Role context: why help is needed now and what progress looks like
• Private material: code, datasets, customer lists, and sensitive strategy

Connect the evidence to the role

A collaborator should understand why their work matters now, what milestone the project is trying to reach, and what would count as progress in the first few weeks.

Share enough context for someone to evaluate fit, while keeping customer names, unreleased code, sensitive financials, private repositories, and detailed roadmaps behind accepted-only access.

If the role is technical, state what already exists and where the technical risk sits. If the role is commercial, explain the audience, channel, and evidence from conversations or tests. If the role is design, operations, or research, show how the work would reduce a concrete uncertainty.

End with a clear next step. Applicants should know whether you want a short application, a working session, a trial milestone, or a conversation about long-term partnership.