Breaking down my current tech stack

The core takeaway is that a modern TypeScript web stack is no longer a fixed “T3 stack” recipe—it’s a modular set of choices optimized for where static vs dynamic rendering happens, how much logic runs on the platform, and how aggressively teams want to avoid dashboard-driven configuration. After years built on the T3 stack, the current setup shifts away from SQL + tRPC-centric data access toward a Convex-first approach, while also rethinking the surrounding layers (auth, payments, analytics, security, and hosting) to reduce operational friction and keep code as the source of truth.

A major pivot is the database/API layer. Instead of PlanetScale + Prisma/Drizzle, then tRPC endpoints, plus separate live-update tooling and React Query, the stack now routes most data and API behavior through Convex. That means using Convex’s built-in useQuery/useMutation patterns and leaning on Convex’s optimistic update path for a smoother client experience. When something falls outside Convex’s model, tRPC still appears as a fallback, but it’s increasingly rare.

The “O layer” (auth) is handled differently depending on whether the goal is speed or enterprise readiness. For most projects, Clerk is the default because it bundles the practical pieces—sign-in, subscription-related flows, and user-facing UI components—so teams can get back to building. Work OS is positioned for enterprise sales where SAML/Octa-style integrations matter and where an admin portal becomes a requirement. A third option, Better Auth, is treated as a promising open-source-oriented path that can attach to an existing database, but without Convex-like hosting it shifts integration work back onto the developer.

Hosting and rendering choices also drive the stack’s shape. React remains the client foundation largely because the ecosystem—libraries, bundlers, tooling, and AI coding agents—still aligns around it. For the framework layer, the decision is framed less as “which init command” and more as “which router and rendering strategy.” Next.js is recommended when static pages and SEO matter (including patterns like a static marketing homepage plus a dynamic app), while Vite is favored for simpler apps where a static landing page isn’t critical. TanStack Start is watched as an emerging option, and React Router remains the practical routing layer in the Vite world.

On infrastructure, the stack stays on Vercel for preview environments and “fluid compute,” which the creator credits with cutting costs dramatically for long-running, low-compute workloads like AI inference. Cloudflare is acknowledged as strong for certain compute-wait patterns, but the integration friction—especially around Node compatibility and deployment complexity—pushes the choice back toward Vercel for full-stack apps.

Security and observability round out the picture. Bot protection is treated as distinct from DDoS protection, with the stack using Bot ID on Vercel and Arcjet as another programmable security layer option (rate limiting, bot detection, email validation, and token buckets). Analytics is split by purpose: PostHog for product analytics (feature flags, session replay) and Plausible for web analytics when sign-in isn’t available. Payments are anchored on Stripe, but the implementation philosophy is to keep payment state out of the application DB—using KV storage for subscription status and syncing via webhooks—while also evaluating newer abstractions like Autumn and Polar to reduce webhook and state-management pain.

Overall, the stack’s evolution is less about chasing new tools and more about enforcing modularity: swap components as needs change, keep behaviors in code, and minimize reliance on external dashboards that can drift from the repo. The result is a setup that’s “weird” compared with the original T3 approach, but designed to work smoothly with modern development workflows and AI-assisted coding.