Board of Directors · Decision Document
Bar Talk
Architecture & Technology Decisions
Executive Summary
Bar Talk is a native mobile social app for iOS and Android that lets users check in at bars, earn rewards, discover hotspots, and receive personalized drink specials. Bars and venues can publish promotions and incentivize repeat visits.
This document presents the architectural decisions required to build Bar Talk, scored across the dimensions that matter most for our context: an AI-assisted development team building a consumer mobile app at MVP scale with intent to grow.
Recommended path: AWS-primary serverless backend, React Native + Expo mobile frontend, PostgreSQL primary database, with two pragmatic exceptions for push notifications (Firebase Cloud Messaging) and maps (Mapbox + Google Places).
Estimated time to public launch: ~5 months. Estimated monthly infrastructure cost at MVP: $300–$600. Estimated monthly cost at 50K active users: $2,500–$4,000.
Scoring Methodology
Each option is scored 1–5 (5 = best) across six weighted dimensions. The weights reflect what matters most for an AI-driven build of a consumer mobile app at our stage:
| Dimension | Weight | Why It Matters |
|---|---|---|
| AI-assisted development fit | 25% | AI is doing most of the implementation; quality of training data and idiomatic patterns directly impact velocity and bug rate. |
| Time to MVP | 20% | Speed to a launchable product matters more than long-term theoretical efficiency. |
| Operational complexity | 15% | Small team means we cannot afford heavy ops burden. |
| Cost at MVP and at scale | 15% | Runway matters. So does not getting locked into expensive scaling. |
| Hiring & ecosystem | 15% | Future engineers must be findable and productive. |
| Vendor lock-in risk | 10% | We accept some lock-in for velocity; we want to know its size. |
Weighted scores are calculated as (raw score × weight). Maximum possible weighted score: 5.00.
Decision 1 · Mobile Frontend
Options under consideration
| Option | Description |
|---|---|
| A. React Native + Expo | JavaScript/TypeScript, single codebase, Expo managed workflow with EAS Build & Submit |
| B. Flutter | Dart, single codebase, compiles to native, Google-backed |
| C. Native (Swift + Kotlin) | Two codebases, platform-idiomatic, maximum performance |
Weighted scoring
| Dimension (Weight) | A · React Native | B · Flutter | C · Native |
|---|---|---|---|
| AI-assisted dev fit (25%) | 5 | 4 | 3 |
| Time to MVP (20%) | 5 | 4 | 1 |
| Operational complexity (15%) | 4 | 5 | 2 |
| Cost (15%) | 5 | 5 | 2 |
| Hiring & ecosystem (15%) | 5 | 3 | 4 |
| Vendor lock-in risk (10%) | 4 | 4 | 5 |
| WEIGHTED TOTAL | 4.75 | 4.10 | 2.65 |
Recommendation: React Native + Expo with TypeScript
TypeScript unifies our entire stack (mobile + backend + infrastructure all in one language). The AI training corpus for React Native and TypeScript is substantially larger than for Dart/Flutter, which directly translates to fewer subtle implementation errors during AI-assisted development. Expo's managed workflow and EAS Build remove the most painful parts of mobile dev (signing, builds, OTA updates).
TRADEOFF One team member's existing Flutter experience is partially offset by the language unification benefit. Learning curve to React Native from Flutter is roughly one week to productive.
TRADEOFF One team member's existing Flutter experience is partially offset by the language unification benefit. Learning curve to React Native from Flutter is roughly one week to productive.
Decision 2 · Cloud Provider
Options under consideration
| Option | Description |
|---|---|
| A. AWS-primary | All backend infra on AWS; FCM for push, Mapbox for maps (necessary exceptions) |
| B. Firebase-primary | Firebase Auth, Firestore, Cloud Functions, FCM, Crashlytics |
| C. Azure-primary | Azure Functions, Cosmos DB, Azure AD B2C |
| D. Multi-vendor | Pick best tool per category across vendors |
Weighted scoring
| Dimension (Weight) | A · AWS | B · Firebase | C · Azure | D · Multi |
|---|---|---|---|---|
| AI-assisted dev fit (25%) | 5 | 4 | 2 | 3 |
| Time to MVP (20%) | 4 | 5 | 3 | 3 |
| Operational complexity (15%) | 4 | 5 | 3 | 2 |
| Cost (15%) | 4 | 5 | 3 | 3 |
| Hiring & ecosystem (15%) | 5 | 4 | 3 | 4 |
| Vendor lock-in risk (10%) | 3 | 2 | 3 | 5 |
| WEIGHTED TOTAL | 4.30 | 4.25 | 2.80 | 3.20 |
Recommendation: AWS-primary with FCM + Mapbox exceptions
AWS scores highest on AI fit and hiring, and ties Firebase practically. Critically, Firebase's Firestore has the same geospatial limitations as DynamoDB (a known dealbreaker for our "bars near me" feature), which negates Firebase's apparent simplicity advantage. AWS gives us PostgreSQL with PostGIS for proper geospatial queries.
TWO PRAGMATIC EXCEPTIONS Firebase Cloud Messaging (FCM) for push notifications — measurably better than AWS SNS for mobile, free, and a clean isolated integration. Mapbox + Google Places API for maps and bar data — AWS has no competitive offering here; this is unavoidable for any provider.
TWO PRAGMATIC EXCEPTIONS Firebase Cloud Messaging (FCM) for push notifications — measurably better than AWS SNS for mobile, free, and a clean isolated integration. Mapbox + Google Places API for maps and bar data — AWS has no competitive offering here; this is unavoidable for any provider.
Decision 3 · Backend Compute
Options under consideration
| Option | Description |
|---|---|
| A. Serverless (Lambda) | Pay-per-request, auto-scaling, zero ops |
| B. Containers (Fargate) | Always-running, predictable cost, easier local dev |
| C. Hybrid | Lambda for API, Fargate for jobs that exceed 15-min limit |
Weighted scoring
| Dimension (Weight) | A · Serverless | B · Containers | C · Hybrid |
|---|---|---|---|
| AI-assisted dev fit (25%) | 5 | 4 | 4 |
| Time to MVP (20%) | 5 | 3 | 4 |
| Operational complexity (15%) | 5 | 3 | 4 |
| Cost at MVP (15%) | 5 | 2 | 4 |
| Hiring & ecosystem (15%) | 4 | 5 | 4 |
| Vendor lock-in risk (10%) | 2 | 5 | 3 |
| WEIGHTED TOTAL | 4.50 | 3.45 | 3.85 |
Recommendation: Serverless (AWS Lambda + Node.js/TypeScript)
At MVP scale, Lambda's pay-per-request model means near-zero cost when idle. Auto-scaling handles viral spikes (e.g., a bar going viral on a Friday night) without intervention. Cold starts (~300ms on Node.js) are acceptable for our use case.
FUTURE PATH Add Fargate later if we introduce long-running jobs (e.g., heavy analytics aggregation). Don't pre-build it.
FUTURE PATH Add Fargate later if we introduce long-running jobs (e.g., heavy analytics aggregation). Don't pre-build it.
Decision 4 · Primary Database
Options under consideration
| Option | Description |
|---|---|
| A. DynamoDB only | Serverless NoSQL, single-digit ms latency |
| B. PostgreSQL only | Aurora Serverless v2, relational, with PostGIS for geospatial |
| C. Hybrid | PostgreSQL primary + DynamoDB for high-velocity hot paths |
Weighted scoring (with gating criteria)
| Dimension (Weight) | A · Dynamo | B · Postgres | C · Hybrid |
|---|---|---|---|
| AI-assisted dev fit (25%) | 3 | 5 | 4 |
| Time to MVP (20%) | 3 | 5 | 4 |
| Operational complexity (15%) | 5 | 4 | 3 |
| Cost at MVP (15%) | 5 | 3 | 3 |
| Hiring & ecosystem (15%) | 3 | 5 | 4 |
| Geospatial fit (gating) | FAIL | PASS | PASS |
| WEIGHTED TOTAL | disqualified | 4.45 | 3.75 |
Recommendation: PostgreSQL primary, DynamoDB introduced later when justified
Geospatial queries ("bars within 1 mile of me") are core to Bar Talk and are awkward-to-impossible on DynamoDB. PostgreSQL with PostGIS solves this elegantly. Aurora Serverless v2 gives us the serverless scaling story without giving up SQL flexibility.
CRITICAL IMPLEMENTATION NOTE Lambdas connecting directly to Aurora exhaust connection pools. We will use RDS Proxy from day one. This is the #1 mistake teams make with Lambda + RDS.
CRITICAL IMPLEMENTATION NOTE Lambdas connecting directly to Aurora exhaust connection pools. We will use RDS Proxy from day one. This is the #1 mistake teams make with Lambda + RDS.
Decision 5 · Authentication
Options under consideration
| Option | Description |
|---|---|
| A. Amazon Cognito | AWS-native, integrates with API Gateway |
| B. Auth0 | Best-in-class DX, paid per MAU |
| C. Clerk | Modern DX, polished UI, paid per MAU |
| D. Firebase Auth | Google-backed, free, simple |
Weighted scoring
| Dimension (Weight) | A · Cognito | B · Auth0 | C · Clerk | D · Firebase |
|---|---|---|---|---|
| AI-assisted dev fit (25%) | 5 | 4 | 4 | 4 |
| Time to MVP (20%) | 3 | 4 | 5 | 5 |
| Operational complexity (15%) | 4 | 4 | 5 | 5 |
| Cost at scale (15%) | 5 | 2 | 2 | 4 |
| AWS integration (15%) | 5 | 3 | 3 | 2 |
| Vendor lock-in (10%) | 3 | 4 | 3 | 2 |
| WEIGHTED TOTAL | 4.30 | 3.45 | 3.85 | 3.85 |
Recommendation: Amazon Cognito
Cognito's developer experience is rougher than Clerk or Auth0, but the deep AWS integration (API Gateway authorizers, IAM, Lambda triggers) and zero per-MAU cost win out — especially with AI-assisted development where the rougher edges of Cognito are easier to navigate. Supports Sign in with Apple, Google, and Facebook out of the box.
RECONSIDERED IF Login UX becomes a measurable conversion blocker post-launch, in which case Clerk is the upgrade path.
RECONSIDERED IF Login UX becomes a measurable conversion blocker post-launch, in which case Clerk is the upgrade path.
Cost Projection
MVP · 1,000 MAU
$306–$541
per month, all infrastructure included
Growth · 50,000 MAU
$1,859–$4,384
per month, with caching layer added
MVP Launch · detail
| Category | Monthly estimate |
|---|---|
| Aurora Serverless v2 (min capacity, baseline) | $60–$120 |
| Lambda + API Gateway | $5–$30 |
| Cognito (under 50K MAU = free) | $0 |
| S3 + CloudFront | $10–$30 |
| RDS Proxy | $30 |
| NAT Gateway | $32 |
| CloudWatch + miscellaneous | $20–$50 |
| Mapbox (under free tier) | $0 |
| Google Places API (cached aggressively) | $50–$150 |
| Firebase Cloud Messaging | $0 |
| EAS Build subscription | $99 |
| TOTAL | $306–$541 |
Growth Stage · detail
Assumes 50,000 MAU across 5 cities; DynamoDB and ElastiCache layers introduced.
| Category | Monthly estimate |
|---|---|
| Aurora Serverless v2 (autoscaled) | $400–$800 |
| Lambda + API Gateway | $200–$500 |
| Cognito | $0–$275 |
| S3 + CloudFront | $100–$300 |
| RDS Proxy | $30 |
| NAT Gateway + data transfer | $200–$400 |
| DynamoDB (added at this stage) | $50–$200 |
| ElastiCache (added at this stage) | $100–$200 |
| Mapbox | $200–$500 |
| Google Places API | $400–$1,000 |
| Firebase Cloud Messaging | $0 |
| Observability (Sentry, etc.) | $80 |
| EAS Build | $99 |
| TOTAL | $1,859–$4,384 |
These are rough estimates — actual costs depend heavily on usage patterns. Budget alarms will be configured on day one.
Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Apple App Store rejection (alcohol app) | Medium | High | Strict adherence to Guidelines 1.4.3, 4.8, 5.1.1; thorough pre-submission review; budget for 1-2 rejection cycles. |
| Google Places API cost overruns | Medium | Medium | Aggressive caching of bar data in our DB; rate limits on bar search endpoints. |
| Aurora connection pool exhaustion | High if not addressed | High | RDS Proxy from day one; load testing before launch. |
| Vendor lock-in on AWS | High (by design) | Medium (long-term) | Accepted tradeoff; PostgreSQL itself remains portable. |
| DUNS / developer account delays | High | Medium | Initiate DUNS request immediately; do not wait for code. |
| AI-generated code bugs in production | Medium | Variable | Mandatory human code review on all AI-generated code; comprehensive test coverage; staged rollouts. |
| Beta tester recruitment for Google's 14-day requirement | Medium | Medium | Recruit 15+ beta testers by month 3. |
Approval Requested
The board is asked to approve the following stack as the path forward for Bar Talk:
- Mobile — React Native + Expo with TypeScript
- Backend — AWS Lambda + API Gateway with Node.js/TypeScript
- Database — Aurora Serverless v2 (PostgreSQL + PostGIS) primary; DynamoDB introduced selectively at growth stage
- Auth — Amazon Cognito with social federation (Google, Apple, Facebook)
- Maps & push — Mapbox + Google Places API + Firebase Cloud Messaging
- Infrastructure as code — AWS CDK in TypeScript
- Build & deploy — EAS Build + EAS Submit; OTA updates via EAS Update
Time to Launch
~20 weeks
MVP Cost
$300–$600/mo
Decision Status
Awaiting Vote