Skip to main content

​
MVP Over Infrastructure: Gateway-First Beats Full-Stack Provisioning

​
Executive Summary

Building choco-gateway (Go + chi + pgx) as a single API gateway took ~3 days of implementation. The full production deployment (EKS, RDS, NATS, Redis, Linkerd, Flux CD, ESO, OTel) would take ~6 weeks. The MVP stack (3 services, 1 database, Vercel + Railway) costs 0−20/monthvs0-20/month vs 200+/month for Kubernetes. The gateway implements 15 REST endpoints — exactly what the existing frontend (cho-co-web/src/lib/api.ts) calls. Nothing more.

​
The Decision

The choco-hq platform had a full production architecture designed: 7-layer service stack, 24 services across 31 repos, Helm charts, Flux GitOps, Linkerd mesh, OTel observability. All designed, none deployed. The MVP question was: what’s the minimum stack that puts choco.tools in front of real users? Answer: 3 services (gateway, golden-press, frontend), 1 database (PostgreSQL), 2 platforms (Vercel, Railway). No Kubernetes. No NATS. No Redis. No service mesh. No observability stack.

​
What Made This Work

​
1. Existing Frontend Was API-Ready

cho-co-web already had a src/lib/api.ts with 4 domain functions (getDashboardStats, listDocuments, getDocument, getRecentActivity) that all hit ${NEXT_PUBLIC_API_URL}/api/v1/* with try/catch fallbacks returning empty data. The frontend was designed to gracefully degrade when the backend is unavailable. This meant the gateway just needed to implement those exact endpoints — no frontend changes required.

​
2. Inline Auth Eliminated a Whole Service

Instead of building a separate choco-auth service (JWT validation, Clerk webhook handling, API key management), we inlined Clerk JWT validation into gateway middleware using JWKS caching. One middleware function replaces an entire service at MVP scale. User upsert on first login means no separate registration flow.

​
3. Golden-Press Only Needed HTTP Handlers

Golden-press already had all the business logic (Ed25519 signing, advisory lock, anti-gaming rules) behind gRPC handlers. Adding 4 HTTP REST endpoints that call the same repository methods took ~100 lines. The gateway reverse-proxies to golden-press via Railway internal networking.

​
4. Migrations Were Already Written

All 8 database migrations existed in infrastructure/migrations/. Provisioning a Neon database and running psql < 000001_initial_schema.up.sql through 000008_consumer_adapter_tables.up.sql creates the complete schema.

​
Key Learning

Design for production, deploy as MVP. The full architecture (contracts, OpenAPI specs, proto schemas, Helm values, migration files) was valuable even for the MVP — it defined exactly what to build. The gateway endpoints match the OpenAPI specs. The database schema matches the migrations. The error format matches _common.yaml. The difference is deployment topology, not application design. The corollary: if your production architecture is well-designed, the MVP is a deployment decision, not a rewrite.

​
Operational Impact

  • Time to live: ~5 days (vs ~6 weeks for full stack)
  • Monthly cost: $0-20 (Vercel free + Railway hobby + Neon free)
  • Services deployed: 3 (vs 7+ for Tier 2)
  • Infrastructure components: 0 (vs EKS, NATS, Redis, Linkerd, Flux, ESO, OTel)
  • Scaling path: Clear triggers documented (>100 users → Redis, >1000 DAU → Kubernetes)
Session: choco-hq-mvp-gateway-implementation-2026-04-07 Owner: Dev4rno Archive: devarno-cloud/atlas/learnings/2026-04-07-mvp-over-infrastructure-choco-gateway.md