Compare
Stack decisions, from systems we run.
We only compare tools we have shipped with. Each page answers the question first, then shows where each option won in our own work.
Pick by what the backend spends its day doing.
Choose FastAPI when the backend is mainly an API for web and mobile clients, an AI service, or something realtime. Choose Django when the product is records, roles, and workflows that people manage through an admin. We run both in production: four FastAPI systems and SigmaCPM on Django REST Framework.
For a new API, FastAPI. For a Flask app that works, keep Flask.
Choose FastAPI for a new Python API, especially one that streams, calls language models, or serves web and mobile clients. Keep Flask when you already have a working Flask app, or when the job is a small server-rendered site. We run four FastAPI systems in production and have not shipped Flask, so read our view with that in mind.
Pick the language the hard part of your backend is written in.
Choose FastAPI when the backend does AI, data, or computer vision work, because that work lives in Python. Choose Node.js when your team writes TypeScript end to end and the backend is mostly product logic, queues, and integrations. We run both: FastAPI in NoteTube and Pullsy, and a TypeScript backend with BullMQ in Kraftr.
Batteries included, or one language everywhere.
Choose Django when the product is records, roles, and back-office work, and you want an admin and permissions on day one. Choose Node.js when your team writes TypeScript across the stack and wants the backend close to a React or Next.js frontend. We run SigmaCPM on Django REST Framework and Kraftr on a TypeScript backend.
Both build good apps. Pick the one that fits the rest of your stack.
Choose React Native when you also have a React or Next.js web app, because one TypeScript team can then build both. Choose Flutter when the app is the whole product, you want pixel-identical UI on every platform, and your team is happy to learn Dart. We ship React Native with Expo in GymFast, NoteTube, and Kraftr. We have not shipped Flutter.
Start on Expo. Leave only when you can name the reason.
Choose Expo for a new React Native app. It handles builds, signing, native configuration, and over-the-air updates, and you can still write custom native code. Choose the React Native Community CLI when you are adding React Native to an existing native app or your team wants to own every native file by hand. Our three React Native apps all run on Expo.
Most apps should be cross-platform. Some really should not.
Choose cross-platform, such as React Native with Expo, when you need iOS and Android from one team and the app is screens, data, and payments. Choose native Swift or Kotlin when the app is built around a platform feature, heavy on-device work, or ships on one platform only. We run both: Pullsy's iOS app in SwiftUI and three React Native apps.
Relational data, or documents and the Google toolbox.
Choose Supabase when your data is relational, with users, roles, and records that join, and you want plain Postgres you could move anywhere. Choose Firebase when the data is document-shaped, you want Google's mobile tooling such as push and crash reporting, or you are already on Google Cloud. We run GymFast on Supabase and The Sharp Interiors on Firebase.
Not either or. The question is whether React needs a server.
Next.js is a framework built on React, so this is really a choice between React with a server and React as a single-page app. Choose Next.js when pages must be found on Google or in AI answers. A plain React app built with Vite is enough for a tool that lives behind a login. All nine systems on our work page use Next.js.
Own the CMS, or rent a very good one.
Choose Payload when you want the CMS inside your Next.js app, your content in your own Postgres or MongoDB, and room to store app data such as leads beside it. Choose Sanity when you want a hosted content platform with real-time collaborative editing and no database to run. We run Payload in production for Siona Jewels. We have not shipped Sanity.
Retrieval changes what the model knows. Tuning changes how it behaves.
Choose RAG, retrieval-augmented generation, when the model must answer from your documents, cite them, and stay current as they change. Choose fine-tuning when you need a consistent format, tone, or narrow skill that prompting cannot reliably produce. Most business AI needs RAG first. We run RAG in NoteTube and SigmaCPM; we have not fine-tuned a language model in production.
A dedicated vector engine, or vectors next to the rest of your data.
Choose pgvector when you already run Postgres and want vectors beside your records, joined and filtered with SQL in one database. Choose Qdrant when vector search is a core workload, with large collections, heavy filtering, hybrid search, or memory pressure that a dedicated engine handles better. We use Qdrant in NoteTube and pgvector in Acasa Sentinel.
Most gyms should buy. Some should build. Here is how to tell.
Choose off-the-shelf gym software for a single gym or a small chain: it works this week and costs far less than a build. Choose custom gym software when you run a chain with its own rules, need deep integrations with your systems, or the software is itself your product. We make both: GymFast is our off-the-shelf product, and we build custom systems on the same base.
Next step
Tell us what you need built.
Thirty minutes on how the work happens today. You leave with a written plan: scope, timeline, and a number.