The Principal Engineer's Agentic Coding Bible · Episode 05
The Principal Engineer's Bible, Part 5: Production Architecture, MVP to Real Apps
A six-part guide for the IT/Cyber/Cloud generalist now orchestrating AI agents. Part 5 is the production architecture playbook. The Vercel + GCP split, Expo + React Native for mobile, Supabase + Postgres + Row-Level Security as the non-negotiable, and the five-stage SDLC runbook from ideation to V1 hardening.
Listen in my voice · AI narration (ElevenLabs clone)
Watch the episode · AI-generated video
On this page
- The Vercel + GCP Split (the boring choice that wins)
- Domain and Routing Standard
- Mobile Development: Expo + React Native (the debate is over)
- OTA (over-the-air) update strategy
- Database Layer: Supabase + Postgres (and the RLS rule that’s non-negotiable)
- Row-Level Security is mandatory
- RLS best practices
- When to consider an alternative
- The SDLC Runbook (five stages, with time budgets)
- Stage 0: Ideation (1 to 3 hours)
- Stage 1: System Design + Spec (2 to 6 hours)
- Stage 2: Backlog + Tickets (1 hour)
- Stage 3: MVP Scaffold (2 to 12 hours)
- Stage 4: Iteration Loop (daily, ongoing)
- Stage 5: V1 Hardening (1 to 3 days)
- A one-screen summary
- What’s next
This is Part 5 of The Principal Engineer’s Agentic Coding Bible. Parts 1 through 4 set the worldview, the toolchain, the security spine, and the org structure for your agentic engineering army. Part 5 is where the rubber meets the road. Production architecture. The patterns that take an MVP from “it boots on Vercel” to “it survives real users hitting it at scale.”
This is also the part where I’m going to be opinionated about specific platform picks. You can absolutely deviate. Just deviate with a reason, not because you saw a tweet.
The Vercel + GCP Split (the boring choice that wins)
Every successful production architecture I run for indie / small-team work in 2026 looks roughly the same:
| Layer | Platform | Why |
|---|---|---|
| Frontend | Vercel | Preview deploys on every PR, staging branch for QA, production with auto-scaling, edge network included, Astro/Next/SvelteKit all first-class |
| Backend API | GCP Cloud Run | Containerized, auto-scaling, IAM-integrated, pay-per-request, scales to zero when idle |
| Database | Supabase Postgres | Postgres with auth, storage, realtime, and RLS built in. Free tier carries you to product-market fit. |
| Secrets | GCP Secret Manager | Tight IAM integration, audit trail, rotation hooks |
| Logs | GCP Cloud Logging | Searchable, structured, alertable |
| Scheduled jobs | GCP Cloud Scheduler | Cron-as-a-service, IAM-controlled |
| Async tasks | GCP Pub/Sub or Cloud Tasks | Queue + durable worker pattern |
| Background workflows | Vercel Workflow SDK (GA April 2026) | Durable, resumable agent workflows. Lives next to your AI SDK code. |
The reason this split wins: the frontend and the backend have different operational shapes. Frontend lives or dies on edge-network latency and preview-deploy DX. Backend lives or dies on observability, scaling controls, and IAM. Vercel is the best in the world at the frontend shape. GCP is the best in the world at the backend shape (with AWS and Azure as defensible alternatives, depending on your existing footprint).
If you put the backend on Vercel too, you outgrow it the day you need real workflow control. If you put the frontend on GCP, you spend three weeks rebuilding what Vercel gives you free.
Domain and Routing Standard
This is the one that prevents six months of “where do I put this” arguments.
| Subdomain | Destination | Purpose |
|---|---|---|
app.yourdomain.com | Vercel | Frontend, customer-facing |
api.yourdomain.com | Cloud Run | Backend API |
admin.yourdomain.com | Vercel | Internal admin dashboard (gate it with auth, obviously) |
docs.yourdomain.com | Vercel | Public docs (Mintlify, Astro, or similar) |
status.yourdomain.com | Better Stack / similar | Status page, decoupled from your main hosting |
Pick this structure on day one. Migrating later costs you DNS changes, JWT scope rewrites, CORS rules, and a weekend of regret.
Mobile Development: Expo + React Native (the debate is over)
The “Expo vs. React Native CLI” debate is over. The React Native team itself recommends a framework-first approach. Default choice: Expo. Stop having the conversation.
OTA (over-the-air) update strategy
Mobile development has historically been a slog because every change required an App Store review cycle. OTA fixes that for the changes that don’t touch native code.
| Change type | OTA-able with EAS Update? |
|---|---|
| Bug fixes (JS only) | Yes |
| UI changes | Yes |
| Content updates | Yes |
| Feature flags | Yes |
| New native modules | No, requires new build |
| Expo SDK version change | No, requires new build |
| Permission changes (e.g. camera) | No, requires new build |
| App icon / splash | No, requires new build |
Use EAS Update for everything OTA-able. The standard tooling matured this year.
Note for anyone still reading older docs: Microsoft’s CodePush retired in March 2025. If a 2024 tutorial tells you to use it, ignore. EAS Update is the answer.
Database Layer: Supabase + Postgres (and the RLS rule that’s non-negotiable)
“January 2025: 170+ apps built with Lovable were found to have exposed databases (CVE-2025-48757) because developers didn’t enable RLS. 83 percent of exposed Supabase databases involve RLS misconfigurations.”
Read that again. 83 percent. This is the most common production security failure in 2026, by a wide margin. And it’s preventable with one toggle and a few lines of SQL.
Row-Level Security is mandatory
RLS is mandatory on all user-facing tables. No exceptions. Not “we’ll add it later.” Not “the API enforces it.” If the table can be queried by an authenticated user, RLS must be on.
RLS best practices
| Practice | Why |
|---|---|
| Enable RLS on all user-facing tables | The 83 percent stat. This is the bar. |
Define granular access policies using auth.uid() | Tenant isolation enforced at the database, not at the app layer |
| Add indexes on RLS columns | 100x query improvement on large tables, no joke |
Wrap auth function calls in SELECT for caching | Postgres caches subselects, raw function calls re-evaluate per row |
| Keep policies simple | Complex joins slow queries. Simple policies enforce better. |
If you’re starting a Supabase project this week, the very first migration after creating any user-facing table should be ALTER TABLE x ENABLE ROW LEVEL SECURITY; plus the auth.uid() policy that says who can see what. Make it a checklist item. Make it a pre-merge gate. Make it impossible to ship a user-facing table without it.
When to consider an alternative
| Scenario | Consider |
|---|---|
| MVP / V1 / most apps | Stay on Supabase |
| Reactive-heavy AI agent app | Convex (the @convex-dev/agent component is a real unlock for thread persistence + vector search) |
| Enterprise compliance forced | Managed Postgres on Cloud SQL or RDS |
| Analytical / OLAP workloads | Add DuckDB or ClickHouse alongside Postgres |
| Edge-first single-region misery | Stay with Supabase. Don’t chase edge databases until you measurably need them. |
The SDLC Runbook (five stages, with time budgets)
This is the runbook I use for every new product or major feature. Time budgets are aggressive on purpose: agentic engineering is fast when the operator gives it structure, and slow when the operator wings it.
Stage 0: Ideation (1 to 3 hours)
Outputs:
- Problem statement (one paragraph, no jargon)
- ICP (Ideal Customer Profile)
- MVP scope (10 bullets max, anything more is scope creep)
- Non-goals (hard list of what you’re explicitly NOT building)
- Success metric (one number; if you can’t define one, you don’t have a feature yet)
- 7-day ship plan (yes, seven days, not seven sprints)
If you can’t write this in 3 hours, the idea isn’t clear enough yet.
Stage 1: System Design + Spec (2 to 6 hours)
Outputs (all going into ARCH_NOTES.md and the specs/ directory):
- Data model (entities, relationships, the small set of objects that matter)
- API contract list (the routes, the request/response shapes)
- Auth model (roles, tenancy, what
auth.uid()looks like in your case) - Error handling strategy (what fails how, what the user sees, what gets logged)
- Threat model (lightweight: what data is sensitive, what an attacker would want, what the blast radius is)
- Feature specs (SDD artifacts per core flow, per the Pillar 1 discipline from Part 1)
This is the most-skipped stage. Don’t skip it. The spec is the agent’s source of truth, and an agent without a spec hallucinates structures that look right and break in production.
Stage 2: Backlog + Tickets (1 hour)
- Epics in Linear / Jira (one per major flow)
- Small, testable tickets (1 to 4 hours each; if longer, decompose)
- Each ticket links to the relevant spec (so the agent can pull context)
- Acceptance criteria on every ticket (testable, binary, no “feels good”)
Don’t open a single agent session before this stage is done. Agents without tickets thrash. Agents with tight tickets ship.
Stage 3: MVP Scaffold (2 to 12 hours)
What “done” looks like:
- Runnable build (the project boots, hot reload works, you see a screen)
- Auth wired (real users can sign up, log in, log out, recover)
- Database connected (you can read and write the smallest happy-path entity)
- First happy path working (one full user flow end to end, even if ugly)
The point of Stage 3 is to compress as much “boot the project” friction as possible into the same focused session. Once a project boots and persists data, the iteration loop gets fast.
Stage 4: Iteration Loop (daily, ongoing)
Per ticket:
Plan ticket
→ Implement (agent)
→ Test (agent)
→ Review (agent)
→ Deploy (Vercel preview)
→ Verify (manual smoke test)
→ MergeThe orchestration roles from Part 4 (Orchestrator, Architect, Scaffold, Coder, Reviewer, Tester) map onto this loop. Different agents wear different hats per phase. Repeat.
Stage 5: V1 Hardening (1 to 3 days)
What “ready for paying users” looks like:
- Rate limiting on all public endpoints
- Input validation everywhere (zod schemas at the boundary)
- Error boundaries on the frontend
- Logging and metrics (structured logs to Cloud Logging, metrics in Better Stack or Datadog)
- Database migration discipline (versioned, reviewed, reversible)
- Backup verification (when was the last restore actually tested?)
- Security headers (CSP, HSTS, X-Content-Type-Options, the standard set)
- CI enforcement (the gates from Part 3 are required, not advisory)
Don’t ship V1 without all of these. The MVP can be hacky. V1 cannot.
A one-screen summary
If you’re skimming:
| Concern | Default | Promotion trigger |
|---|---|---|
| Frontend | Vercel | Don’t promote, stay |
| Backend | Lovable / Replit | $10k MRR OR reliability issues |
| Backend, V1 → mature | GCP Cloud Run | Performance, compliance, cost optimization |
| Mobile | Expo | Don’t promote until production scale forces it |
| Mobile OTA | EAS Update | (CodePush is retired, don’t use) |
| DB | Supabase + RLS enabled day one | Convex if reactive AI app, managed Postgres if enterprise compliance forced |
| Process | 5-stage runbook with time budgets | Adjust budgets, don’t skip stages |
What’s next
Part 6 closes the series. The operating system you actually run day-to-day. Vibe coding failure case studies with the receipts (Enrichlead, Replit, litellm, Lovable). Compliance and governance baseline. The Notion workspace template. Reusable feature spec templates and launch checklists. Daily, weekly, and monthly loops you can actually maintain.
Subscribe to AI in Living Color below if you want the final part dropped into your inbox.
This is Part 5 of “The Principal Engineer’s Agentic Coding Bible,” v3.0, originally drafted March 2026, now publishing in pieces through 2026 in my actual voice. Built in public.