Web Apps Built to Last

Web applications in 2024–2025 have a narrower recommended architecture surface than at any point in the past decade. The maturation of Next.js App Router, the emergence of full-stack TypeScript patterns, and the convergence around a small set of managed infrastructure providers means fewer foundational decisions to agonize over — and more time to focus on the product logic that actually differentiates your application.

Frontend Framework and Stack Selection

The framework choice for a web application is the most consequential early architecture decision. It determines your hiring pool, your rendering strategy options, your deployment infrastructure, and your ability to adopt new platform capabilities. Getting this wrong produces a rewrite — which is a 3–6 month project that produces nothing customer-facing.

Frontend Framework Comparison for Web Apps

State of JS 2023 (published Q1 2024, ~23,000 respondents). LCP benchmarks on typical SaaS dashboard pages under median server load. Actual LCP depends on image optimization, CDN placement, and server response time.

Backend for Web Applications

Next.js API Routes / Route Handlers. Suitable for most web app APIs — co-located with the frontend, sharing the same deployment, TypeScript throughout. Limitations: no WebSocket support (requires a separate server), cold start latency on serverless deployments, not suitable for CPU-intensive work. Correct default choice until these limitations are actually encountered.

Separate Node.js / Fastify backend. Justified when the API is consumed by multiple clients (web + mobile + third-party integrations), WebSocket or SSE connections are required, or processing needs are CPU/memory-intensive. Fastify at ~77,000 req/sec handles significant load with minimal infrastructure cost.

Edge Runtime. Next.js Middleware and select API routes can run on the Edge Runtime (Cloudflare Workers-compatible), delivering responses from the nearest CDN node globally. Constraints: no Node.js APIs, limited CPU time per request, no persistent connections. Best for authentication checks, A/B testing splits, and geo-routing where latency is the primary concern.

DeepLearnHQ take: The most common backend architecture mistake in web app projects is choosing a separate microservices architecture for a product that a well-structured Next.js monorepo could serve perfectly well. We advise teams to start with co-located API routes, extract a separate service only when a specific capability (WebSockets, heavy computation, independent scaling) actually requires it, and never decompose prematurely for theoretical scaling reasons.

Deployment Options: Cost, Scale, and DX Comparison

The Vercel trap: Vercel is excellent for startups to ~$10K MRR. At scale, bandwidth egress and function invocation costs grow faster than AWS alternatives. Multiple high-profile migrations in 2023–2024 (widely discussed on Hacker News) moved mid-stage companies to Fly.io + Neon or Railway for 40–60% cost reductions.

SaaS Architecture Patterns and Multi-Tenancy

A production SaaS web application requires deliberate architecture across five layers: presentation (Next.js app on CDN), API (REST or tRPC with auth middleware and rate limiting), business logic (service layer with no database queries in HTTP handlers), data (Postgres primary + read replica + Redis), and background processing (BullMQ or Trigger.dev for email, reporting, and webhook delivery). Shortcuts at any layer produce technical debt that compounds with every order of magnitude of user growth.

Multi-Tenancy Implementation Options

Stage 1 (0–100 tenants, MVP). Row-level tenant isolation with tenant_id on every table. Row-level security (Postgres RLS) enforced at the database layer — not application layer — preventing cross-tenant data leakage even from application bugs. One database, one schema. Simplest to implement and operate.

Stage 2 (100–1,000 tenants). Introduce connection pooling (PgBouncer or Supabase pooler) to handle concurrent tenant connections. Add a read replica for reporting queries that would otherwise contend with transactional traffic. Begin monitoring per-tenant query performance — the first signs of a "noisy neighbor" tenant will appear here.

Stage 3 (1,000+ tenants or enterprise tier). Offer dedicated schema or dedicated database for enterprise customers requiring data isolation, data residency, or compliance certifications. Maintain shared infrastructure for SMB customers. Automate tenant provisioning via API — manual onboarding at more than 100 tenants per month is operationally unsustainable.

DeepLearnHQ take: The most consequential architectural decision in SaaS web apps is how multi-tenancy is implemented — and it is made in week one of development. We have helped companies re-implement multi-tenancy at Series B because it was done incorrectly at seed stage. The cost of that migration was 3–4 months of engineering time. Getting the isolation model right at inception costs nothing extra.

Core Web Vitals: Thresholds and Business Impact

Google Core Web Vitals thresholds as of 2024. INP replaced FID as a ranking signal in March 2024. All three metrics are Google search ranking factors — poor Core Web Vitals directly affect organic traffic for web applications with public pages.

Web App vs Native App, SaaS Metrics, and Staffing

The decision between a web application and a native mobile app is frequently made on instinct rather than on user behavior data. Web app versus native is not a religious choice — it is an audience, engagement pattern, and capability question that should be resolved by data before architecture decisions are made.

Web App vs Native App Decision Criteria

Choose a web app when: the primary access device is desktop or laptop, the use case is content consumption or workflow management, offline functionality is not required, push notifications are not central to the engagement model, and the team does not have iOS/Android expertise. Web apps are deployable without App Store approval cycles — a 1–7 day review delay that matters for every release.

Choose native when: access to device hardware is required (camera, GPS, accelerometer, Bluetooth, NFC), background processing is central to the product (fitness tracking, navigation, health monitoring), offline-first functionality is required, or push notifications are the primary re-engagement mechanism. The native experience quality gap matters most for consumer apps where usage frequency and session depth determine retention.

Choose a Progressive Web App (PWA) when: the primary audience is mobile but the budget or team does not support native development, push notifications are needed but App Store distribution overhead is not justified, and offline caching for a subset of content is sufficient. PWA capabilities have improved significantly — Workbox service workers, Web Push, and the Background Sync API cover the majority of native re-engagement mechanics.

DeepLearnHQ take: We routinely redirect clients away from native app projects toward well-executed PWAs or responsive web apps. For B2B SaaS, the App Store distribution model adds release friction without adding significant value for a primarily desktop-accessed tool. Build native when native capabilities are genuinely required — not because a native app "feels more serious."

SaaS Web App Business Metrics Context

Staffing Model for SaaS Web App Development

Seed stage (0–$1M ARR). 1–3 engineers total, full-stack generalists who can ship frontend and backend. Avoid over-specialization — the T3 Stack (Next.js + tRPC + Prisma + TypeScript) is specifically designed for a single engineer to work across the full stack effectively. Stack choices should optimize for team size.

Series A ($1M–$5M ARR). 5–12 engineers. Begin specialization: 1–2 frontend specialists, 1–2 backend specialists, 1 DevOps/infrastructure engineer. Add a QA engineer even if part-time — the cost of releasing regressions to paying B2B customers begins to exceed the cost of QA at this scale.

Series B ($5M–$20M ARR). 15–40 engineers. Introduce an engineering manager, a staff engineer for architecture decisions, a dedicated security engineer, and a data engineer. Begin a platform team if internal developer tooling has become a bottleneck to feature velocity.

Studio engagement model. Early-stage companies benefit from a fractional CTO (20% time, ~$5,000–$10,000/month for architecture and investor conversations) combined with a studio team of 3–5 engineers ($40,000–$80,000/month total). This delivers equivalent velocity to a $600,000/year full-time team at significantly lower fixed cost and hiring overhead.