TenorDash: An Experiment in AI-Native Treasury Tooling
The Starting Point
I've been using AI tools for several years, but over the past few months something shifted. The tools became capable enough that the question changed. It is no longer "how can AI help me improve this Excel workbook?", for example, but "does this need to be a spreadsheet at all?"
That's a different kind of question. It's the difference between using AI to assist a workflow and rethinking the workflow entirely — moving from AI-assisted to AI-native.
So I decided to run an experiment. I had a good candidate — an Excel workbook I'd maintained for years to track fixed advance borrowings. Could I build a dedicated replacement from scratch, using an AI coding assistant (Claude Code)?
That became TenorDash — a small dashboard for debt instrument tracking, deliberately scoped narrow: single user, local-only, no cloud services, no IT involvement required.
If the experiment failed, the cost would be my own time. If it worked, I might end up with something better than the spreadsheet. Either way, the sheer fun of the experiment was worth it for me.
I started with a product requirements document — mapping every field, workflow step, and edge case I knew from experience. Then I spent a couple of evenings and a full weekend working back and forth with Claude Code, building, testing, and refining.
What It Does
The goal was simple: make the current state of the credit lines visible immediately.
Open the app and the dashboard shows three things:
- active advances grouped by currency
- upcoming continuation dates flagged by urgency
- credit line utilisation at a glance
Try the live demo → (synthetic data — no real financial information)
When recording a new advance, the form displays derived values in real time — days to maturity, the back-calculated interest rate, and updated credit line capacity — before anything is saved.
Each save updates the dashboard, recalculates utilisation, and generates a structured export file that can be automatically imported into Power BI.
Daily exchange rates are fetched automatically via ECB's API and are visible in a sidebar widget.
All data shown is synthetic — no real financial information is used.
The full feature set includes:
- CRUD operations with auto-generated IDs
- dynamic multi-currency support
- continuation date alerts with business-day logic
- credit line capacity tracking
- Power BI-formatted auto-export
- print and PDF output
Every feature maps directly to an actual workflow step.
Key Decisions — and Why
Most of the work wasn't writing code — that was handled by Claude Code. It was deciding how the workflow should behave and settling on a few key assumptions.
Back-calculated interest rate. For this version, the app takes the bank-provided interest rate and amount as given. TenorDash derives the implied interest rate as a verification check. The alternative — entering a rate and calculating the interest — would require tracking credit contracts and their rate logic (EURIBOR, SARON, spreads, reset rules). That would be a logical upgrade for a future version.
360-day year convention. Interest calculations use ACT/360, the standard money-market day-count convention used in interbank lending.
Continuation dates: 3 business days, no holiday calendar. The app flags advances approaching maturity three business days in advance, skipping weekends. I deliberately skipped multi-jurisdiction holiday calendars for simplicity.
Computed fields, never stored. Days to maturity, derived interest rates, and active/matured status are calculated at read time rather than stored. With datasets typically in the hundreds or low thousands of rows, performance isn't a concern. Data integrity is. Stored calculations go stale. Change a maturity date and every derived field must update. By computing them dynamically, the data always remains consistent — no "refresh" button required.
Soft delete for credit lines. When a credit line becomes inactive, it is archived rather than deleted. Existing advances still reference that credit line. Deleting it would either orphan records or require cascading deletions that destroy historical data. Referential integrity matters more than a perfectly clean list.
Each of these decisions looks obvious in hindsight. None of them would appear in a generic specification. They tend to surface only after spending time inside the workflow itself.
How I Built It
The priority was simplicity, transparency, and maintainability.
Tech stack. TenorDash runs on a Python/Flask backend with a SQLite database and a vanilla JavaScript frontend. No ORM — direct SQL for transparency and control. No frontend framework — the interface is simple enough that adding one would increase complexity without real benefit. The application exports structured data that feeds Power BI for reporting — a setup that treasury practitioners increasingly view as a practical and inexpensive alternative to a full TMS.
AI-assisted development. TenorDash was built mainly using Claude Code. The process started with a product requirements document — fields, relationships, and edge cases derived from experience. The architecture, domain logic, and data model were human decisions. Claude Code translated those into working code. When the output was technically correct but missed domain nuances — that's where experience mattered. The workflow resembled a small development team: Claude Code as the primary builder, Codex occasionally reviewing or suggesting refactors, and me reviewing pull requests and deciding what to merge.
Engineering practices. GitHub for version control, feature branches with pull requests, CI via GitHub Actions, 96 automated tests, and a structured release process. Not because a side project requires it — but because professional habits transfer, and I wanted to test whether the full workflow was realistically manageable.
What I Learned
The most interesting result wasn't the tool itself, but what building it revealed.
The experiment worked.
With clear requirements and modern AI development tools, it is now possible to build a real working tool — not just a prototype, but something capable of replacing a production spreadsheet and improving the workflow.
The cost was time and curiosity.
More importantly, this pattern is unlikely to disappear.
There's a growing gap between spreadsheets and six-figure enterprise platforms. Practitioners are filling it themselves — combining domain knowledge with accessible development tools to build what enterprise software hasn't addressed at their scale.
TenorDash is one small example. I expect to see many more.
Built with Python, Flask, SQLite, and Claude Code. All data shown is synthetic. Live demo · Source on GitHub.