The parts of a product nobody wants to build
Billing flows, deletion with grace periods, subscription sync. Invisible when done well, damaging when skipped.
Nobody asks about the cancellation flow until someone tries to cancel. Then it's the only thing that matters.
There are features in every product that nobody designs for and nobody celebrates shipping. Account deletion. Subscription sync when a payment fails. Billing overlays that actually explain what a user is paying for. The grace period between a cancelled account and a deleted one. These aren't the features that end up in a launch post. They're the features that determine whether users trust you.
The features that make a product feel real
When I was building Unsaid, I kept deferring these. There was always something more important: the core journaling experience, the AI analysis pipeline, the onboarding flow. The invisible features could wait.
What I found is that waiting is its own design decision. An app without a grace-period deletion is making a choice: users who cancel lose their data immediately. An app without proper subscription sync is making a choice: users who churn because of a payment failure don't get a recovery window. These aren't gaps. They're behaviors. They just weren't deliberate ones.
Why developers avoid them
The obvious reason is that they're unglamorous. Nobody demos the cancellation flow. There's no equivalent to a smooth onboarding animation for 'your account will be permanently deleted in 30 days.' The features are complex: edge cases, timing logic, state machines for subscription status. The only feedback you get is when they break.
The less obvious reason is that they require you to think clearly about scenarios you'd rather not think about. Building a deletion flow means modeling what it means for a user to leave. Building a billing overlay means confronting how your pricing looks when someone stares at it before paying.
What gets exposed when you skip them
Skipped invisible features tend to show up as support tickets and churn. A user who can't figure out what they're paying for doesn't usually write in. They cancel. A user who deletes their account and regrets it has no recourse. A user who lets a card expire and loses access before getting a retry email may not come back.
The invisible features don't show up in your metrics. Their absence does.
The deletion grace period
I modeled Unsaid's deletion as a soft delete with a 30-day grace period. The account is marked as scheduled_for_deletion. The user can cancel the deletion during that window. After 30 days, a background job runs the hard delete. It took most of a day to build: the state machine, the email at day one and day twenty-five, the recovery flow.
Nobody has used it yet. That's fine. The feature isn't there for the average case. It's there for the edge case, which is always the one that matters most to the person in it.
The working principle
The filter I use now: if a user would notice the absence, it isn't optional. A missing cancellation flow isn't a feature gap. It's a trust gap. Users don't necessarily know which features they're using to calibrate their trust in a product, but they know how it makes them feel when something goes wrong.
Shipping the invisible features is less satisfying than shipping the visible ones. The payoff is that when a user tries to cancel, or wants their data back, or has a question about their bill, the product handles it like it was designed by someone who expected them to show up.