Somewhere in every app project, this question appears: "Do we need a backend for this?" It sounds technical, but it's really a budget and timeline question, the answer can swing your MVP cost by thousands of euros. Here's the plain-language version we walk founders through, including the cases where the honest answer is "not yet".
First: what is a backend, in human terms?
The app on the phone is the part users see. The backend is everything behind it: where the data lives, where the rules run ("has this user paid?", "who can see this?"), where accounts are managed. Every serious app has one somewhere, the real question is whether it's a ready-made service you configure, or a custom system built for your product.
Option 1: Backend-as-a-service (Firebase, Supabase & friends)
Services like Firebase or Supabase give you a pre-built backend: user accounts, a database, file storage, notifications, configured, not coded. For a lot of MVPs, this is genuinely the right call, and any agency that pushes a custom backend on every project is optimizing for their invoice, not your runway.
- Your app mostly stores and displays data: notes, habits, workouts, saved items, simple profiles
- The rules are simple: users see their own data, maybe share some of it
- You need to validate the idea before investing in infrastructure
- Budget saved: typically €3,000–8,000 versus a custom backend, and 1–2 weeks of timeline
Option 2: A custom backend
A custom backend (we build ours in Nest.js, more on why in a moment) means the server-side logic is written specifically for your product. It costs more upfront and exists for one reason: some products simply cannot be expressed as configuration.
- Complex business logic: matching drivers to riders, calculating dynamic prices, multi-step approval flows
- Money beyond a simple checkout: subscriptions, payouts to users, commissions, invoicing
- Integrations with other systems: warehouses, CRMs, payment providers, government APIs
- Multiple user roles with genuinely different permissions and workflows
- Data you must fully own and control, common in health, finance, and B2B contracts
- A web app planned next to the mobile app, sharing the same data and logic
The signs you've outgrown Firebase
Plenty of successful apps launch on Firebase and migrate later, that's not failure, that's the plan working. The signs it's time: your 'security rules' file has become an unreadable novel; you're writing more and more cloud functions to work around missing logic; queries that were instant are getting slow or expensive; or a business partner asks where exactly the data lives and you need a better answer. Migration is a normal, plannable project, not a rewrite of your app.
“Choosing Firebase for your MVP isn't cutting corners. Paying for a custom backend before you have users, that's cutting runway.”
Why we build custom backends in Nest.js
When a project does need a custom backend, we build it in Nest.js, a mature, structured framework in TypeScript, the same language as our web (Next.js) and mobile (React Native) apps. One language across the whole product means the same team works on all of it, data definitions are shared instead of duplicated, and a whole class of "the app expected X, the server sent Y" bugs disappears. For you it translates to fewer people needed, faster changes, and one team accountable for the whole system.
The honest decision path
- Describe your app's core in one sentence. If it's 'users save and view X', start with Firebase/Supabase.
- If the sentence contains 'matches', 'calculates', 'pays out', 'approves', or 'integrates with', budget for a custom backend from day one.
- If you're unsure, start managed and plan the migration as a milestone, not an emergency.
- Never let this decision be made by whoever profits from the answer. Ask them to justify it in plain language, like this post just did.
Describing your app in one sentence and still not sure which side you're on? Send us that sentence. We'll tell you which setup fits, what it costs, and, if the answer is 'Firebase is fine', we'll say exactly that.
