Skip to main content

Built by makers, shipped in public

Sign in

Ways a Side Project Can Earn: Tip Jars to Paid Tiers

Growing Up · 10 min read ·

Not every side project needs to become a business. A survey of honest ways to earn from one, from donations to paid tiers, with the trade-offs of each.

Illustration: A workshop bench with five little labelled jars along a pegboard shelf: Tips, Sponsor, Paid tier, Services, Related, each with a stencilled tag, safety orange on kraft brown

Making things for the love of it is a fine reason to make them. But time is not free, hosting is not free and the glow of seeing someone use your work can fade when the bill arrives. At some point, many makers wonder whether the project could pay for itself, or a little more.

It can, in several ways. None is magic, and most bring in modest sums. This guide surveys the common routes, from a tip jar to a paid tier, with an honest look at what each asks of you. It does not promise income. It helps you choose a way that suits the project, your audience and your temperament.

Start with the goal

Be clear what "earn" means to you.

  • Cover costs. Hosting, domain, tools.
  • Pay for your time a little. A reward for the evenings.
  • Fund growth. Enough to improve it.
  • Replace a salary. A much bigger goal, which changes everything.

Each goal needs a different scale of effort. A project that covers its costs can stay a joy. One that must pay a salary becomes a business, with all its demands.

Write the goal down. It guides every choice below.

Route one: donations and tip jars

The simplest. You ask users who value the project to give voluntarily.

Software offered free with a request for voluntary donations is sometimes called donationware. The principle also applies to any project: give it away, let people support it.

Strengths: easy to set up; no barrier for users; no change to the project; suits open work.

Weaknesses: most people do not give; income is unpredictable and usually small; it can feel awkward to ask.

Doing it well:

  • Make the request visible but not pushy: a short line and a link.
  • Say what the money covers, honestly. "Covers hosting and a bit of my time."
  • Thank donors, without making a fuss.
  • Do not promise special treatment for donors unless you intend to give it.
  • Do not make users feel guilty.

Route two: pay what you want

A related approach in which the buyer chooses the amount, sometimes with a minimum. It relies on goodwill and on people's sense of fairness.

Strengths: low friction; some people pay more than you would have asked; suits creative and community-minded projects.

Weaknesses: many pay little or nothing; income varies; hard to forecast.

Doing it well:

  • Suggest a range, so people have a guide.
  • Make the free option clearly acceptable, if it is.
  • Explain what the money supports.

Route three: sponsorship

Individuals or companies support the project regularly in exchange for thanks, recognition or, sometimes, influence.

Strengths: regular income, possibly larger amounts from companies that depend on your work; fits open projects.

Weaknesses: requires visibility and trust; sponsors may expect things; it can create conflicts of interest if you favour sponsors.

Doing it well:

  • Be clear what sponsors get, and what they do not. Recognition is common; control over direction is a different matter.
  • Keep your decisions independent, and say so.
  • Disclose sponsorships openly.
  • Thank sponsors publicly if they agree.

Route four: a paid tier

You keep a useful free version and offer a paid version with extras. The freemium model is built on this: a basic product free, premium features paid. Open-core, in which a core is open and some additions are proprietary or paid, is a cousin of it.

Strengths: predictable income if it works; scales with users; lets many people use the free version.

Weaknesses: you must decide where to draw the line; the free version has costs; support burdens increase; users resent features moved behind a paywall.

Doing it well:

  • Make the free version genuinely useful.
  • Put things behind the paywall that cost you more to provide or that serve heavier users.
  • Never take away what was free without long notice and a good reason.
  • Show prices clearly, in one place, and link to them from elsewhere, so a change updates everywhere.
  • Offer a trial of the paid version.
  • Be clear about what happens when someone stops paying: do they lose access, keep their data, keep a basic version?

Route five: services around the project

You offer your skills: setup, customisation, training, consulting, hosting or support.

Strengths: companies pay for expertise; income can be good per hour; you learn what users need.

Weaknesses: it trades time for money; it can swamp the project; clients make demands.

