Choosing a technology stack is one of the most consequential early decisions in a software project. Get it right, and it fades into the background — the team moves quickly, the system is easy to reason about, and adding new capabilities feels natural. Get it wrong, and the stack becomes a constant source of friction, slowing everything down and making every change harder than it should be.
At MildFist, we have settled on a set of defaults that we reach for on most projects. They are not the only valid choices, but they are choices we understand deeply and can use effectively.
Frontend: Next.js and React
Next.js is our frontend framework of choice for web projects. It handles routing, server-side rendering, static generation, and API routes in a single, coherent package. The developer experience is excellent, the performance defaults are sensible, and the ecosystem is large and well-maintained.
We use the App Router, which brings React Server Components into the picture. For most content-heavy or data-driven pages, server components eliminate unnecessary client-side JavaScript and improve initial load performance meaningfully.
Language: TypeScript
TypeScript is non-negotiable for us. The safety it provides — particularly in larger codebases and over longer timelines — justifies the overhead many times over. We have found that TypeScript catches a significant proportion of bugs that would otherwise only surface at runtime, often in production.
Styling: Tailwind CSS
Tailwind's utility-first approach aligns well with how we think about component-level styling. It eliminates the naming problem, keeps styles close to the markup they affect, and makes it easy to enforce visual consistency through a shared configuration. We use the latest version, which introduces a cleaner configuration model and better performance.
Infrastructure and Deployment
For most projects, we deploy on Vercel. The integration with Next.js is seamless, the deployment pipeline is fast, and the global edge network provides good performance without significant configuration. For projects with more specific infrastructure requirements — custom backend services, specific data residency needs, or unusual scaling requirements — we evaluate alternatives including AWS and Google Cloud.
Observability
Logging, error tracking, and performance monitoring are not optional. We instrument every production application with error tracking from day one, and we add structured logging and performance metrics early in the project lifecycle. Catching and understanding problems quickly is far less expensive than discovering them from user complaints.
Staying Current
We review our stack decisions periodically. The tools available today are significantly better than they were three years ago, and the tools available in three years will be significantly better than what we have now. Staying current is part of our commitment to doing excellent work.