PeakofEloquence is an open-source Islamic education platform. It is not a side project with ten users — it is a real product with 490K+ monthly active users, mostly mobile, mostly international, with spiky traffic around prayer times and holidays.

The constraint was intentional: keep the stack boring, keep it at the edge, keep the bill under $50/month. Here is what that looked like in practice.

The shape of the stack

• Static-first delivery — pages that can be pre-rendered, are. Dynamic only where the content truly requires it.
• Edge caching — HTML and assets cached close to users; cache keys tuned for locale and device class where it mattered.
• Managed database at minimum viable tier — connection pooling and read patterns matter more than raw CPU when your ORM is honest about what it fetches.
• No always-on workers — background jobs batched or deferred; cron over constant polling.
• Observability on free tiers — uptime checks and error rates, not a full APM suite.

The goal was not "serverless for aesthetics." It was matching spend to revenue for a community project that should never need a fundraiser to stay online.

What made it work

Cache hit ratio is a feature. We treated slow queries and cache misses as product bugs, not infra tickets. A page that could be static but wasn't was a defect.

Images were the hidden cost. Responsive formats, lazy loading, and aggressive CDN caching cut egress more than any server resize ever would.

Deploy simplicity reduced downtime. Small repo, predictable build, one platform. When something broke at 2am in a distant timezone, the fix was usually a revert, not a runbook spanning four services.

Community traffic is bursty. Edge caching absorbs spikes better than scaling a central origin — especially when those spikes are predictable (Ramadan, Eid, major events).

What I'd change

If I were designing it today:

• Stricter content-addressable assets — immutable filenames everywhere, longer cache lifetimes, fewer invalidation surprises.
• Earlier load testing on mobile networks — median latency in the US is not the median latency in the user base.
• Formal RTO/RPO docs — even for a volunteer-run project, "we'll figure it out" is not a backup strategy.

The stack was lean; the ops culture had to be lean too. One person on call is fine if the system fails gracefully and recovers without heroics.

The takeaway

You do not need a platform team to serve half a million users. You need clear boundaries — static vs. dynamic, cache vs. origin, must-have vs. nice-to-have — and the discipline to say no to infrastructure that does not earn its keep.

If you are building something similar: start with the bill, work backward. The architecture follows the budget more honestly than any diagram.