Every time a new client asks me to build an app, the backend choice is the longest single decision in the brief. App-store apps live for years; the backend that powers them has to be there every day, every release, every iOS major update. The question is never what is fast to write. It’s what is cheap to operate for the next five years.
I keep landing on Quarkus.
What Quarkus actually buys you
Quarkus is the Red Hat-led Java framework that compiles to a native binary via GraalVM. The boot time is 30 milliseconds, the memory footprint is single-digit megabytes, the runtime is the JVM you already trust, and the developer experience is dev-mode hot-reload that puts most Node setups to shame.
For SMB-scale apps it is the sweet spot: you get fast iteration in development, tiny container images in production, and the entire Jakarta EE / SmallRye ecosystem of integration points the moment you need them.
What it does not buy you
It is not free. Quarkus has a learning curve if you’ve never used CDI before. The native-image compilation step is slow on CI. The GraalVM substrate has occasional sharp edges around reflection. None of these are deal-breakers, but they are real.
When I would pick something else
If the client’s team is two TypeScript developers and they will be the ones running the backend after I leave, I will write the backend in TypeScript and let them own it. Tooling continuity matters more than benchmark numbers for a small team.
If the workload is mostly event-driven, sometimes I reach for Go: single binary, no JVM, easier to operate by people who already speak Go.
But for the default app + backend project? Quarkus.