Example milestone plan
An example plan for a open-source tool dream with a goal of $8,000. Backers fund the whole goal, but each milestone's money stays held until you post the proof and Backers release it.
Milestone 1
$2,000 · 25%
Publish the technical scope
Post a repository link, a design note and a minimal runnable example explaining the problem and the planned interfaces.
Milestone 2
$2,800 · 35%
Implement the core tool
Share tagged source changes, automated test output and a recorded example showing the main function with sample inputs.
Milestone 3
$2,000 · 25%
Check compatibility and docs
Upload a compatibility matrix, fresh installation results and draft documentation tested against the current version.
Milestone 4
$1,200 · 15%
Prepare contributor release
Post release notes, contribution instructions and an issue triage plan with links to the final examples and known limitations.
- 01
Make every step provable
A milestone only works if a Backer can look at your proof and agree it is done. 'Buy equipment' is weak; 'equipment bought, receipt and photo posted' is strong.
- 02
Order by risk
Put the cheapest, fastest step first. Each released milestone proves you deliver and funds the next. Leave the biggest amount for the step where most of the work is already done.
- 03
Keep the amounts honest
Milestones must add up exactly to your goal. Price each step from real quotes, include tools and services, and split any step that is too big to prove in one go.
Risks to plan for
- R1
Dependencies break compatibility
An upstream change can make installation fail even when the tool code is unchanged. Define supported versions early and budget for automated compatibility checks and fixes.
- R2
Maintainer workload expands
Support requests can displace planned development work. Limit the funded feature scope and reserve the final milestone for contribution guidance and a manageable issue triage plan.
- R3
Examples hide setup problems
A tool may run only in its creator’s environment. Include fresh installation tests on the supported setups and fund documentation fixes before presenting the release as complete.
Budget example
A typical cost split for a open-source tool dream in New York, shown in USD. Backers are charged the equivalent in US dollars.
Example goal
$8,000
- Core engineering and maintenance$5,600 · 70%
- Test infrastructure and hosting$800 · 10%
- Documentation and worked examples$800 · 10%
- Release and community support$800 · 10%
What you receive
- Backers give
- $8,000
- Platform fee (15%)
- −$1,200
- You receive
- $6,800
How Backers are protected
14-day review per milestone
When proof is posted, each Backer has 14 days to release their share or ask for more. Money not released in time goes back to the Backer.
15% fee, deducted — never added
Backers pay exactly what they choose. The 15% fee comes out of each backing: $100 gives the Dreamer $85. The fee is kept if money is returned.
Gifts, not shares
Backings are gifts. No shares, equity, interest or repayment, and Dreamers keep full ownership. Nothing on cohero is an investment or a loan.
Questions and answers
Why fund an open-source tool if anyone can use the code?
The dream can fund the engineering, testing and documentation needed to make public code useful. Explain the specific work being supported and provide repository evidence rather than implying Backers buy exclusive access.
What counts as proof when the work is mostly maintenance?
Link to resolved issues, source changes and test results that show the supported versions still work. Include a reproducible example or installation check so Backers can assess maintenance beyond a list of commits.
How many milestones should a open-source tool dream have?
Three to six works for most dreams. Fewer gives Backers little to review; more than seven makes each step feel small. The example plan on this page uses four.
Ready when you are
Sign in or create an account to publish a dream or back the ones you believe in.
Sign in / Create account