Matching Local Businesses to Grants with a Cost‑Efficient React App on AWS

Overview

For a Non Profit Environmental Awareness Organization, we delivered a React single‑page application hosted on AWS Amplify, backed by serverless APIs and DynamoDB to minimize operational overhead and control costs. The app ingests grant data from multiple sources, normalizes eligibility rules, and surfaces geo‑matched opportunities to local businesses via an intuitive map and search experience.

The challenge

• Budget-sensitive customer needing predictable, low monthly costs.
• Data scale and variability from multiple sources.
• Low ops tolerance — preferred managed services.
• Need for fast map queries and near‑real‑time updates.

Objectives

• Build a responsive, map‑centric React app to match businesses to nearby grants.
• Minimize infrastructure and ongoing operational costs.
• Keep latency low for map queries while supporting growth.
• Deliver quickly with low maintenance burden.

Solution

A serverless architecture on AWS centered on Amplify for hosting and CI/CD, Lambda for ingestion and APIs, and DynamoDB as the primary data store to balance performance, scale, and cost.

Cost‑focused architecture highlights

• Frontend: React app deployed via AWS Amplify (low-cost hosting with automatic CI/CD).
• Ingestion: Scheduled Lambdas process feeds — billed only for execution time.
• Storage: DynamoDB for low‑maintenance, predictable-cost reads/writes and efficient storage of semi-structured grant records.
• Caching: CloudFront and Lambda-level caches to reduce DynamoDB read usage.
• Capacity strategy: started on DynamoDB On‑Demand to avoid provisioning risk, then migrated to Provisioned Capacity + Autoscaling after traffic patterns stabilized to lower RU costs.
• Optional lightweight OpenSearch only for targeted full‑text needs to avoid expensive persistent search instances.

How money was saved

• Serverless vs. managed VMs/RDS: eliminating EC2 and RDS reduced baseline monthly costs (no always‑on DB instances, no patching/ops labor). Estimated savings: 40–60% compared to an equivalent relational deployment for expected traffic.
• DynamoDB access pattern optimization: by designing keys and precomputing geohash buckets, most map queries became single‑partition reads (single‑item or small batch reads), minimizing read capacity units (RCUs). This produced predictable, low per‑query costs versus frequent costly scans.
• On‑demand → provisioned capacity: starting on On‑Demand avoided over‑provisioning during launch; switching to Provisioned Capacity with Autoscaling after stable usage reduced RCU/WCU expenses by ~25–35% based on observed traffic.
• Caching hot queries: CloudFront and in‑Lambda caches served repeated bounding‑box and tile requests, cutting DynamoDB reads for popular queries by up to 70% and lowering monthly data‑access charges.
• TTLs and deduplication: automated TTL for stale grants and deduplication reduced storage costs and write load; storage and write costs dropped by ~15% after cleaning old records.
• Targeted OCR and batch processing: limiting OCR to large/critical PDFs and running heavy jobs in off‑peak windows reduced Lambda execution time and avoided high on‑demand spikes.
• Reduced ops headcount/time: fully managed services cut day‑to‑day ops by ~70%, saving indirect costs (server maintenance, backups, tuning) and letting the small team focus on product and data quality.

Quantified impact

• Estimated infrastructure cost reduction vs. a comparable EC2+RDS+ElasticSearch stack: 40–60% monthly.
• Read cost reduction from caching and optimized access patterns: up to 70% fewer DynamoDB reads for hot queries.
• Storage and write savings from TTLs/deduplication: ~15% lower monthly storage/write spend.
• Operational savings (people/time): ~70% less ops burden, equating to reallocated engineering time worth multiple thousands USD/month depending on team rates.

Implementation highlights that enabled savings

• Precomputed geohash buckets and GSIs to convert scans into targeted reads.
• Caching layers (CloudFront + in‑Lambda) to serve repeat queries cheaply.
• Autoscaling provisioned capacity after launch to lock in lower per‑unit costs.
• Use of Amplify hosting (free tier + low rates) and Cognito for auth to avoid custom auth services.
• Conservative OCR and heavy‑job scheduling to avoid peak‑price execution.

Business results (measured)

• MVP launched in 8–10 weeks with low upfront infra spend.
• Platform scaled to handle regional campaigns and traffic spikes without manual intervention.
• Monthly infrastructure spend low enough to support a freemium model and invest savings back into data acquisition and UX.
• Faster time to market and lower ongoing costs improved unit economics for small‑business customer acquisition.

Customer impact

Campaign: County small‑business relief rollout

• Costs: deployment and hosting costs remained within pilot budget due to on‑demand resources and caching.
• Outcome: Unified Ground published matching maps in 48 hours; increased applications routed through the platform while keeping per‑user infrastructure cost low.

Lessons learned

• Design data access for DynamoDB from day one — wrong access patterns drive cost.
• Cache aggressively at the edge for repeated map queries.
• Start on On‑Demand to avoid over‑provisioning; move to Provisioned+Autoscaling after traffic stabilizes.
• Automate TTLs and deduplication to avoid paying for stale data.
• Monitor billing closely and set alarms for unexpected spikes.

Bottom line

By pairing a React frontend on AWS Amplify with DynamoDB and serverless compute, Unified Ground delivered a fast, scalable grant‑matching app that kept infrastructure and operational costs low. Careful data modeling, caching, and capacity strategies produced concrete savings (40–60% vs. traditional stacks) and allowed the team to invest more in data quality and product growth.