I don't fit the usual boxes. That's fine. The operating mode here is ship fast with parts you can swap.
I'm not optimizing for status or niches; I'm optimizing for clarity, ergonomics, and hot‑replaceability.
Labels don't ship product. Decisions do.
Red Queen's Race
Everything changes--including your own reasoning. Plan for it.
Assume you'll be wrong soon. Prove yourself wrong on purpose and on schedule.
Design for swap‑outs. Every module is a part you can replace without drama.
Prefer learning loops over sunk‑cost loyalty. When the world shifts, you shift.
Instagram's Engineering Philosophy (2011)
Keep it very simple
Don't reinvent the wheel
Go with proven and solid technologies when you can
Use 1 and 2 by default. Use 3 only when "proven" also means ergonomic, portable, and easy to replace. New tools exist for reasons--learn the reason before you commit.
Use server helpers (getSession, listOrganizations) on the server only
Don't call client methods from the server
Prefer built‑in plugins (Stripe, Organization)
Use referenceId for multi‑tenant boundaries
Elysia & Eden Treaty
Eden Treaty for typed client ↔ server calls
Narrow error types and check before accessing data
Keep handlers tiny and composable
Database (Drizzle)
Schema is the source of truth; infer types from it
Don't re‑add fields already provided by plugins
Use relations & indexes; limit 1 on single‑row fetches
UI Components
Use shadcn/ui (already installed)
Use Sonner for toasts (not inline status messages)
Server components by default; client components only when necessary
Fetch Data Inside Component, instead of prop drilling
They'll be optimized with Partial Prerendering
Anti‑Patterns
Client‑side fetching in a server‑rendered app
Duplicating functionality provided by Better Auth/Stripe/etc.
Ignoring TS errors (no @ts-ignore to make it pass)
Building abstractions before you need them
Fetching without a caching strategy
Code Review Checklist
No any types
No client fetches for server‑available data
No duplicate re‑implementations of platform features
All TypeScript errors resolved
Server hits DB directly when applicable
Proper error handling with type‑narrowing
Toasts via Sonner (not inline)
Parallelized data fetching where possible
Server components by default
The Stack (hot‑replaceable by default)
Moonrepo
Minimal setup; great for multilingual Monorepos
Multilingual ⇒ interoperable/hot‑replaceable
Bun
Fast, light, understands TS natively
No config thrash; tsconfig purely for editor tooling
Elysia (+ Hono where Web‑Standard routing/edge is ideal)
Simple, ergonomic, fast
Elysia feels familiar to Express; Hono hugs web standards
Elysia's Eden Treaty and Hono's RPC are type‑safe clients-server contracts. Ergonomic.
Better Auth
Minimal setup; great plugin surface (Stripe, Organization)
Server‑first helpers; typed end‑to‑end
You own the data. Hot-replaceable.
Drizzle ORM + Postgres
Schema‑first, typed queries, simple migrations
Postgres is boring‑great
Again, you own the data. Hot-replaceable.
Biome
Lint + format in one; fast; low config
AWS via FlightControl
Vercel‑like ergonomics, AWS under the hood
Hot‑replaceable: mostly ergonomic wrappers over AWS APIs
Pair with Nixpacks for painless images
HTTP‑only cookie auth + typed REST (or Eden Treaty RPC)
Keep tokens off localStorage; keep surface small & typed
shadcn/ui + Sonner
Copy‑in components (hot‑replaceable), great DX for toasts
Vitest/Jest/Bun
Similar APIs; pick per project needs
Automation
GitHub Actions for CI
Lefthook (or plain git hooks) for visible, simple commit hooks
Skeptical but pragmatic
Vercel & Next.js
Don't love the occasional rebranding/overrides, but: ergonomic.
Use server components, cache directives, and route handlers well.
SWR / TanStack Query
Use only when you must fetch on the client. Server‑first otherwise.
Prisma
Fine; but Drizzle keeps types closer to SQL and feels lighter.
If mixing: isolate behind a repository layer for hot‑swap potential.
What I usually avoid unless necessary
Docker (hand‑rolled everywhere)
Docker is imperative in the inside.
Use Nixpacks or equivalents to avoid yak‑shaving.
And try out that new hot thing in town
Let's say after 2 months, there's a new hot library in town. Should I stay uncool? I'd say: take a leap of faith, but with a parachute Try unreliable but high‑leverage ideas--wrapped in interoperable, hot‑replaceable, type‑safe modules.
Summary
Be clear.
Be direct.
Be type‑safe.
Be Server‑first.
Be library power-user.
Be a shipper, not an architect.
Comments0
No comments yet. Be the first to share your thoughts.