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.
October 24, 2026
Node.js, the software our server runs on, put out a security release on October 21 that fixed several flaws. We updated within two days and restarted the site on the patched version. We also updated the web framework the site is built on. We take security seriously. We maintain the site every month, and we apply security fixes between those rounds as soon as they come out.
October 12, 2026
On Track lets you log what you really spent, and the dashboard rebuilds your plan around it. Say you told us at setup that you would spend $80,000, then logged months that came in at $95,000. The dashboard plans on $95,000. Several other screens did not. The What-If Workshop, Scenario Explorer, Smart Suggestions, the Coast FI age, and the history behind Since your last update all ran on the $80,000 you typed at setup. A household with logged spending could see one plan on My Situation and a different current plan inside a what-if, and every comparison was measured from the wrong starting point. Each number looked reasonable on its own, which is why nothing flagged it. We changed every screen that re-runs your plan to start from the same recalibrated plan the dashboard uses, and added automated checks that fail if a screen goes back to setup numbers. One side effect: a household with logged spending may see a single change under Since your last update that comes from this switch, not from anything they did.
October 1, 2026
Our On Track tab lets you log what actually happened each month, spending, withdrawals, part-time income, so the rest of your plan can correct itself around reality. For income that repeats, like a paycheck, taking one real month and projecting it forward for the rest of the year makes sense. A Roth conversion doesn't repeat. It's a single decision, made once. Our engine didn't know the difference. It took whatever was logged for a conversion and stretched it out the same way it stretches part-time income, as if the household converted that same amount every month of the year. A customer who converted a real amount in a single month saw a number many times larger than what actually happened, both on the On Track screen and in that year's tax estimate. While fixing it, we found a second copy of the same mistake in the part of the engine that feeds the Projection Table and Full Report instead of only the On Track summary. We fixed both. A logged conversion now counts exactly once, in the month it happened, the same as it would on your real tax return.
September 26, 2026
While researching an article about a couple retiring at 52, we ran the same household twice, once with a $500,000 Roth conversion and once without. The conversion added $104,768 in tax that year. Total assets fell by only $18,338. The tax bill had disappeared. Our engine treated the converted money as cash the household could spend. That phantom cash cancelled out the conversion's own tax, so no account was ever drawn down to pay it. Every Roth conversion projection in the app came out too generous by the amount of that tax. Small conversions barely moved. Aggressive ones looked far cheaper than they are. No customer reported it, and the math on each screen looked internally consistent. It only surfaced because we tested one household two ways. We fixed the engine so the tax now comes out of the household's own accounts. We added an automated check that fails if a conversion's tax ever stops reducing balances. We also corrected the published articles that used the old numbers. In one comparison, the gap between converting everything and stopping at a Medicare line changed from $57,502 to $132,844.
September 15, 2026
One of our guards protects your ACA subsidy and your Medicare premium tier by capping how much you convert or withdraw each year. To do that safely, it has to estimate how much of your Social Security counts as taxable income. For years it used the worst case. It assumed 85% of the benefit was always taxable, no matter how low the rest of a household's income was. For a retiree living mostly on a small pension and Social Security, that assumption was wrong. At that income level, the real IRS formula taxes little or none of the benefit. The guard didn't know that. It thought the household had no income budget left, so it handed back zero room to convert or withdraw from a traditional account. Every dollar of spending came out of the Roth account instead, year after year, even though the household's real income sat well under the ceiling they had chosen. We rebuilt the guard to solve the real IRS formula directly instead of guessing. It now finds the exact amount a household can convert or withdraw before crossing into a higher tax bracket for their own benefit. We tested it against tens of thousands of income combinations to make sure it never lets anyone go over their limit. For this household, the fix opened up about $15,000 a year of room that had gone unused.
September 13, 2026
A trial user asked about moving from Virginia to New Jersey or Pennsylvania. Our relocation tool only let you compare against seven states with no income tax at all, so we couldn't answer the question. Widening it meant checking whether our existing state tax data was even right first, and for some states it wasn't. California was taxing Social Security at the state level, something California hasn't done in decades. Pennsylvania, Illinois, and Mississippi fully exempt pension and retirement account withdrawals, and none of the three had that modeled, so those states looked worse than they actually are. New Jersey's retirement income exclusion wasn't in the system at all. We fixed all four, then kept going. Connecticut, Minnesota, and Utah each tax Social Security on a sliding scale tied to income. Utah does it through a shrinking tax credit rather than a straightforward exemption. None of the three were modeled correctly either. Everything is fixed now, and the relocation tool compares against all 50 states instead of seven.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.
September 8, 2026
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.