Inspiration

I've lost track of how many times I bought something that felt fine in the moment and only stung a week later, not because I didn't have the money, but because I hadn't actually done the math. I'd forget how many days were left in the month, forget I was supposed to be saving for something, and only put the pieces together after checking my balance and feeling that little drop in my stomach. The problem was me being lazy to crunch numbers myself which meant I never had the full picture in front of me at that moment. Every budgeting app I tried was built for looking backward: categorized spending, monthly summaries, charts that told me what I'd already done wrong. None of them stood between me and the "Buy Now" button when it actually mattered. Troshkali started from one simple question: what if, right before you spend, you can see the math and be advised before you do it?

What it does

Troshkali checks whether you can actually afford a purchase right now, before you make it, and gives you a blunt, honest verdict: go ahead, tight, or not now.

You give it a price or scan it with app, and it weighs that purchase against what you have left to spend this month, how many days remain, and how close it would push you to your safe-to-spend line, plus how it would affect your savings goal down the road. It doesn't just say yes or no; it shows you the daily runway you'd be left with and how many days a purchase would set your goal back, so the trade-off is visible, not abstract.

It also understands that not everything is paid for all at once. Purchases can be split into installments, and Troshkali correctly spreads the monthly hit across the plan's whole lifespan, so a item bought in April is still quietly accounted for in June, automatically.

How I built it

The backend is the single source of truth: one rule engine deciding every verdict. The affordability decision is pure math, computed the same way every time, and lives in exactly one file: $$\text{remaining} = \text{safe_to_spend} - \text{spentThisMonth}$$

$$\text{daily runway} = \frac{\text{remaining}}{\text{days left in month}}$$

$$\text{days until goal setback} = \frac{\text{price}}{\text{daily save needed}}, \quad \text{daily save needed} = \frac{\text{target amount} - \text{saved so far}}{\text{days until target date}}$$

For example, with the numbers from the app:

$$2{,}500 - 2{,}009.81 = 490.19\ \text{KM remaining}$$

The iOS app is a thin client that calls that API. It isn't allowed to make its own judgment call about what "affordable" means; it just displays the answer.

AI enters only after the number is already decided. Once the verdict is computed, the model turns the raw numbers into a short, human explanation. If the API call fails or no key is configured, a fallback kicks in automatically, so the app never breaks just because a language model had a bad day.

Challenges I ran into

The hardest problem was editorial. Once the core "check a purchase" loop worked, it was tempting to keep bolting things on: spending categories, tags, streaks, notifications, deeper analytics. But the whole value of Troshkali is that it gives you one clear answer in the three seconds you have before clicking buy and every extra field, toggle, or screen between you and that answer works directly against the product's purpose. I had to keep asking, "does this make the verdict clearer, or does it just make the app feel more full?".

Accomplishments that I'm proud of

I'm proud that the affordability logic is entirely deterministic and testable. The AI never gets a vote in whether something is affordable, only in how that fact gets said out loud, which means the app can never "hallucinate" a bad financial decision. I'm also proud of how the installment math turned out: tracking which plans are active in a given month, separating committed spend from earlier plans out of the current month's number, and computed live from the actual rows rather than stored and drifted.

What I learned

Basically, making the math boring, transparent, and always right, and kept the AI on writing duty only. I also learned a lot about restraint as a design skill in its own right: it's much easier to add a feature than to justify leaving one out, and the discipline of protecting a simple core app experience.

What's next for Troshkali

Next up, I'm working on push notifications and reminders, so Troshkali can nudge you before a subscription renews or when you're close to your budget limit. I'm also planning shared budgets, so multiple users can track spending and saving goals together.

Built With

Share this project:

Updates

Submission history