Debt payoff is not just a balance-sorting problem

Hey everyone, hope you’re having a good week.

I wanted to share another thought from building MyDebtLens, because it keeps coming up as I work through the product and how it should explain debt payoff decisions.

Debt payoff can look simple from a distance.

Sort the debts.

Pick avalanche or snowball.

Pay extra when possible.

Repeat.

That logic is useful, but it is not the whole picture.

In real life, people are often trying to answer a more personal and practical question:

“What can I actually do next month without making everything else unstable?”

That is why I think debt payoff tools should look at more than just balances and interest rates.

Balances matter.

APRs matter.

Minimum payments matter.

Due dates matter.

Income and expenses matter.

The amount of extra money someone can safely apply matters.

So does the timing of a change, like a payment increase, a payoff date, or a temporary gap in cash flow.

A route that looks mathematically efficient can still feel unrealistic if the monthly pressure is too high. A route that looks slower can sometimes feel more usable because it creates breathing room or early progress.

That product tension shaped MyDebtLens from the start.

I did not want the app to behave like a lender, lead generator, or debt-relief funnel. I also did not want it to require bank linking just to help someone understand their own numbers.

So the app is built around manual inputs and route comparison.

Users enter balances, APRs, minimum payments, due dates, income, expenses, and any extra amount they want to test. Then they can compare payoff paths such as avalanche, snowball, and custom routes, while seeing monthly pressure and timing tradeoffs in plain English.

The goal is not to tell someone what they “should” do.

The goal is to help them see the shape of the decision more clearly before choosing a route.

From a product-design perspective, this has been an interesting challenge: how do you build something useful for a stressful financial topic without making it feel judgmental, intrusive, or overly technical?

I’m still early, but that is the direction I’m trying to stay disciplined about:

clarity over pressure,

comparison over prescription,

and user-controlled numbers over forced account linking.

Curious how other builders think about this kind of product boundary.

When a product touches a sensitive personal topic, how much should it optimize for automation, and how much should it preserve user control?