The Board: Building a Fixed Deposit Rate Tracker for Sri Lanka with AI-Assisted Development

Introduction

If you've ever tried to open a fixed deposit in Sri Lanka, you know the problem: every bank and finance company publishes its rates on its own website, in its own format, and none of them make it easy to compare. Some bury the numbers in a PDF, some in an image, some in a table that changes shape every few months. There was no single place to just see who was actually paying the best rate right now.

So I built The Board - a site that tracks fixed deposit rates across roughly 40 banks and NBFIs (non-bank finance companies) in Sri Lanka, updates itself daily, and keeps a full history of every rate change. I architected the system - the pipeline design, the database model, the API boundaries - and used AI coding agents to help implement it, the same way I've approached my last few projects. It's a good showcase of what that workflow actually looks like end to end: scraper pipeline, read API, public frontend, and an admin panel, all built and shipped in a single focused effort.

What It Does

• Tracks ~40 institutions - every licensed bank and finance company that publishes FD rates
• Extracts rates automatically from whatever format each site uses - HTML tables, PDFs, images, or JS-rendered pages
• Keeps a full history - every rate change, not just the current snapshot
• A public board ranking every institution's best rate, plus a side-by-side comparison tool filterable by tenure, customer type, and payout frequency
• A public request form so visitors can ask for a bank that isn't tracked yet
• An admin panel to manage which institutions are visible, review those requests, and see exactly what the daily scrape did - and why anything failed

Backend Design

The backend is a Python scraping pipeline sitting on top of PostgreSQL, with a FastAPI service reading from it.

The pipeline runs once a day against every configured institution. Each one gets its own config describing where its rates live and which extraction method applies - a plain HTML table parser for the common case, a PDF table extractor for the banks that publish a tariff sheet instead, OCR for the ones that only publish a rate image, and an LLM-based fallback for anything that doesn't fit the other three. If the primary method fails, it automatically degrades to the fallback rather than just failing outright.

Every extracted rate gets a confidence score before it's trusted. Low-confidence extractions (usually from OCR or the LLM fallback) get quarantined instead of published - they land in the database, but flagged, so a bad OCR read never silently overwrites a real rate on the public site.

The schema is append-only by design: nothing gets updated in place, every new rate is a new row, which is what makes the full rate-history view possible - for any institution you can see exactly when a rate moved, in which direction, and what it moved from. Every scrape attempt is logged too - what ran, when, which extraction method it used, how many rows it produced, and the full error if it failed - which is what the admin panel's pipeline view is actually reading from.

The read API is FastAPI, cached at the query level since the underlying data only changes once a day, with a scoped, read-only database role - it can't write anything even if a query were somehow built wrong. Writes (admin actions, the public request form) go through a separate, narrowly-scoped role that can only touch the tables it needs to. Admin auth is a straightforward JWT-based login layered on top, gating everything else in the admin panel.

Frontend Design

The frontend is Next.js (App Router), rendered mostly on the server - every rate lookup happens in a Server Component, and the mutations (submitting a request, toggling an institution's visibility) go through Server Actions rather than a separate client-side API layer. The visual identity leans into a passbook/ledger metaphor - it's a rates board, so it should look like one.

The public side covers the leaderboard above, a per-institution page with its full rate history, and a comparison view that re-sorts live as you change tenure, customer type, and payout frequency:

There's also a public form for visitors to request a bank that isn't tracked yet - which feeds straight into the admin panel below:

Admin Panel

The admin panel is where I spent the most time thinking about what actually needed to exist versus what would just be nice to have. It ended up covering three things: institution management, request handling, and pipeline visibility.

From the dashboard, an admin can hide or show any institution from the public board (useful when a rate looks wrong and needs a second look before it's public), and work through the queue of visitor-submitted requests - mark them done once the institution's been added, or dismiss them.

The part I found most useful in practice, though, is the pipeline view. A daily scraper against ~40 external websites will fail sometimes - a bank redesigns its page, an OCR call runs out of API credits, a source times out - and previously the only way to know was to read raw logs. Now there's an actual health board: which institutions succeeded, which were quarantined and why, which failed and with what error, right down to the exact rate values a run produced compared to what they replaced.

AI-Assisted Development Experience

This was built end to end with an AI coding agent doing most of the implementation, while I stayed in the architect/reviewer seat - deciding the pipeline shape, the database model, and where the security boundaries needed to sit.

Where it helped most was exactly where I expected: the repetitive parts. Wiring up four different extraction methods with a consistent interface, the FastAPI/Pydantic boilerplate, the admin CRUD screens - all of that moved fast. The parts that needed judgment - what should quarantine versus publish outright, what a hidden institution should actually mean at the API layer, whether a partial pipeline failure should block the rest of the run - I made those calls myself and had the agent implement them, then reviewed the result against real data before trusting it.

Try It

The site is live at fdrate.randhana.com - the public board, the comparison tool, and the request form are all open to anyone. The admin panel is naturally login-gated.

Conclusion

The Board project was not only about scraping data. We used four different extraction methods and made sure they all produced data in the same format.

The bigger challenge was deciding what should happen after the data is collected. We needed to decide what information could be published automatically, what should be checked by a person first, and how to clearly identify the reason when something fails instead of leaving missing data without an explanation.

That is the part of the project I consider my main contribution. AI helped during development, but the decisions about safety, human review, and error handling were my own.