server actions or route handlers for a 40-endpoint internal dashboard, two devs Routing

Split it on the question "will a client I do not control ever need this?"

• Forms and mutations that only the dashboard performs: server actions. Colocation is worth real money at 40 operations and two people.
• Reads that a second client will want, and the CSV exports: route handlers. Exports especially, because you want a URL you can hit with curl and a proper Content-Disposition.

That is maybe 8 route handlers and 32 actions. If mobile happens you write an /api/v1 that calls the same service functions, which is the actual lesson: put the logic in plain functions and let both transports be thin. Then the decision stops being expensive.

One practical note from doing exactly this: bulk actions are where server actions get awkward. A single action that processes 4,000 rows will hit your platform's function timeout, and now you need a job queue and a status endpoint, and the status endpoint wants to be a route handler anyway. Plan for that early rather than discovering it in week five.

Six weeks, internal, 60 staff who are all on the same corporate laptop image: use whichever you type faster. This decision is worth about half a day of your six weeks and you have already spent more than that thinking about it.

Server actions for all of it and stop thinking about the mobile app that does not exist. Two constraints you should know going in though: an action is always a POST, so it is not cacheable and you cannot link to it, and the arguments have to be serialisable, which bites the first time someone tries to pass a Date inside a class instance.

We run about 70 actions in one product. The thing that keeps it sane is one zod schema per action, validated on the server, and never trusting the client-side parse.

The decision you are actually making is where authorisation lives, and neither option gives it to you.

With route handlers you will write the same six lines of session check at the top of 40 files and forget one. With server actions you will do the same thing, except the forgotten one is directly callable by anyone who can read your JS bundle, because every action is a public endpoint whether you meant it or not.

Write one wrapper - authed(schema, handler) - before you write endpoint number three, and make it impossible to define an action without going through it.

Route handlers are on the way out, the whole framework is moving to actions. Would not start anything new on them.