How I Built a Credit Card Management Dashboard (And Why Spreadsheets Were Not Cutting It)

I had 17 credit cards open. Each one had a purpose. 0% APR on a balance transfer expiring in four months. A business card earning 3x on advertising. A personal card with rotating 5% categories. Another business line I used specifically for inventory purchases.

I tracked all of this in a Google Sheet. Columns for card name, issuer, credit limit, current balance, APR, promo rate, promo expiration date, annual fee date, reward structure, and notes. Color-coded rows for urgency. Conditional formatting that was supposed to flag upcoming deadlines.

It worked for about two years. Then it stopped working.

The Breaking Point

I missed a 0% APR expiration on a card carrying a $12,000 balance. The promotional rate ended on a Tuesday. I did not check the spreadsheet that week. The standard APR kicked in. By the time I noticed, I owed interest I never needed to pay.

The spreadsheet had the date in it. The conditional formatting was set up correctly. The problem was not the data. The problem was that a spreadsheet does not tap you on the shoulder and say "hey, you have 7 days before this rate expires and you still have $12,000 on this card."

That was the moment I decided to build something better.

What I Actually Needed

Before writing any code, I wrote down the things that had gone wrong over two years of spreadsheet-based card management:

1. No proactive alerts. The spreadsheet shows data. It does not push notifications. I had to remember to check it, and I did not always remember.
2. Utilization was manual math. Calculating total credit utilization across 17 cards meant updating balances, summing them, dividing by total limits. Every time.
3. No "which card should I use" logic. I knew the reward structures in my head, mostly. But I regularly used the wrong card at the wrong merchant because I was not thinking about it in the moment.
4. Annual fee decisions were reactive. I would notice the fee on my statement instead of evaluating whether to keep the card before the fee hit.
5. Application tracking was a mess. Am I under Chase's 5/24? When was my last application with Amex? I had to count manually.

The Technical Approach

I am not going to pretend this needed bleeding-edge technology. The core problem is data management and timely notifications. Here is what mattered:

Data Model

Every credit card is an object with these core properties:

- Card name / issuer
- Credit limit
- Current balance (manual or API-synced)
- Standard APR
- Promotional rate (if any)
- Promotional rate expiration date
- Annual fee amount
- Annual fee date
- Reward structure (categories + multipliers)
- Application date
- Last statement date
- Payment due date

The tricky part is that some of these properties are time-dependent. A card's effective APR changes when the promo expires. Reward categories rotate quarterly. Annual fees create decision points that need to be surfaced before the charge hits.

Deadline Engine

The most important feature. Every card generates a set of deadlines:

• Promo rate expiration (alert at 90, 60, 30, 7 days)
• Annual fee renewal (alert at 60 and 30 days before)
• Payment due date (alert at 7 and 3 days before)
• Rotating category activation windows

Each deadline has a severity level and an associated action. "Your Citi card's 0% APR expires in 30 days. Current balance: $8,400. Action: pay off or transfer." That context is what a spreadsheet cannot provide.

Utilization Calculator

Real-time (or near-real-time) calculation of:

• Total utilization across all cards
• Per-card utilization
• Utilization impact if you move a balance from Card A to Card B

This sounds simple, but it becomes genuinely useful when you are deciding whether to put a $3,000 purchase on your Chase card (pushing that card to 45% utilization) or your Amex (which stays at 12%). The per-card utilization matters for your credit score, not just the total.

Card Selector

Given a spending category (groceries, gas, dining, online, etc.), which card in your portfolio earns the best return? This requires knowing:

• Base reward rate per card
• Bonus categories per card (including rotating quarterly bonuses)
• Whether quarterly bonuses have been activated
• Any spending caps on bonus categories

It is essentially a lookup function, but one that changes quarterly and needs to account for caps and activation status.

What I Learned Building This

Financial data is messy

Credit card terms are not standardized. One issuer calls it "promotional APR." Another calls it "introductory rate." The expiration logic varies. Some promos end on a specific date. Others end "18 months after account opening," which means you need to calculate the date from the application date.

People do not update manually

I built the first version with manual balance entry. Nobody used it consistently. The dashboard was only useful when the data was current, and manual data entry creates a chicken-and-egg problem. I had to find ways to minimize manual input or make it frictionless.

Notifications are the product

The dashboard is nice. The charts are helpful. But the thing that actually prevents expensive mistakes is the notification that arrives three days before a promo rate expires. Everything else is secondary to that alert engine.

YMYL content requires extreme care

Building in the financial space means your content is classified as "Your Money, Your Life" by search engines. Google holds YMYL content to a higher standard. Every number needs to be accurate. Every claim needs to be defensible. You cannot publish sloppy financial advice and expect to rank.

Current State

StackEasy is live and people are using it. The core features that matter most:

• Portfolio dashboard showing all cards, balances, limits, and utilization at a glance
• Deadline tracker with proactive alerts for promo expirations, annual fees, and payment dates
• Card selector that recommends the best card for each spending category
• Application log that tracks your velocity across issuers

The biggest validation was when users told me they caught a promo expiration they would have missed. That is the whole point. Not the charts, not the UI polish. Did you avoid losing money you did not need to lose?

For Other Builders

If you are thinking about building in fintech, here are the non-obvious lessons:

1. Start with your own pain. I built StackEasy because I needed it. That meant I understood the edge cases before writing a single line of code.
2. Management tools are undervalued. Everyone builds tools to help people find or buy financial products. Almost nobody builds tools to help people manage what they already have.
3. Simple beats clever. A deadline alert that fires on time is worth more than a machine learning model that predicts spending patterns.
4. Trust is everything. People are entering their financial data. Earn that trust through transparency, security, and never being clever with their information.

---

If you are managing multiple credit cards and a spreadsheet is starting to crack, check out StackEasy. Happy to answer questions about the build in the comments.