Forem: Eric Rodríguez

Day 91: Why I stopped using GenAI for budgeting math

Eric Rodríguez — Tue, 26 May 2026 13:00:00 +0000

When building AI-powered apps, you have to know when to turn the AI off.

Today, I was testing my Serverless Financial Agent. I asked it a simple question: "How much can I spend today without breaking my goal?"

The Amazon Bedrock LLM gave me a beautifully written, highly confident answer. The only problem? The math was completely hallucinated.

The Problem: LLMs predict the next best word; they don't do arithmetic. If you let GenAI calculate daily limits based on raw transaction data, it will eventually confidently authorize spending that bankrupts your user.

The Fix: I added a deterministic interceptor in my AWS Lambda backend.

Instead of passing the prompt directly to the AI, my Python router now uses regex to catch specific intents. If the user asks about their daily limit, Python takes over:

Deterministic Math > AI Hallucinations

safe_daily_limit = (recorded_monthly_income / days_in_month) - daily_savings_goal

If the system detects 0 recorded income for the month, it hard-stops and refuses to calculate a limit. The AI is only used to format the final delivery in its designated "tough love" persona, but the underlying numbers are strictly governed by standard code.

I also decoupled my public landing page from my authenticated React SPA.
If you want to use Google OAuth in your app, GCP requires publicly accessible /privacy and /terms pages. By splitting the routing, unauthenticated users hit a lightning-fast static landing page cached by AWS CloudFront, while authenticated users get routed directly to the heavy dashboard.

Route language to the LLM. Route math to Python. Code for intelligence, but architect for accuracy!

Day 90: Building a Resilient App Shell & Theme Engine in React

Eric Rodríguez — Mon, 25 May 2026 14:00:00 +0000

A robust serverless backend is useless if your frontend feels like an unfinished prototype. Today, I executed a complete visual and structural redesign of my Financial Agent.

Here are the technical highlights of the frontend overhaul:

Full Theme Persistence
I built a theme engine supporting System, Light, and Black modes using #171717 and #f4f5f0 base colors. Instead of just keeping this state in the browser, the React app sends the appearance_preference to the AWS backend. This ensures cross-device UI continuity when the user authenticates.
App Shell Architecture
I ripped out the top-bar navigation and implemented a proper desktop App Shell. It features a sticky left sidebar and a dedicated right insights panel for desktop. To fix native scrolling physics, I applied overscroll-behavior: none to the body, preventing the browser's default background rubber-banding.
Hardening the Local App Lock
The PIN lock screen got a UX and security upgrade. I added an invisible input over the PIN dots to seamlessly trigger the mobile keyboard. Architecturally, I implemented a custom PBKDF2 fallback for environments where the native crypto.subtle API is blocked, and wired up a backend endpoint for server-side PIN verification.

Structure your UI with the same rigor you apply to your databases.

Day 89: Building a Savings Dashboard & Reusing AI Responses (FinOps)

Eric Rodríguez — Sat, 23 May 2026 14:00:00 +0000

Adding features to an AI-powered SaaS is easy. Doing it without increasing your LLM token consumption is the real architectural challenge.

Today, I replaced the "Transactions" navigation tab with a dedicated "Savings" view in my Serverless Financial Agent. I moved existing gamification widgets there and built a new Daily Savings chart using Recharts to visualize the user's daily pacing against their target goals.

The biggest win was the FinOps strategy. The new dashboard needed a financial recommendation. Instead of triggering a new, expensive Amazon Nova prompt, I decided to recycle data.

Every morning, my AWS Lambda generates a daily report email containing a financial "Advice" section. I modified the backend to extract that exact block of text and persist it in the user's DynamoDB profile as latest_daily_savings_advice.

Now, when the React frontend loads the Savings view, it simply fetches that cached string instead of pinging the AI. If there isn't enough signal, it defaults to a deterministic math calculation. By decoupling the AI generation from the UI rendering, I expanded the product's capabilities while keeping the marginal cost at exactly zero.

Day 88: Architecting a Serverless Monetization Engine (DynamoDB & Affiliate APIs)

Eric Rodríguez — Fri, 22 May 2026 14:00:00 +0000

Building a cloud application is fun until you get the AWS bill. To make my Serverless Financial Agent sustainable, I started building a contextual Monetization Engine today by applying to strict Fintech affiliate networks (financeAds and AdCredy).

Getting approved by these networks is hard if you just have a static site. But when you explain that your traffic sits behind an AWS Cognito login and uses an AI model to evaluate real-time API banking data, you become a premium publisher.

