Back to Insights
DECEMBER 15, 2025•5 MIN READ•ARCHITECTURE / STACK

How I Setup a Project in 2025

As the year wraps up, I thought it would be interesting to capture how I am currently spinning up new projects. This will almost definitely change again in a year or two, but right now these are the tools and patterns I keep reaching for.
I work mostly with .NET and TypeScript, with a lot of Next.js for web projects, so this is biased towards that world.

.NET: Aspire and FastEndpoints

For new .NET work I am now using .NET 10 and have moved most new projects onto Aspire.
Aspire gives me a nice opinionated way to structure distributed apps and services, and the built in dashboarding and wiring between services makes spinning up new solutions feel far less painful than manually stitching everything together.

APIs with FastEndpoints

For APIs I have fallen in love with FastEndpoints. I find myself choosing it over:
  • Minimal APIs
  • Older frameworks and templates I am used to, like SSW VSA
  • Clean Architecture style templates such as the SSW Clean Architecture Template
FastEndpoints gives me:
  • A clear way to model endpoints without a lot of ceremony
  • Good separation of concerns without needing a huge amount of boilerplate
  • A nice balance between structure and flexibility compared to raw minimal APIs
A few useful links if you want to explore these options:
At the moment, a typical new .NET backend for me looks like:
  • An Aspire solution to model the overall app and services
  • A FastEndpoints based API project for the main HTTP surface

TypeScript: Turborepo as the Base

For TypeScript based work, I have standardised on Turborepo.
When I need a monorepo or know I will have multiple apps and packages, Turborepo gives me:
  • A predictable way to share packages and utilities
  • Caching and task pipelines that make development and CI feel much faster
  • A structure that scales from one app to several without a big migration later
Most greenfield TypeScript projects now start life as a Turborepo, even if I am only spinning up a single app to begin with.
A useful link if you want to dig into Turborepo:

Web: Next.js plus separate APIs

I still use Next.js for almost all website frontends. It is familiar, fast, and has great support for the kind of sites I build.
One change in 2025 is how I think about APIs for these apps. I am moving away from putting everything into the built in app/api or pages/api routes in Next.js. Instead, I prefer to:
  • Use libraries like Hono or Elysia to define APIs
  • Integrate them with Next.js API routes or deploy them as separate services when that makes more sense
This gives me:
  • A cleaner separation between the UI and the API
  • Frameworks that are focused on HTTP handling, routing, and middleware
  • Flexibility to move the API to a separate deployment later without rewriting everything
A couple of useful links for these API frameworks:

Mobile: Expo and React Native

For mobile apps I still reach for React Native, but these days I default to Expo for almost everything.
Expo gives me:
  • A batteries included toolchain for building, testing, and deploying React Native apps
  • Managed workflows that handle a lot of native build complexity for me
  • A fast feedback loop when I am iterating on UI or behaviour
If I know from day one that an app will need heavy custom native work I will still consider a bare React Native setup, but for most projects in 2025 Expo gets me to something shippable much faster.

Hosting and Infrastructure: Vercel and Cloudflare

I am still hosting my sites on Vercel, with DNS handled through Cloudflare.
This setup works well for me because:
  • Vercel gives me a very smooth developer experience for Next.js projects
  • Cloudflare handles DNS, some free metrics, and email routing
  • Managing domains and records in Cloudflare feels easier and more centralised than relying only on registrar tooling
Overall this combination lets me spin up new projects quickly, with sensible defaults for performance and reliability, without needing to manage a huge amount of infrastructure myself.

Why bother writing this down?

A big reason for documenting this is that my stack has shifted a few times over the past few years. Writing down what I reach for at the end of 2025 gives me a snapshot I can look back on when I inevitably change my mind again.
It also might be useful for anyone with a similar background in .NET and TypeScript who is looking for a practical, opinionated setup rather than yet another giant comparison matrix of tools.
If you would like me to go deeper into any part of this stack, such as concrete templates, commands, or example folder structures, let me know in the comments and I can follow up with a more detailed post.

COMMENTS