FastEndpoints vs Minimal APIs vs Controllers in .NET — The Honest Comparison

A new project lands and you ask three .NET devs which routing flavour to use. You get three different evangelism pitches. None of them mention the trade-offs honestly, because they're emotionally invested. Let me try to be the boring one.

The same endpoint — create a user — three ways:

// Controllers (still here, still works)
[ApiController, Route("users")]
public class UsersController : ControllerBase
{
    [HttpPost] public Task<IActionResult> Create(CreateUser req, IUserService s) =>
        s.Create(req).ContinueWith<IActionResult>(t => Created($"users/{t.Result}", null));
}

// Minimal APIs
app.MapPost("/users", async (CreateUser req, IUserService s) =>
    Results.Created($"/users/{await s.Create(req)}", null));

// FastEndpoints
public class CreateUserEndpoint : Endpoint<CreateUser>
{
    public override void Configure() { Post("/users"); }
    public override async Task HandleAsync(CreateUser req, CancellationToken ct) =>
        await SendCreatedAtAsync(...);
}

Honest scorecard:

Concern	Controllers	Minimal	FastEndpoints
Startup	Slowest	Fastest	Fast
Throughput	Baseline	+10-15%	+10-15%
OpenAPI quality	Best	Improving	Excellent
Validation ergonomics	Good	Was poor, fixed in .NET 10	Excellent
Team onboarding	Trivial	Easy	Steeper
Third-party risk	None	None	One library

What people don't admit:

Controllers are fine. They're not slow in any way you'll measure. The "they're old" energy is a vibe, not a benchmark. For a 40-person team that rotates engineers across services, Controllers are the lowest-friction choice.

Minimal APIs are wonderful until they aren't. The day Program.cs hits 800 lines is the day you'll write the same IEndpoint interface I wrote, and the same registration extension method everyone else writes. It's not a problem, but it's not "free".

FastEndpoints is the best-organised of the three. The cost is that it's a third-party library you're betting your service architecture on. If the maintainer moves on, you own it. For internal projects this is fine. For a 10-year-life product, think harder.

What I'd actually pick:

• Public SaaS API, ten or more endpoints: FastEndpoints if I trust the team to absorb the library risk, otherwise Minimal with the endpoint-per-feature pattern.
• Internal tool, under 20 endpoints: Minimal APIs. Don't overthink it.
• Large team, mixed seniority, long-lived service: Controllers. The boring answer is the right one.

The thing nobody benchmarks: how long it takes a new engineer to ship their first endpoint. Controllers wins this one, every time. That's worth a few microseconds.