The Architecture of Affiliate Links:
Never hardcode affiliate links in your frontend code. If a campaign pauses, your app breaks, and you have to trigger a full CI/CD pipeline just to swap a URL.

Instead, I am designing a database-driven approach:

Storage: A new FinanceAgent-Offers table in DynamoDB will hold the offer_id, affiliate_url, and category.
Logic: My Python Lambda function calculates the user's financial score. If they are broke, it pulls a credit offer from the DB. If they are saving well, it pulls an investment broker offer.
Delivery: The React app just receives a clean JSON array and renders the UI cards dynamically.

Monetization should be treated as a backend microservice, entirely decoupled from your frontend presentation layer.

Day 87: Voice-Interactive AI with Amazon Polly & DynamoDB Caching

Eric Rodríguez — Thu, 21 May 2026 14:00:00 +0000

Imagine asking your app directly, "What was my biggest expense this month?" and having it instantly reply aloud, scolding you like a ruthless personal financial coach.

Today, I built a Voice Interaction loop into my Serverless Financial Agent. The architecture mixes native web APIs with AWS machine learning services, bound together by strict cost controls.

The Audio Pipeline
For input, I used the native browser SpeechRecognition API. It's completely free and captures the user's voice, submitting the form automatically upon silence.
For output, the Python Lambda calls Amazon Polly to synthesize the AI's response using high-fidelity Neural voices.

FinOps: The Caching Layer
Amazon Polly can get expensive if abused. I built a caching mechanism in DynamoDB (FinanceAgent-Cache). Every time text is synthesized, the Base64 MP3 is saved with a SHA-256 hash of the text and language. If the same response needs to be read again, the backend serves the cached audio instead of calling Polly.

Backend Gating & IAM
I didn't just hide the microphone button in the UI. I secured the backend route (?action=synthesize_voice) to strictly reject any requests that don't match specific premium user emails verified via Cognito JWTs. Finally, I locked down the Lambda execution role with a single inline policy: polly:SynthesizeSpeech.

Voice AI is a fantastic feature, but caching and access control are what make it production-ready.

Day 86: Adding Multi-Language Support with AI Translation Caching

Eric Rodríguez — Wed, 20 May 2026 15:00:00 +0000

Translating a static React app is easy. Translating a dynamic AI agent without draining your cloud budget requires architectural discipline.

Today, I added support for 5 languages (en, es, fr, de, it) to my Serverless Financial Agent.

The biggest risk was cost. If a user toggles the language dropdown, asking the LLM to regenerate the entire financial analysis is a waste of money.

To fix this, I built a specific POST ?action=translate_message endpoint. It translates the currently visible AI string once and caches it in DynamoDB (FinanceAgent-Cache) using a SHA-256 hash of the language and text. Subsequent language toggles hit the NoSQL cache (cache_hit: true) instead of Amazon Nova, dropping the translation cost to zero.

For scheduled tasks like daily SMS alerts and email reports, the backend simply reads the user's preferred_language from DynamoDB and generates the text natively during its normal run.

Lesson learned: When scaling AI globally, caching is your best financial defense.

Day 85: Building a Secure App Lock in React with PBKDF2

Eric Rodríguez — Tue, 19 May 2026 15:00:00 +0000

Authentication gets you into the application, but what happens when a user leaves their laptop open? When building financial tools, an unattended screen is a critical vulnerability.

Today, I added a Local App Lock to my Serverless Financial Agent. While AWS Cognito handles the primary session, this new layer acts as a local inactivity shield.

The Cryptography Layer
A 4-digit PIN is easy to brute-force if stored poorly. I ensured the PIN is never saved in plain text. Instead, I used the native Web Crypto API. The application generates a random salt and hashes the PIN using the PBKDF2 algorithm with SHA-256. Only pinHash and pinSalt live in localStorage, keeping the device secure.

Idle Detection
I built an event listener hook that tracks pointer movements, key presses, and touch events. If the user is inactive for 10 minutes, the financial dashboard is immediately obscured by the lock screen. It also tracks the visibilitychange event, measuring the exact elapsed time when the tab is running in the background.

The "Forgot PIN" Failsafe
If a user forgets their local PIN, there is no simple "reset link." For maximum security, clicking "Forgot PIN" instantly clears the local App Lock state and executes a hard sign-out via the AWS Amplify SDK. The user must fully re-authenticate with their Cognito credentials and create a brand new PIN from scratch.

