Real Fixes
We can't share real customer names or emails publicly. These stories are anonymized. What isn't softened is the detail. Each one is a real bug we found or a real feature we built, from a real situation, with the actual mechanics of what was wrong and what changed.
Two retirement ages, and a survivor benefit that used a shortcut
A customer's household had each spouse retiring at a different age. Our health coverage model back then treated the household as one flat snapshot. It couldn't show one spouse losing employer coverage while the other kept working. Fixing that surfaced a bigger problem. Our survivor Social Security benefit used a placeholder, just the bigger of the two checks, instead of the real SSA formula. We rebuilt both. Coverage now follows each spouse on their own timeline. The survivor benefit now matches the real SSA formula, starting at 71.5% of the deceased's benefit at age 60 and rising to 100% at full retirement age.
A safety margin that wasn't holding
Our Roth conversion tool lets you set a safety margin below a Medicare IRMAA threshold. That way, a conversion doesn't accidentally trigger a premium surcharge two years later. We found a bug where a conversion landing just inside that margin got no cap at all. Two parts of the guard logic had drifted apart over time. Only one of them was checking the buffer correctly. We merged them into a single function so the safety margin holds every time.
A military family's health coverage the guard couldn't read
A military family in our system had TRICARE as their health coverage. Our ACA subsidy guard didn't know how to read that. It kept treating the household as if it needed marketplace subsidies. That protected a subsidy they didn't receive. The mistake cut their available Roth conversion room from about $175,000 a year down to zero, for five straight years. We found it during an internal audit, traced it to a coverage field the guard never checked, and fixed it the same day.
A benefit that dropped 30% for no real reason
SSDI converts automatically to a regular Social Security benefit at full retirement age. The real dollar amount doesn't change when that happens. Our model had it dropping by about 30% at exactly that age. Two parts of the engine used different cost-of-living conventions. The mismatch showed up right at the conversion point. We caught it during an internal audit and fixed it the same day.
A widow's benefit that jumped by an amount she never should have gotten
When a spouse dies before claiming Social Security, the survivor's benefit is supposed to start right away, based on what the deceased had earned up to the date of death. Our model instead held the survivor's benefit low for years, then jumped it up once it reached the deceased's planned claiming age. That jump included delayed retirement credits Social Security never awards after death. We rewrote the calculation to start the benefit at death and use only the credits earned by that point, matching the real rule instead of a simplified one.
A federal savings match most people haven't heard of yet
A customer asked us to flag a new federal savings match, the Saver's Match, before it takes effect in 2027. It's a 50% match up to $1,000 per person, capped by income. We built it to their spec. It flags eligible years without pretending to be a certified answer, notes when a Roth conversion, not your regular income, is what pushes you over the cap, and points you to a tax professional from there. A week later, the same customer told us where they'd look for it in the app, on the Projection Table, not just the dashboard. We moved it there too.
Two bugs that four rounds of math-checking never would have found
Our most engaged tester spent a weekend using the app instead of checking numbers against a spreadsheet. He found a settings link on the Inherited IRA tab that dead-ended one click short of anywhere useful. He also found a return-rate field on Risk Analysis that was nearly impossible to type into. The field's stored range and its displayed percentage were off by a factor of 100. It reformatted itself mid-keystroke as a result. Neither bug would ever show up in a calculation audit, since the math itself was fine. Both only showed up because someone used the screen. We now run a separate usability pass, not just a correctness pass, because of this.
Silence that looked like a broken feature
Our On Track tab blends your real logged spending into future-year projections. The plan corrects itself as your actual numbers come in. A customer who had only logged pre-retirement spending couldn't tell whether the recalibration was working, or just hadn't started yet, since a bucket with no data yet looked exactly like a bucket that was broken. We fixed it by saying so directly. Any phase with nothing logged yet now tells you that, instead of quietly leaving it blank.