7Sigma

Posted on Aug 28

Full-Stack Development: What Actually Matters in Production

#webdev #typescript #techdebt #fullstack

Full-Stack That Survives Production: Boring Tech, Clear Boundaries, Measured Changes

Most “best practices” posts chase shiny tools. In production, boring tech solves real problems and keeps systems alive. After two decades of shipping software that still runs, here is what actually matters.

Pick Boring Tech First

Boring is not lazy. It is predictable. It has docs, examples, battle scars, and a talent pool.

Pattern I keep seeing:

Teams pick an exotic stack to “move fast”.
Six months vanish to edge case triage.
A competitor on Fastify, React, and Postgres ships features weekly.

When in doubt, choose:

React and TypeScript for UI.
Node with Fastify for APIs.
PostgreSQL for data.

Use the weird tool only when you hit a measured limit, not a theoretical one.

A Pragmatic Stack

Layer	Tech	Why
Frontend	React, TypeScript, Tailwind, Vite	Fast builds, types, composability.
API	Node, TypeScript, Fastify or Express, tRPC or GraphQL when needed	Pick per project, keep the surface small.
Services	Rust with TS bindings when performance or safety requires it	Hot paths without losing integration ergonomics.
Database	PostgreSQL with Prisma	One engine that handles relational, JSON, search, and light graphs.
Auth	JWT with refresh, thin custom layer for complex cases	Less magic, clearer flows.
Infra	Docker, Cloud Run or similar	Simple deploys, predictable cost.
CI/CD	GitHub Actions, agents in the loop for tests and scaffolding	Repeatability and fast feedback.
Observability	Logs, metrics, tracing, alerts tied to impact	See issues before customers do.

Monolith First, Modular Always

Most painful microservices journeys start too early. Twelve services mean twelve deploys, twelve dashboards, twelve failure modes.

Do this instead:

Build a modular monolith.
Measure real bottlenecks.
Extract a service only when a module has different scaling needs, clear ownership, and well defined contracts.

Postgres Everywhere, Until It Isn’t

Start with PostgreSQL because it covers more ground than people expect.

Relational, JSON, full text, time series, simple graphs.
Extensions and CTEs handle many “we need a new database” urges.
Add search engines, caches, or warehouses only when metrics justify it.

Design for synchronization early. You will integrate with something external. Emit events, add webhooks, and prefer managed CDC when possible. Your future integrations will be easier and safer.

Cache with intent. Cache expensive results, not everything. Measure before optimizing.

Security That Actually Breaks In Prod

Validate input and output. Use JSON Schema or Zod at the edges.
Use parameterized queries and safe builders.
Keep AuthN and AuthZ simple and explicit. A thin, consistent layer beats a pile of plugins.
Centralize secrets, rotate and audit. If a secret touched git, treat it as compromised.
Patch critical CVEs fast, pin versions for stability.

Log and audit as a first class concern. Incidents are easier when you can answer “who did what, when, and to which record”.

Performance, The 80–20

What usually fixes real latency:

Query plans and indexes.
Targeted caching.
CDN for static assets.
Lazy load what is not visible.

What rarely matters early: framework swaps, micro JavaScript tricks, exotic bundlers. Measure first, then optimize where users feel it.

Monitoring That Maps To Business

Track uptime, errors, latency, and user journeys. Alert on customer impact, not just CPU. A spike in checkout failures is urgent. A CPU blip during batch work is not.

Code Reviews That Prevent Late Pain

Look for correct business logic, edge cases, security, and data access patterns. Comments and naming polish are nice, but correctness and clarity ship value.

Documentation People Actually Read

Write decision records, deployment steps, incident runbooks, and API contracts. Keep them short and current. Skip line by line commentary. Module level notes help both humans and AI agents generate safe changes.

Technical Debt Is Real Debt

Shortcuts cost interest. Skipping tests makes refactors slow. Skipping error handling makes outages long. Skipping docs makes onboarding hard. Take debt on purpose, pay it down on a schedule.

You Are Not Google

Do not solve scale you do not have. Kubernetes can wait. Custom frameworks can wait. Solve the problems your users feel today, then scale the parts that earn it.

Bottom Line

Choose boring tech that works.
Keep the monolith modular, extract with proof.
Start with Postgres, add systems when metrics demand it.
Validate, observe, and automate where it counts.
Optimize for developer velocity and customer outcomes.

Originally published at 7Sigma Blog

Don't scale your team, scale your thinking.

DEV Community