Saying Goodbye Gracefully: The Feature Sunset Playbook for Vibe Projects

Intro: Shutting Down a Feature Is a Sign of Maturity, Not Defeat

Every vibe developer knows the launch move: a user mentions a need, you hand three sentences to an AI, and two days later the feature ships with a changelog entry. Euphoria. But fast-forward three years and your product is carrying seventeen features, ten of which you've half-forgotten the purpose of — each one still demanding maintenance: dependency upgrades, the occasional bug report, a user asking why a button does nothing. These zombie features cost more in upkeep than building new ones ever did.

Shipping is easy; sunsetting is not. That's the most expensive habit in indie development. Launching takes nerve. Sunsetting takes a full execution playbook: announcement, data export, refunds, emails, 301s, archiving, retrospective. Skip any step and you get 2 a.m. support tickets, one-star App Store reviews, or a Google index full of 404s. This guide is that playbook — because sunsetting is the mirror image of shipping, and it deserves equal seriousness.

A word on scope, since this site already covers neighboring territory. vibe-project-api-versioning-deprecation-guide handles API-layer deprecation — URL versioning strategies, Deprecation headers, breaking-change calls: that's the contract for machines and developers. vibe-project-exit-acquisition-guide is about selling the whole project — valuation, diligence, handover: that's company-level. side-project-kill-list is the decision checklist — it helps you decide whether something deserves to live. This guide assumes the decision is made: a feature or product line is going away. What follows is the product-layer execution SOP for doing it cleanly, from day one of the announcement window to the last page of the retrospective.

Step 1: The Three Sunset Questions — Kill It, When, and How

Before you sunset anything, answer three questions, each with data, not vibes.

Question one: does anyone still use it? Open your analytics and look at three numbers: daily active users of the feature over the last 90 days, its share of total users, and whether the trend is rising or falling. A useful rule of thumb: under 5% of users active in 90 days, declining for two straight quarters — that's a sunset candidate. But don't look at raw counts alone. A feature used by 200 people who are all $500/year enterprise customers is a different animal from one with 20,000 users and zero paid conversion. Rank by revenue contribution × activity trend, not by page views.

Question two: what does it actually cost to keep? List the hours spent on this feature over the last six months: bug fixes, dependency upgrades, support tickets, the odd production incident. The cost indie developers most underestimate is the cognitive tax — every time you open the codebase, you burn ten minutes remembering what that logic was for. Build a "feature graveyard review" sheet: one row per feature, columns for monthly actives, paying users, maintenance hours in the last half-year, and date of the last meaningful iteration. A row that's red in all four columns is just a tax you're paying for nostalgia.

Question three: what's the real cost of killing it? Three kinds: user trust (did anyone pay specifically for this feature?), traffic (does any page rank in Google's top three?), and legal (any SLA commitments or contract terms?). If the answer is "a dozen annual subscribers and 30K monthly organic visits," then the plan should be a migration, not a shutdown. Answer all three and you get a clean verdict: kill now, migrate-then-kill, or watch for another quarter.

Step 2: Work Backwards — Treat the Sunset Like a Launch

The cardinal sin of sunsetting is flipping the switch on some random Tuesday morning. The right move is to run it like a small launch, in reverse: announcement window, read-only period, shutdown day. Three phases.

Announcement window: 30 days minimum for free features, 90 for paid ones. Why 30/90? It's the industry floor. Dropbox announced the Mailbox shutdown in December 2015 and set the kill date for February 26, 2016 — a full 80 days of notice. When Google stopped selling new Gemini Code Assist subscriptions on October 9, 2026, existing customers got renewal runways stretching to January 2027 (annual) and even December 2027 (monthly) — a migration window measured in years. Your user base is smaller, but the principle holds: the announcement window must cover at least one full billing cycle, and annual subscribers need 90+ days, or refunds and complaints will bury you.

Day one of the announcement window means four things happen simultaneously: the in-app banner goes live, the farewell email goes out, the changelog entry publishes, and the FAQ page launches. Order matters — announce first, close the gates second. Never the reverse. During the announcement window, shut off new entry: no new signups, no new subscriptions, no new API keys. Existing users are unaffected. People forget this step constantly, and the users who sign up after the announcement are always the angriest on shutdown day.

Read-only period: writes stop, reads and exports stay. The feature goes read-only: no new data can be created, but history remains viewable and exportable. Two weeks minimum, longer for data-heavy features. This is when your export button needs to be the most prominent thing on the page — and you should test the export flow three separate times. An export service that dies on shutdown day is a trust catastrophe.

