Sunsetting a Project Responsibly

Everything that is made eventually stops being maintained. A project that mattered to you for years may become a project you cannot keep up. A product may lose its audience. A life may change. How you handle the ending shapes what people remember, and it is a skill worth learning before you need it.

This guide is about closing a project with care. It offers a plain sequence: decide, tell people early, let them take what is theirs, choose between handing on and archiving, handle data properly and say goodbye well.

Endings are normal

Software and products have life cycles. In the business world, the end of a product's life is a recognised stage that organisations plan for, with notice to customers, support for a period and a clear final date. Maintenance, the work of keeping software working after its release, is a continuing cost, and when the cost outweighs the reward, stopping can be reasonable.

For a small maker, the same applies, with less ceremony. The measure is not whether you ended it but how.

Decide: pause, hand over, archive or close

There are several different endings. Be clear which one you are choosing.

Pause. You stop active work but keep the project running as it is. Good for a stable tool that needs little. Say so, so nobody expects updates.

Hand over. Someone else takes on the project. Good when there is a trusted successor.

Archive. You stop work and leave the code and page available, clearly marked as no longer maintained. Good for open projects others may fork.

Close. You shut the service down. Good when the project depends on running infrastructure or handling data.

Each requires different steps. Write down which one you are doing and why.

Tell people early

The kindest thing is early, clear notice.

How early? It depends on how much people rely on it. A hobby toy may need a few weeks. A tool that people use for work deserves months.

Where? In every place people look: your README, your page, an email to users, the issue tracker, any listing and your social posts. Don't expect everyone to see one announcement.

What to say:

1. That the project is ending, and the date.
2. Why, honestly and briefly. You do not need to justify it at length, but a straight reason is respectful.
3. What will happen on the date: will the service stop, or will the code remain?
4. What users should do: export, switch, fork.
5. Where to ask questions.
6. Thanks.

Avoid vague phrases such as "winding down at some point". Give a date and keep to it.

An example: "After four years, I am closing this project on 30 June. The service will stop working on that date. Until then, you can export your lists from the settings page. The code stays available under its licence, and you are welcome to run your own copy. Thank you to everyone who used it and helped."

Let people take their things

Users' data belongs to them. Make it easy to leave with it.

• Provide an export, in an open, usable format such as plain text, CSV or JSON. Test it.
• Explain how in plain steps.
• Keep it available for the whole notice period, and ideally a little beyond.
• Include everything that matters, not just the main records.
• Offer help to people who struggle.

UK data protection law includes a right to data portability in some circumstances, allowing individuals to obtain and reuse their personal data across services. Whether or not the law requires it in your case, the principle is good practice: do not hold people's data hostage.

If you cannot build a full export, offer to supply data on request, and say so.

Point to alternatives

Help people move on. Where other tools do the same job, list a few, honestly, without paid promotion. If you know that a particular tool can import your export format, say so. If there is a community fork, link to it.

This is not an admission of failure. It is a service to the people who trusted you.

Handing over

Passing a project to a successor can give it new life. Do it carefully.

• Choose someone trustworthy, with the skill and the time. A long track of contributions is a good sign.
• Tell users who is taking over, and why you trust them.
• Transfer the pieces: the code repository, domain, accounts, hosting, documentation, passwords (through a secure method), and any customer relationships and data.
• Check the licence. Make sure the new maintainer has the rights they need.
• Be clear about data. Transferring user data to a new person is a decision with privacy implications. Tell users and, where required, get consent or give them the chance to leave first.
• Offer a handover period where you stay available for questions.
• Update the README and your page with the new contact and status.
• Let go. A good handover means the new person decides.

If the successor wants to change the direction, that is theirs to explain.

Archiving

For open projects, archiving is often right.

• Update the README at the top: "This project is no longer maintained. The last release was this version, in this month."
• Say what to do: fork it, use it as is, switch to an alternative.
• Keep the licence in place, so others can lawfully use and modify the code.
• Close or lock the issue tracker, or state that issues will not be answered.
• Tag a final release, with a note on known issues.
• Mark the project as archived where the hosting platform offers it, so it is read-only and clearly labelled.
• Leave the site up with a notice, or redirect to a static page with the information.

Open licences exist to allow this kind of continuation. The open source definition includes freedoms that let others redistribute and modify the code, which is why an archived open project can live on in forks.

Closing a service

If the project runs infrastructure or handles data, closing takes more care.

Plan the shutdown. Decide the date and the steps: stop new sign-ups, switch to read-only, stop the service.

Handle data properly. Decide what to delete, what to keep and for how long. Personal data should not be kept longer than needed. Tell users what you will do, and delete securely when you say you will.

Settle money. If you charged, stop billing in good time, and handle any amounts you owe or are owed in line with your terms and the law. Take advice if unsure.

Tell partners and providers. Cancel subscriptions, domains and services in the right order. Do not let a forgotten domain expire in a way that someone else could take over and impersonate the project.

Think about links. Many people will have linked to your page. Keep a simple page at that address explaining what happened, or redirect to a relevant place.

Keep your own copy of everything you need for records and for the code you may want to reuse.

Say a proper goodbye

A final note matters.

• Thank people by name where appropriate.
• Say what the project achieved. It did something.
• Be honest about why it ended.
• Share what you learned. Others will benefit.
• Say what you will do next, if you like.

A short, warm post is enough. It leaves people feeling respected.

Look after yourself

Ending a project can bring grief, relief or both. It is normal.

• Don't rush the announcement in a low moment. Write it, sleep, read it again.
• Expect mixed reactions. Some will be sad, some irritated, some silent.
• Accept kindness.
• Don't take everything personally.
• Give yourself a rest before starting the next thing.

A project's end is not a verdict on you.

A sunsetting checklist

• I have decided: pause, hand over, archive or close.
• I have chosen a date and told people clearly and early.
• Users can export their data in an open format.
• I have pointed to alternatives.
• The README and page show the status at the top.
• Licences are clear.
• Data decisions are made and communicated.
• Billing, domains and accounts are handled.
• I have written a thank-you.
• I have kept what I need.

Common mistakes

• Vanishing without a word.
• Short notice for important tools.
• No export.
• Leaving the page promising things.
• Forgetting domains and billing.
• Keeping personal data forever.
• Handing over without telling users.
• Pretending it is not ending.

On this site

If you list a project here and it ends, update your entry from your account so visitors see the truth, and the contact page is the way to ask for help. The terms and privacy pages explain how listings and data are handled, and the launches page shows how other makers present their projects.

The short version

Choose your ending: pause, hand over, archive or close. Give early, clear notice with a date, let people export their data in an open format, point to alternatives, transfer carefully if you hand over, mark archived projects clearly and keep the licence, handle data, billing and domains properly, and say a warm goodbye. How a project ends is part of how it is remembered.