How to Retire a SaaS Feature While Building in Public

The short answer

To retire a SaaS feature responsibly, identify who depends on it, test how they’ll complete their work afterward, and give them a clear transition plan. Then share the reasoning publicly. A useful retirement update explains what you learned, what’s changing, and how you’re helping affected customers through the change.

To retire a SaaS feature responsibly, identify who depends on it, test how they’ll complete their work afterward, and give them a clear transition plan. Then share the reasoning publicly. A useful retirement update explains what you learned, what’s changing, and how you’re helping affected customers through the change.

For founders building in public, removing a feature deserves the same care as launching one. Your public record should help people understand how the product evolves, including the decisions that make it smaller.

Find out what would break for the people still using it

Low usage is a reason to investigate a feature. It doesn’t tell you enough to remove it.

A feature used once a month might support a customer’s most important monthly task. Another might have frequent clicks because people keep trying to make it work.

Before deciding, write down:

• Which accounts use the feature and how recently.

• What those users are trying to accomplish.

• What they would have to change if it disappeared.

• Whether your proposed replacement supports that work.

Look beyond activity counts. Ask affected users to walk you through the last time they used the feature. Pay attention to the steps before and after it.

GOV.UK’s guidance on retiring services starts with a useful question: how will the underlying user need be met after retirement? Although written for government services, that question applies directly to a founder removing part of a product. GOV.UK: Retiring your service

Test the replacement against the whole task

Consider this hypothetical example.

You run a reporting SaaS and want to retire scheduled PDF emails. Most customers now use shared dashboards, and maintaining the PDF layouts takes time you could spend improving reports.

The replacement looks straightforward: send customers a dashboard link.

But conversations with the remaining PDF users reveal three different jobs:

The feature being retired is “scheduled PDF emails.” The customer’s task might be “deliver a stable record of last month’s performance.”

That distinction changes the decision. You might retire automated delivery while keeping manual downloads. You might improve the replacement first. Or you might discover that the remaining workflow still justifies maintaining the feature.

Before announcing a date, try the proposed alternative with affected customers using a realistic task. Record where they need help and where the alternative fails.

Give customers a concrete transition notice

Affected customers need enough detail to act. Prepare a notice that answers:

1. What exactly is changing?

2. When will it change?

3. Which parts of their workflow are affected?

4. What should they do next?

5. What happens to existing files, settings, or saved work?

6. Where can they get help if the alternative doesn’t work?

Use specific dates and describe what those dates mean. Stopping new setups, ending support, disabling a feature, and deleting stored material are separate events. Make the distinction clear whenever it applies.

GitHub’s Atom retirement announcement provides a useful example of specificity. It named the sunset date and described consequences such as package management stopping and security updates ending. Those details gave users something concrete to plan around. GitHub: Sunsetting Atom

Choose your transition period around the work customers must do. A settings change and a replacement integration require different amounts of preparation.

Write the public update around the decision

Once affected customers have a clear notice and support route, explain the broader lesson publicly.

Buildside’s practical guide to building in public recommends sharing decisions, evidence, and next steps. A feature retirement fits that structure well.

Using the hypothetical reporting product, a public update could read:

We’re retiring scheduled PDF emails and focusing our reporting work on shared dashboards.

During migration testing, we found that some customers need a fixed monthly document for client reporting. A live dashboard doesn’t cover that task, so we’re keeping manual PDF downloads.

We’ve contacted affected customers with the timeline and migration instructions. Our next check is whether they can complete their next reporting cycle using the revised workflow.

This gives readers a specific product lesson: testing the replacement changed the scope of the retirement.

Keep account names, private conversations, and individual customer economics out of the public explanation unless you have permission to share them.

Track whether customers can finish their work

After sending the notice, keep a simple record for each affected account:

• Notice delivered.

• Alternative tested.

• Migration completed.

• Blocker still unresolved.

• Next follow-up date.

An email open doesn’t show that someone can complete their task. Where practical, check what happens during their next real use of the workflow.

For the reporting example, the meaningful check is whether a customer can prepare and deliver the next monthly report. If they can’t, the migration needs attention even if the new dashboard works exactly as designed.

Close the loop with what you learned

After the transition, publish a short follow-up grounded in what actually happened.

Explain which assumptions held, what customers needed that you missed, and what you changed along the way. Be candid about unresolved problems. Avoid claiming that retirement improved retention, reliability, or development speed unless you have evidence for those outcomes.

Before writing your next feature retirement announcement, finish this sentence:

“Customers who currently use this to accomplish ___ will be able to accomplish it by ___.”

If the second blank is still vague, work through it with the people affected. That conversation will improve both the product decision and the story you eventually share.

A note from Uriel Bitton

I share practical lessons from building Buildside and learning alongside SaaS founders.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.