Shutdown day: close the gates, stop billing, kill the crons. The checklist: hide frontend entry points, return 410 or 301 on routes (next section), stop subscription billing, shut down related cron jobs and webhooks, cancel or downgrade third-party services (SMS, email, storage sub-buckets). One detail worth stealing from Google's Code Assist wind-down: they separated "stop selling" from "stop serving" as two distinct dates — halt new commitments first, then wind down existing ones per contract. Solo developers should do the same: close the door to newcomers before touching existing users.

Step 3: The Data Exit — Export, Migrate, Delete

Users can accept a feature dying. They cannot accept their data dying with it. There are three exit paths, in priority order: export (users take it themselves) → migrate (you help them move) → delete (they ask for erasure).

Export is the baseline. Offer one-click export in at least two formats: CSV for normal humans (opens in Excel), JSON for technical users (structure intact). The export must be complete: all user-created data, metadata (timestamps, tags, relationships), and download links for attachments. Here's a working export skeleton — package per user into a zip, upload to object storage, return a download link:

import csv, io, json, zipfile
from datetime import datetime, timedelta

def export_user_data(user_id, db, storage, retention_days=180):
    """Export one user's data for a sunset feature, packaged as a zip."""
    rows = db.query(
        "SELECT * FROM feature_records WHERE user_id = %s", (user_id,)
    )
    buf = io.BytesIO()
    with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
        # 1. JSON: full structure, for technical users
        zf.writestr("records.json", json.dumps(rows, ensure_ascii=False,
                                               indent=2, default=str))
        # 2. CSV: opens in Excel, for everyone else
        if rows:
            text = io.StringIO()
            writer = csv.DictWriter(text, fieldnames=list(rows[0].keys()))
            writer.writeheader()
            writer.writerows(rows)
            zf.writestr("records.csv", text.getvalue())
        # 3. README: export time, scope, contact
        zf.writestr("README.txt",
            f"Exported: {datetime.utcnow().isoformat()}Z\n"
            f"Scope: all records before the feature sunset\n"
            f"Download link valid for: {retention_days} days\n"
            f"Questions: support@example.com\n")
    key = f"exports/{user_id}/{datetime.utcnow():%Y%m%d}.zip"
    url = storage.upload(key, buf.getvalue(),
                         expires_in=timedelta(days=retention_days))
    return url

Three details people miss: first, link lifetime — keep exports available for at least 6 months after shutdown, and state the exact cutoff date ("your data stays downloadable until X") in the announcement. Second, decouple export from the kill switch — the export service must still be alive on shutdown day. Third, power users have big datasets, so make export an async job with an email notification, not a page that times out while they stare at a spinner.

