• Case study • Financial product •
AgencyTrack: a financial product for the money problem I live
Role
Product designer and builder
Date
2026
Responsibilities
Product strategy
Financial UX
End-to-end build
Timeline
6 months
Overview
The money side of a small business is not something I researched. It is something I have lived. I co-founded and ran an internet service provider for three years and did the invoicing, cash flow, and admin myself, with an economics degree underneath it.
Today I run an independent design practice in Serbia on the paušal tax model. That model has a hard edge. I built AgencyTrack to stay on the right side of it.
01
The problem I actually have
Paušal is a flat-tax model for small operators. It carries two limits. Cross 6,000,000 dinars in a calendar year, or 8,000,000 across any rolling 365 days, and you lose the flat rate and move to a heavier regime. Those limits change how the whole business is taxed, so knowing exactly where you stand is not optional.
I tracked it in a spreadsheet. Building the tool, I rebuilt the same math in code and checked it against the sheet. The sheet had five errors in it. I had been making real decisions off numbers I trusted and should not have.
02
How I built it
I started from my own workflow rather than a feature list. I wrote down how money actually moves through the practice: quote, invoice, payment, exchange rate, tax position. I framed the problem before I designed a screen.
Then I prototyped fast with Claude Code and validated each part against my real payment history. I shipped it in pieces and used each piece as I finished it, so the tool got corrected by real use instead of by my assumptions. The result is 399 commits of a working product, built solo, from a bare Next.js app to something I use to run my own finances.
03
What makes it a financial product, not a form
Anyone can build an invoice form. The product is in the money correctness.
Payments drive everything. The tax position is never typed in by hand. It is computed from the payments ledger, so it cannot drift from reality.
Currency is locked in time. When an invoice is issued, the tool fetches the National Bank exchange rate for that date and freezes it, so a euro invoice paid three months later still reports the tax the law actually expects.
You can see the tax before you accept the money. A payment simulator shows what a given payment does to your threshold position before you accept it, so a single incoming transfer never quietly pushes you over a limit.
The system warns early and records everything. It flags 70, 80, 90, and 100 percent of each limit, logs every change to an immutable audit trail, and produces KPO-compliant output ready for the books.
04
Where it stands
I use AgencyTrack to run my own invoicing and threshold tracking. It replaced a spreadsheet and a mail folder. It is not a daily-critical system for a large team yet, and I am not going to claim numbers it has not earned.
What it has earned is trust. It matched how the work actually happens instead of how a spec imagined it, so I stopped second-guessing the figures. That is the outcome I care about most in financial tooling. The person using it believes the number on the screen.
05
What this transfers to
Fintech teams need people who can hold two things at once: a complicated flow, and the money underneath it. I have built both, end to end, for a problem I live every month.
I understand the small-operator money problem from the inside, I can design the complex flow that solves it, and I can build enough of it to prove the thing works. The cost of putting me on a financial product is close to zero.
See the tax before you accept the money.
Hiring a design leader, or need one for a while?
Let’s talk.
Marko Rosić PR Beyond Clicks Studio · MB 67353170 · PIB 114143089
Cara Lazara 26/21, 34000 Kragujevac, Serbia
© 2026 rosic.net