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 morning, 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.