Frontend security is about defense in depth. Never trust local storage with plain text secrets, even if it is just a simple 4-digit PIN.

Day 84: Merging Cognito Identities & Surviving a 502 Gateway Error

Eric Rodríguez — Mon, 18 May 2026 15:00:00 +0000

Today I almost broke my serverless production environment, but AWS disaster recovery features saved the day.

I was deploying a major update to my Financial Agent to fix a split identity issue. Users logging in with Email/Password and Google OAuth were getting separate DynamoDB partitions. I rewrote the backend to unify the identity resolution around the verified email address.

At the same time, I was updating the transaction classification logic. The system needed to strictly separate refunds/credits from actual income so the AI wouldn't hallucinate false financial praise.

The Deployment Incident:
I deployed the new Python code to AWS Lambda, but I forgot to package a newly required module in the deployment zip. The immediate result was a global 502 Bad Gateway. While trying to patch it quickly, I caused a 500 Internal Server Error by calling an unimported configuration variable.

The Rollback:
Because I treat my serverless infrastructure seriously, I had taken two precautions before deploying:

I created DynamoDB On-Demand backups for my Cache, Memory, and Transactions tables.

I published numbered versions of my Lambda function instead of just overwriting $LATEST.

Instead of panicking and writing hotfixes in the AWS Console, I simply rolled back the API Gateway to point to Lambda Version 1. The system stabilized instantly. I then fixed my local code, bundled the dependencies correctly, and deployed Version 4 cleanly.

The lesson here is simple: Never deploy major logic changes without database backups and function versioning. Rollbacks should be a one-click operation, not a debugging session.

Day 83: AWS SNS SMS Alerts & Segment Cost Optimization

Eric Rodríguez — Fri, 15 May 2026 15:00:00 +0000

Adding SMS alerts to your serverless application is incredibly easy with AWS SNS. Keeping those alerts cheap, however, requires a bit of FinOps knowledge.

Today, I restored the SMS alerting feature for my Serverless Financial Agent. If a user spends more than 100€ in a day, the system sends them a harsh financial reality check via text.

Here are the critical architectural updates I made to secure the pipeline and optimize costs:

The ASCII-Only Rule
Initially, the AI included emojis in the SMS text. This was a costly mistake. Emojis force the message into UCS-2 encoding, shrinking the SMS segment limit from 160 characters to just 70. By refactoring the Python logic to use ASCII-only rotating phrases, I avoided multi-segment billing charges entirely.

Strict IAM Policies
I removed any broad SNS permissions from the Lambda execution role. Instead, I attached a granular inline policy: FinanceAgentSmsPublish. This ensures the Lambda only has the sns:Publish action allowed.

Account-Level Guardrails
AWS SNS can get expensive if a bug causes an infinite loop of messages. I configured the SNS MonthlySpendLimit attribute to a strict $1 limit while operating in the SNS Sandbox environment.

The Lesson: When writing cloud-native code, you must treat your cloud bill as an architectural constraint. Optimize your payload encoding and always lock down your IAM roles.

Day 80: Building an Event-Driven Bank Sync Pipeline (Webhooks, SQS & DynamoDB Locks)

Eric Rodríguez — Fri, 15 May 2026 15:00:00 +0000

When building fintech applications, letting the client dictate when to fetch third-party banking data will eventually destroy your API rate limits and skyrocket your cloud bill.

Today, I tore down my reactive data-fetching logic and replaced it with a resilient, event-driven webhook architecture using AWS Lambda, Amazon SQS, and DynamoDB. Here is how I solved the core architectural bottlenecks in my Serverless Financial Agent.

Fixing the Stale Dashboard & Identity Resolution
My React dashboard was showing stale data, while the daily automated emails had real-time numbers. The root cause? An identity partition mismatch. The background worker was using a default ID, while the frontend sometimes resolved to an email address instead of the strict Cognito sub ID. I unified the identity resolution algorithm so both endpoints read and write to the exact same DynamoDB partition.

Event-Driven Sync Pipeline
I deprecated the dangerous user-triggered "Force Sync" pattern. Instead, I implemented a persistent Plaid Access Token and shifted to a Webhook-to-SQS pipeline.
Now, when a transaction is added, modified, or removed, the Plaid API fires a webhook to my Lambda. To avoid timeouts, the Lambda instantly pushes a sync_transactions task to an SQS queue (FinanceAgent-SyncQueue) and returns a fast 202 Accepted back to the bank.

