I want to tell you about the three mistakes I made building FloatForex.com, because the mistakes are more useful than the success story.
The app itself — a real-time currency converter with live gold prices, forex rates for 60+ currencies, an AI chatbot, and a handful of financial tools — is live at FloatForex.com. It works well now. Getting there involved some genuinely embarrassing decisions that I would rather other developers not repeat.
Here is what I built, how I built it, and where I went wrong.

The Stack
Nothing exotic here, which was a deliberate choice:

React (Create React App + CRACO) for the frontend
FastAPI (Python) for the backend
MongoDB Atlas as the primary database and cache layer
Vercel for frontend hosting
Render for the backend service
Cloudflare for DNS and edge protection

The boring stack was the right call. Every time I considered switching to something trendier, I reminded myself that the goal was to ship a working financial tool, not to explore new technology.

The Architecture (Simplified)
The frontend is a React SPA deployed to Vercel's global CDN. It communicates with a FastAPI backend on Render. The backend sits between the frontend and a set of external APIs — forex rate providers, metals price APIs, a news aggregator, and an AI service.
The critical architectural decision was making MongoDB the cache layer between the backend and the external APIs. Every external API call is expensive, rate-limited, and slow. By fetching data on a schedule and storing it in MongoDB, I reduced external API calls from thousands per hour to a handful. The backend serves most requests from the database in under 100ms.
Background tasks handle the refresh cycle. When the FastAPI server starts, background coroutines kick off and loop indefinitely — hitting the forex API every 10 minutes, metals prices every 2 minutes, news every 10 minutes. No user request ever waits for an external API call unless the cache has expired and simultaneously received a first hit.

Mistake 1: Not Designing the Cache First
The first version hit an external API on every single request. During local development with one user (me), this was invisible. The moment I shared the staging URL with three people simultaneously, I started hitting rate limits within minutes.
The fix was obvious once I understood the problem — cache everything in MongoDB on a schedule, serve from the cache — but diagnosing it cost me two days. The lesson: if your application makes external API calls, design the caching layer before you write a single route handler. Your future self will thank you.

Mistake 2: Blocking Operations in an Async Framework
FastAPI is built on asyncio. If you put a synchronous, blocking operation anywhere in the request path, you block the entire event loop. Early in the project I used PyMongo (synchronous) instead of Motor (async MongoDB driver). Every database call was blocking the server from handling other requests while it waited for MongoDB to respond.
Switching to Motor was straightforward but required refactoring every database call. Had I made this decision upfront, it would have been a non-issue. The rule: if you are using FastAPI, every I/O operation in your route handlers must be async. No exceptions.

Mistake 3: Treating SEO as an Afterthought
The business case for FloatForex.com depends partly on organic search traffic. Currency converter searches are high-volume and commercially valuable. I knew this before I started and still left the SEO work for "later."
Later turned out to mean a painful rebuild. The app needed individual static pages for every currency pair — /usd-to-eur, /eur-to-gbp, and so on — around 380 pages total. Generating these with a build-time Node.js script that runs during Vercel deployment was the right solution, but retrofitting it into an existing app took significantly longer than building it in from the start would have.
If your project has SEO requirements — and most do — architect for them on day one.

The Deployment Reality
Render's free tier cold-starts services after inactivity. For a currency converter where users expect instant responses, a 45-second cold start is catastrophic. The upgrade to a paid plan that keeps the service warm was necessary. An UptimeRobot monitor pinging the health endpoint every five minutes adds insurance.
Vercel handled the frontend without any issues. Push to main, Vercel builds, build script generates the static pages, deployment completes in under three minutes. The GitHub integration is the right default for this kind of project.

What the App Does Now
FloatForex.com currently handles:

Live forex rates for 60+ currencies, updated every 10 minutes
Real-time gold and silver prices from institutional feeds
An AI market sentiment gauge for major currency pairs
Static pages for 380+ currency pairs with unique content
IBAN validation and SWIFT/BIC lookup
A financial news feed
Zoie — an AI chatbot scoped to forex and metals questions
A suite of financial calculators

The gold and silver charts section pulls XAU/USD and XAG/USD data, caches it, and renders price history in a way that updates on page load without a full reload.

What I Would Do Differently
Design the MongoDB cache layer before writing any API routes. Use Motor instead of PyMongo from day one. Write the static page generator in week one, not month three.
Beyond the technical decisions: ship earlier. The first version I was comfortable showing people was probably two weeks more polished than it needed to be. The feedback I got after shipping would have saved me time I spent polishing things nobody noticed.

One More Thing
If you are building something in the fintech or data-aggregation space and want to talk through architecture decisions — the async patterns, the caching strategy, the static generation approach — drop a comment below. Happy to share more detail on any of it.

FloatForex.com — live forex rates, real-time gold prices, and free financial tools. No account required.