Migration is the bonus round. If a mature alternative exists (even a competitor's), write a one-page migration guide: field mapping table, import steps, known gotchas. When Facebook shut down Parse in 2016, they gave a full year of runway, open-sourced Parse Server, and shipped migration tooling — the textbook migration path. You don't need that scale, but one page of "where to go and how to move" converts 80% of anger into "this team actually handled it well."

Deletion is an obligation. When users ask to delete their account or data, run the standard erasure flow: clear the database, follow your backup retention policy. EU users bring GDPR erasure rights into play — don't cut corners here. Delete thoroughly, send a confirmation email.

Step 4: The Money — Refunds and Compensation, One Formula

Money is where sunsets blow up. One iron rule: if a user paid for service they haven't consumed, the money goes back. The formula is simple — refund pro-rata by remaining days. A $365/year plan with 120 unused days at shutdown means a $120 refund. Don't get clever with "store credit" or "convert to points" — the user is leaving the feature, not shopping for another one. Credit feels like a scam.

Three tiers in practice. Monthly subscribers: refund the remaining days of the current month — Stripe, Paddle, and friends all have pro-rated refund APIs; it's one call. Annual subscribers: refund pro-rata by remaining days. This is your most sensitive group, so spell out the math in the refund email ("You paid $365/year, 120 days remain, refund: $120"). Transparency is the best fire extinguisher. Lifetime/one-time buyers: the hard tier — there's no "remaining days" to compute. The industry norm is a fixed-percentage refund (say 30–50%) or equivalent time on another of your products. State the policy once, in the announcement. Never make users haggle for it.

Compensation is separate from refunds. A refund returns unspent money; compensation apologizes for disrupting someone's workflow. It doesn't need to be expensive, but it needs to be concrete: three free months on another product of yours, or a personally written apology email (actually personal, not a template). This is the indie developer's unfair advantage — big companies can only send templates; you can show up as a human. When Dropbox killed Mailbox, their FAQ covered migration guidance for every alternative, down to details like "your drafts will be deleted, save them manually" — the more specific the detail, the more respected the user feels.

Step 5: The Announcement and the Farewell Email — What to Say, What Never to Say

Announcement copy comes in three pieces: the in-app banner, the farewell email, and the changelog entry. One red line governs all of them: no blame-shifting, no vaporware, no word games.

The three nevers. Never shift blame: don't write "due to third-party service changes" or "circumstances beyond our control" unless it's literally true. Users can smell deflection. Never promise vaporware: don't write "we're building an even more powerful 2.0, stay tuned" if 2.0 doesn't exist — that burns your last shred of trust. Never play word games: don't dress up a shutdown as a "feature upgrade" or "service optimization." Users aren't stupid, and cute euphemisms just make them angrier.

The three musts, in this order. Lead with the decision: "We've decided to shut down XX on [date]." No three paragraphs of throat-clearing first. One sentence on why, in plain language: "Over the past year only 3% of users touched it, and maintaining it ate half our development time, so we're focusing on the core product." Then the logistics: how to export data, how refunds work, where to find alternatives — one link per item.

Banners and emails differ in tone. A banner is a notice: calm, accurate, linked. An email is a farewell, and it can have a little humanity. A good farewell email: paragraph one states the decision and date; paragraph two gives the reason (one sentence); paragraph three covers "your data and your money" as a bulleted list with links; paragraph four says thank you — be specific, "thank you to the 2,400 of you who used this over three years" beats "thanks for your continued support" by a mile; sign it as a real person, not "the XX team."

Pin three questions at the top of the FAQ: "What happens to my data?" "What about the money I paid?" "Is there an alternative?" Those three cover 95% of tickets. The remaining 5% genuinely need a human reply — have response templates ready so support (that's you) isn't scrambling on shutdown day.

Step 6: SEO and Backlinks — The 301 Map

If the sunset feature has public pages — help docs, feature landing pages, blog tutorials — deleting them outright throws Google rankings and link equity in the trash. The right move is a 301 mapping table: every dying URL gets a closest-living page.

The mapping rules are simple: feature landing page → product homepage or replacement feature page; help docs → migration guide or FAQ; blog tutorials → an archive page or updated tutorial. When no related page exists, 301 to the homepage still beats a 404 — search engines long ago stopped discounting PageRank passed through 301s, so your accumulated link equity isn't wasted. Use 410 (Gone) in exactly one case: the content is truly gone with no replacement, like docs for a deleted API endpoint. A 410 tells search engines "don't come back" — it's for real endpoints.

A working Nginx example:

# Feature sunset 301 map — write every rule, ten extra beats one missing
server {
    listen 443 ssl;
    server_name example.com;

    # Feature page -> replacement feature
    location = /features/smart-reminders {
        return 301 https://example.com/features/automation;
    }
    # Help docs -> migration guide
    location = /docs/smart-reminders {
        return 301 https://example.com/docs/migration-guide;
    }
    # Nowhere to go -> homepage (safety net, never a dead end)
    location = /features/legacy-dashboard {
        return 301 https://example.com/;
    }
    # Deleted API endpoint docs -> 410, tell crawlers to stop coming
    location = /docs/api/v1/reminders {
        return 410;
    }
}

After the 301s go live, do three things. First, spot-check a few URLs in Search Console's URL inspection — confirm 301s with 200 targets. Second, for pages with heavy backlinks (check Ahrefs or Search Console's Links report), consider asking the linking site to update the URL — a 301 is insurance, not an excuse. Third, remove dead URLs from your sitemap; don't make crawlers chase redirects. Three months later, revisit the Search Console coverage report and confirm there's no abnormal spike in 404s or soft 404s. Only then is this section truly closed.

Step 7: Code Archiving and Branch Strategy — Delete Clean, Recover Anytime

Sunsetting code is four steps, in this order: tag → archive branch → delete the pipeline → shut down crons and third-party services.

Step one: hold a funeral for the code — tag it. Before deleting anything, tag the main branch, e.g. archive/smart-reminders-final, with the sunset date, last served version, and where the data export script lives in the tag message. A tag is the cheapest time capsule in Git — ten years from now, one command brings the code back.

Step two: archive the branch. Merge feature-related branches into a single archive branch (or archive the whole repo if it was a standalone service), named archive/<feature>-<date>. GitHub and GitLab both offer repository archiving: archived repos are read-only — no pushes, no new issues. It's a dignified "case closed" gesture. A public archived repo still shows code and history, but nobody files issues asking "are you going to fix this bug?"

Step three: delete the deployment pipeline. Kill or disable CI build jobs, CD deploy flows, and Docker image auto-builds. The three spots people forget: scheduled nightly builds; image-registry cleanup policies (tag-lock the archived images first so they don't get garbage-collected); and IaC definitions (Terraform/Pulumi) — if the resource definitions stay, the next apply resurrects the service, and that's an embarrassing incident report.

Step four: shut down crons and third-party services. Work through a checklist and check each off: cron jobs, webhook subscriptions, SMS/email provider sub-accounts and templates, object storage sub-buckets (only after data is migrated or past retention), DNS records for dedicated subdomains (delete the record, but renew the domain itself for another year — you don't want it snatched for phishing), error-monitoring projects (Sentry and friends), status-page components. Date and initial every item — the operator is you, and the notes exist so that three months from now you can still answer "what did I actually turn off?"

Step 8: The Post-Mortem — Turn "What We Killed" Into a Trust Asset

Shutdown day isn't the finish line; the retrospective is. Keep it to one page, four questions:

1. Why did we build this in the first place? Write down the original rationale — user votes, competitive pressure, a 2 a.m. idea. Many features die of causes present at birth: a general-purpose feature built for three people's needs, a demo built for a launch event that nobody maintained.

2. When did the death signals first appear? Look back at the data and find the inflection point: did growth stall three months after launch? Was this the code nobody wanted to touch during the first big refactor? Write down the signal and the date — next time the same signal appears, you'll react twice as fast.

3. What would killing it three months earlier have saved? Do the math: three months of maintenance hours × your hourly rate (use your freelance rate), plus servers and third-party services. That number is the best sobriety check for the next time you hesitate.

4. What will we do better next time? One item, two at most. "Write sunset criteria when a feature launches." "Announcement window for paid features goes from 30 to 90 days." A retrospective with ten action items is a retrospective with zero.

The final step is optional but surprisingly effective: publish a public "feature graveyard" page. List what you shut down, why, and the one-line lesson. It sounds counterintuitive — who advertises failures? But when users see "this team kills features cleanly and explains itself," trust goes up, not down. A team brave enough to publish its sunset history earns the belief that "they won't let a feature I depend on vanish without a word" — because you've already proven that even when things disappear, you say goodbye properly.

Anti-Patterns: Seven Things to Never Do

1. Silent shutdown: killing it with no announcement, hoping users "figure it out." That's trust suicide — users will assume you rug-pulled.
2. Closing the gates before announcing: wrong order. New users still sign up in the 24 hours after an announcement — close new entry first, then announce.
3. Letting export die with the feature: the export service must outlive the feature by at least 6 months. Put it in the announcement.
4. Store credit instead of refunds: users want their money back, not a coupon for another purchase. Refund pro-rata in cash; no cleverness.
5. "Feature upgrade" language: dressing a shutdown as an upgrade. Users aren't stupid — the cuter the euphemism, the angrier the response.
6. Deleting code without a tag: three months later you'll want to look at the old implementation and find it unrecoverable. Tags are the cheapest regret insurance.
7. Changing the plan on shutdown day: once the announcement is out, the plan is frozen. Every date change or refund-policy tweak costs a unit of trust.

Acceptance Criteria: It's Only Done When Everything Is Checked

A sunset isn't "code deleted." It's done when all twelve of these are checked:

1. Announcement published (in-app banner + email + changelog + FAQ); window meets the 30/90-day floor
2. New-user entry closed (signups, subscriptions, API keys); zero new users during the window
3. Data export works; spot-check exports for 3 users of different data sizes (CSV + JSON)
4. Migration guide published (if an alternative exists), or an explicit "no official alternative" statement
5. Paid-user refunds completed, refund emails sent, refund math transparent
6. Farewell email sent; FAQ pins the three questions: data, money, alternatives
7. 301 map live; status codes spot-checked; sitemap cleaned
8. Archive tag created, archive branch in place, public repo set to read-only archived (if applicable)
9. CI/CD pipelines deleted; crons, webhooks, third-party services off; checklist signed item by item
10. Billing stopped; no user charged after shutdown day (re-verify on the next billing date)
11. One-page retrospective written and filed in the team knowledge base
12. 30 days later: review ticket volume, Search Console coverage, refund disputes — confirm no abnormal spikes

One last thing: a graceful sunset never makes users leave you. A graceless one does — and takes their friends with them. An indie developer's moat was never feature count; it's trust. Saying goodbye properly is how you bank credit for the next launch.