DEV Community: Eric Rodríguez

Day 94: Stop using .pem for Apple Push Notifications. Do this instead.

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

Today, I built the push notification engine for my Serverless AI Financial Agent. The goal was simple: if a user spends >100 EUR in a day, hit their iPhone with an alert and update their Home Screen widget.

Getting AWS Lambda to talk to APNs (Apple Push Notification service) requires authorization.

The Mistake You Are Probably Making:
Generating a .pem certificate in the Apple Developer Portal. These expire every year, requiring manual intervention, and they force you to manage separate certs for Sandbox and Prod.

The Architecture Fix:
Use Token-Based Authentication (.p8).

Generate a .p8 Auth Key in the Apple Developer portal. It is Team-Scoped and never expires.
Go to AWS SNS -> Push notifications.
Create a Platform Application (Apple iOS/VoIP/Mac).
Choose Token for authentication (not Certificate).
Paste your Key ID, Team ID, Bundle ID, and the .p8 file.

Now, your AWS Lambda doesn't need to struggle with APNs connections. It just fires an event:

Lambda just publishes to SNS. SNS handles Apple.

sns.publish(
TargetArn=os.environ['APNS_SANDBOX_PLATFORM_APPLICATION_ARN'],
Message=json.dumps(apns_payload),
MessageStructure='json'
)

Widget Syncing Issue:
iOS heavily sandboxes processes. If your app receives the push notification, your Widget cannot read the new data.
To fix this, you must configure an App Group (e.g., group.com.yourcompany.app). This creates a shared memory space. The main app receives the SNS push, writes the new spending limit to the App Group's UserDefaults, and the Widget reloads its timeline reading from that exact same shared space.
Stop managing certificates. Start building scalable infrastructure.

Day 93: Bridging React to iOS Widgets and Face ID

Eric Rodríguez — Thu, 28 May 2026 16:00:00 +0000

Taking a web app to mobile isn't just about making it responsive. It's about tapping into the OS.

Today, I expanded the native iOS capabilities of my Serverless Financial Agent using Capacitor.

The Auth Flow: Face ID + PIN
Relying solely on AWS Cognito for every app open is slow and ruins the mobile experience. I already had a local PIN system, but typing a PIN is tedious.

I integrated the NativeBiometricAuthPlugin to trigger Face ID. If Face ID succeeds, the local session unlocks. If it fails (or the user cancels), it seamlessly falls back to the local PIN. Zero-trust security without the friction.

The Data Flow: React to WidgetKit
I wanted my users to see their "Spending Overview" directly on their iOS Home Screen.

The challenge? React (running in a WebView via Capacitor) cannot talk to an iOS Widget (written in Swift).

The solution was an Apple App Group.
I created a shared directory: group.com.quiklygroup.duromoney.
I built a custom native plugin. When my React app receives new financial data from my AWS Lambda backend, it sends a snapshot to the plugin, which writes it to the App Group. The native iOS widget then reads that snapshot and updates the Home Screen.

The Permission Strategy
I also restructured the onboarding. I intentionally delay asking for Push Notification and Face ID permissions until after the user has logged in and seen their financial dashboard. If you ask for permissions before showing value, users will deny them.

Build the backend for scale, but design the frontend for humans.

Day 92: Moving to iOS and the Apple Push Notification roadblock

Eric Rodríguez — Wed, 27 May 2026 16:00:00 +0000

Taking a cloud-native web app to mobile introduces a whole new set of architectural challenges.

Today, I wrapped my React SPA into a native iOS app using Capacitor. The goal was to maintain a single codebase communicating with my AWS Lambda backend while gaining access to native device features.

The Auth Fix: Deep Links
Authentication is notoriously tricky when moving from Web to Mobile. I use AWS Cognito for OAuth (Google Sign-In). On mobile, when the browser finishes the auth flow, it needs to know how to return to the app.

I had to configure the iOS App.xcworkspace to accept custom URL schemes and update my Cognito App Client to accept duromoney://localhost as a valid callback URL. Without this, users log in and get stuck staring at a blank Safari screen.

The FinOps Dilemma: SMS vs. Push
Right now, my AI agent sends "High Spending" alerts via SMS using Amazon SNS. SMS costs money. Push notifications don't.

I wrote the backend logic to register the device token and push alerts via APNs (Apple Push Notification service) alongside the SMS so I could compare latency.

The Roadblock
I hit a hard wall. Xcode refused to build, throwing:
Personal development teams do not support the Push Notifications capability.

AWS lets you build multi-region serverless architectures for pennies. Apple won't even let you send a local test Push Notification to your own device unless you pay the $99/year Apple Developer Program fee.

The Fix for Now: I'm keeping the SMS fallback active. Once the paid Apple Developer account is active, I will extract the .p8 Auth Key, Team ID, and Bundle ID to create an APNS_SANDBOX Platform Application in AWS SNS and finally bypass the SMS costs.

Cloud providers give you the tools. Mobile platforms sell you the keys!

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.