Doing it well:

  • Set boundaries and a minimum.
  • Write simple terms.
  • Keep the project's roadmap yours.
  • Do not neglect the free users.

Books, courses, templates, merchandise, workshops, a newsletter with a paid edition. They sit beside the project and draw on what you know.

Strengths: you earn from knowledge, not only code; they can reach people who will never install your project.

Weaknesses: they are projects in themselves, with their own work.

Doing it well:

  • Make something genuinely helpful.
  • Be honest about what is free and what is paid.
  • Do not hold back essential documentation to sell a book.

Route seven: a listing and visibility

A listing on a launch platform is not income, but visibility can lead to income through any of the routes above. A free listing gives a public page. Some platforms also sell paid placements. Think of them as marketing costs and weigh the benefit. Here, money can buy a labelled placement but never a vote or a place in the community ranking, and the platform keeps community voting and verified data apart from anything paid.

What every route needs

Honesty

Say plainly what you charge for and what you do not. Never promise what the project cannot deliver. Advertising rules in many places expect claims to be true and prices to be clear. If you make claims about performance, security or support, be able to back them up.

One place for prices

Keep every price in one place, such as a single page or setting, and link to it from elsewhere. When you change it, everything updates. Typing numbers into many pages invites mistakes.

A way to take payment properly

Use a reputable payment provider so you never handle card numbers yourself. Issue receipts or invoices. Keep records.

Once money flows, you may need to register as self-employed or as a business, keep records and pay tax. Government guidance explains how to register as a sole trader and what to keep track of. Rules differ by country and by amount, and you should check yours, or take advice. Do not ignore this because the sums are small.

Terms and privacy

If you take payments or handle personal data, write simple terms and a privacy note in plain words.

Support

Decide what support payers get, and say it. "Email support, replies within a few working days" is fine. Do not offer what you cannot sustain.

How much can you expect?

Be sceptical of stories of easy income. Most side projects earn little. Many earn nothing. A few earn more than expected. There is no reliable average to quote, and published figures are chosen to impress. Treat your project as an experiment: try a route, watch the results and adjust.

Set a modest target for the first months and a date to review.

Mixing routes

Routes combine well.

  • A free open project with a tip jar and paid support.
  • A free tool with a paid tier and a related course.
  • A hosted version for those who do not want to run it themselves, plus sponsorship for the open core.

Start with one. Adding routes adds work.

Protect the project and yourself

  • Do not let money change what the project is for without telling users.
  • Do not neglect free users who made it worth paying for.
  • Do not overpromise to win payment.
  • Keep your life in balance. Income is not worth burnout.
  • Be ready to say no to requests that distort the project.

A decision in five questions

  1. What do I want the money to do?
  2. Who benefits most from the project, and could they pay?
  3. What can I offer without harming what is free?
  4. How much extra work am I willing to take on?
  5. How will I tell users honestly?

Answer these, and the right route often becomes plain.

On this site

The pricing page shows how a plain price list looks, the submit page lets you list a project on a public page of its own and the launches page shows how other makers present theirs. The developers page describes the free API and MCP server, and the founders page introduces the people behind this place.

The short version

A side project can earn through tip jars, pay-what-you-want, sponsorship, a paid tier, services around it or related products, each with trade-offs. Start from your goal, choose the lightest route that fits, keep prices in one place, be honest about what is free and paid, take payments properly, check your registration and tax duties and never take away what was free without notice. Earn in a way you would be happy to explain.

Questions and answers

Can a side project earn money without becoming a full business?
Yes. Donations, a paid tier, sponsorship or related products can bring in modest income while the project stays small.
What is pay-what-you-want?
A pricing approach in which the buyer chooses the amount, sometimes with a minimum, relying on goodwill.
What is donationware?
Software offered free with a request for voluntary donations.
Do I have to register anything when I earn?
Often yes. Rules on registering and paying tax differ by country and by amount, so check the government guidance for where you live.
How do I keep earning honest?
State what is free and what is paid, keep prices in one place, do not mislead and keep your promises.

Sources

Related guides

Ask us