Cursor-Based Sync & DynamoDB Locks
The background SQS worker processes the event using a new /transactions/sync logic with a persistent cursor, fetching only the exact delta of changes. If the cursor fails, it gracefully falls back to the standard /transactions/get method.
To prevent API abuse, I built atomic sync locks in DynamoDB. If a sync is already running, the request is safely ignored. I also added strict routing logic to protect my live Wise profile from this Plaid-specific reactive sync behavior.

Curing AI Hallucinations
Finally, I patched the semantic AI layer. The system was treating credit card refunds and cashbacks as actual "Income," artificially inflating the user's AI Financial Health Score. I updated the classification engine to isolate real income (payroll, Gusto, interest) from simple cashflow corrections, ensuring the AI context is 100% accurate.

Verification & Next Steps
I verified the backend with Python compile checks, confirmed Lambda deploys (LastUpdateStatus=Successful), and validated the webhook endpoints. Next up: replacing the Sandbox Link flow with real production access tokens.

Day 80: Stop letting your AI hallucinate on dirty data (Fintech Edge-cases)

Eric Rodríguez — Thu, 14 May 2026 15:00:00 +0000

When you build AI-powered applications, the most important code you write has nothing to do with AI. It has to do with data sanitization.

Today, my Serverless Financial Agent was aggressively lecturing me for spending 500€. The catch? I didn't spend it. I transferred it between my own multi-currency accounts using Wise.

The Problem:
My backend was blindly feeding raw transaction arrays to Amazon Bedrock. The LLM saw a -500€ transaction and did exactly what I prompted it to do: it roasted me for bad financial habits. If your context window is fed garbage, the output will be garbage.

The Fix:
I had to build a deterministic sanitization layer before the LLM ever sees the data. I wrote a strict filter in the frontend to handle business logic mapping.

const INTERNAL_TRANSFER_RE = /^to (eur|usd|gbp|chf|pln|ron|huf|czk|sek|nok|dkk)\b/;

const isInternalTransfer = (tx) => {
const desc = String(tx.description || '').trim().toLowerCase();
return tx.is_internal === true || desc === 'balance' || INTERNAL_TRANSFER_RE.test(desc);
};

By explicitly flagging internal transfers and edge cases like intrst (Interest Payments), I prevented them from being grouped into the totalExpenses array.

Alongside this, I shipped two new UI components: Velocity Analysis and a Savings Streak calculator. Now, the React app mathematically proves to the user exactly why they are hitting their daily goal, comparing their dailyIncome against their todayExpenses.

The Golden Rule:
Do not use GenAI for deterministic math or data cleaning. Clean the data with code, calculate the limits with math, and use the LLM solely to explain the clean results to the user.

Day 80: When your Frontend and Backend disagree on math (Fixing Data Sync in Fintech)

Eric Rodríguez — Wed, 13 May 2026 15:00:00 +0000

When building full-stack financial apps, your standard math logic needs serious guardrails.

Today (Day 80 of my build!), I was fine-tuning the Month-End Projection widget for my AI Financial Agent.

The Problem: My React dashboard looked great, showing €86 in expenses. But my Serverless Python backend was returning a projection of €168. To make matters worse, if I clicked on "April" (a past month), the system would project a completely broken number instead of just showing the final closed amount.

The Fix: I had to implement three architectural changes to force my backend to respect the passage of time and match the frontend's business logic.

Aligning Business Rules (The Mirror Filter) My React code was hiding internal currency conversions (like Wise "To EUR" transfers) from the expense chart. But my Python Lambda was just summing up everything that wasn't an income. Fix: I added an aggressive regex-style filter in the backend to match the UI perfectly.

Python

Aggressive Filter for Wise and Plaid

is_internal = (
t.get('is_internal', False) or
any(x in desc for x in ['to eur', 'to usd', 'to gbp', 'balance', 'conversion'])
)
if not is_income_tx(desc, amt) and not is_internal:
target_month_expenses += abs(amt)

The "Smart Sync" Pattern
I have a 7 AM Cron Job that fetches new bank data daily. But what if the month rolls over to May 1st at 2 AM, and the user logs in before the Cron runs? They would see an empty dashboard.
Fix: A lightweight fallback. On load, the Lambda checks the server's absolute clock. If the DynamoDB query for the current month (2026-05) returns empty, it forces a real-time fetch to the bank APIs.
Temporal Math
You can't calculate a "daily burn rate" projection for a month that is already over.
Fix: The backend now checks the target month against the current system month. If it's a past month, projected_spend = total_expenses. Period.

Code for the happy path, but architect for the edge cases!