STRATUM

• 

  vercel-production-map

• 

  vercel-neighborhood-score-card

• 

  dynamodb-proof

• 

  aurora-rds-running-proof

Inspiration

Three weeks ago I'm in a coffee shop and I overhear two strangers complaining about the same broken streetlight. It's been out for two months. Neither of them had reported it. Why would they — 311 is a black hole, Nextdoor is just parking arguments.

That's not a small problem. Every city on earth has millions of residents sitting on real, useful, hyperlocal intelligence about their own streets. And it just evaporates. Every single day.

I wanted to build something where the infrastructure itself was the proof it could scale. Not a slide deck claim. Actual receipts.

What it does

You open Stratum. You see your neighborhood. You tap once, pick a category, submit. Fifteen seconds, no login, nothing.

That signal joins thousands of others and gets clustered into four live layers — Safety, Vibe, Infrastructure, Opportunity. Click any cluster and you see a real neighborhood health score, updated in real time as new reports arrive and old ones age out.

The business model is simple: residents generate the data for free because it's their neighborhood. Realtors pay $49/month to see trend data before they list. Cities pay $299/month to see exactly where their infrastructure is quietly failing before it becomes a crisis. Everyone wins or nobody uses it — that's the right alignment.

How we built it

The core decision was refusing to pick one database.

Every anonymous report is a write — fast, simple, geographically clustered, needs to feel instant no matter where on earth it comes from. That's DynamoDB down to its design philosophy. I partitioned the reports table by geohash, 6 characters, roughly one square kilometer per cell. One decision, and every "show me what's near here" query hits a single partition. No scans. No cross-partition overhead. The spatial query becomes essentially free.

But the second you need anything relational — 7-day neighborhood trends, API rate limiting, subscription status, billing aggregations — DynamoDB actively fights you. That's Aurora PostgreSQL's job. It handles all the relational state cleanly. Right tool, right problem. Not a compromise, a choice.

Frontend is Next.js 14 on Vercel, map renders on free OpenFreeMap tiles so there's zero map API bill. A scoring engine sits between the two databases — pulls recent reports from DynamoDB, applies recency weighting where today counts five times more than last month, writes computed scores into Aurora.

I got obsessive about write latency because the whole product lives or dies on whether submitting a report feels instant. DynamoDB from Vercel edge: under 80ms consistently. That's not a benchmark I'm estimating — I measured it.

Challenges we ran into

The hardest part was nearly talking myself out of the whole dual-database architecture. Two clients, two credential sets, two mental models — for about a day I genuinely considered just dumping everything into Aurora. What stopped me was running the actual numbers. Aurora Serverless cold starts were pushing 800ms on the write path. That's the difference between something that feels alive and something that feels broken. That benchmark kept the architecture honest.

Geohash length was its own puzzle. 4-character cells are the size of a city district — useless for neighborhood-level signals. 8-character cells are basically a building — too granular. 6-character is the sweet spot, roughly a neighborhood block. I use 4-character for rolled-up analytics scores because that resolution makes sense at the city dashboard level. Different zoom for different jobs.

Auth broke silently in production because NEXTAUTH_URL was wrong in Vercel's env config. The error told me nothing. Took an embarrassingly long time to find a one-line fix. Added a one-click demo login afterward specifically so nobody evaluating this ever has to touch OAuth to see the dashboard.

And the map took more iteration than anything else in the build. Dot sizing, pulse animation on recent reports, default zoom level — all small things, all things that determine whether this reads as a product or a debug overlay.

Accomplishments that we're proud of

Watching the DynamoDB table fill up with real geohashed rows while Aurora's score table updates underneath it. Seeing your own architectural decisions show up as actual data instead of staying theoretical. That's the thing.

The geohash partition key specifically. Invisible if you don't know what you're looking at. Decisive if you do.

And backing up the latency claim with a real number. Every hackathon submission says "built to scale." Almost none of them have a benchmark behind it.

What we learned

Database selection is a design decision, not a day-one implementation detail you set and forget. A single application can contain multiple genuinely different problems. Forcing them through one tool is a debt you pay later — usually at 2am, under real load, when the wrong index turns a simple query into a nine-second one.

Measure before you assume. I was certain Aurora Serverless would be fast enough for writes. It wasn't. The number told me what my intuition couldn't.

What's next for STRATUM

The obvious next move is mobile — this interaction belongs in a pocket, not a browser tab. After that, DBSCAN clustering so the layers reflect real incident density instead of raw counts.

The one I actually care about: getting this in front of a city planner. Not to pitch it. Just to show them the dashboard and watch what they do with it. That conversation will tell me more than six more months of building.

Built With

• awsaurorapostgresql
• awsdynamodb
• nextjs
• typescript
• vercel