Can You Build a Production-Ready MVP Without a Custom Backend?
What Supabase, Firebase and Appwrite handle for you, what they don’t, and how to avoid the security mistakes that catch early-stage startups.
The short answer is yes. You can build and launch a real product on a Backend as a Service platform without running your own backend server. Platforms like Supabase, Firebase and Appwrite now provide authentication, databases, file storage, realtime features and serverless functions, so a small team can ship in weeks what once took months.
But there is a distinction that trips up founders and plenty of developers. Not building your own backend infrastructure is very different from not doing backend engineering. The platform manages the servers. You are still responsible for application security, authorisation, business logic, testing, data design and a clear understanding of the limits of whatever you chose.
What building without a custom backend actually means
When developers say they built an app without a custom backend, they usually mean a managed platform replaced the backend application they would otherwise have written and hosted. Take a SaaS product built with Next.js. It needs registration and login, a database, file uploads, permissions, subscription management and some background work.
The traditional route would be a Node.js or Django backend, a configured database, hand written authentication, API endpoints and a server to deploy it all on. With BaaS, much of that is handled for you. Supabase, for example, supplies PostgreSQL, authentication, storage, realtime features and Edge Functions, and your Next.js app talks to them through an SDK.
Keep one idea in mind for the rest of this piece. BaaS does not mean backend free development. It means using an existing backend instead of building every part of one yourself.
What you can safely hand over
Authentication is the easiest thing to delegate. Writing password hashing, session handling, password resets and email verification yourself is slow and risky, and all three platforms offer it ready made, often with social login and multifactor options. But authentication only tells you who the user is. What that user may do is a separate problem, and I’ll come back to it.
Databases are the second. A managed platform gives you the infrastructure and tools to create tables, store records and run queries. Supabase gives you PostgreSQL, which suits data with rich relationships between customers, organisations and orders. Firebase gives you Cloud Firestore, a document database that fits data shaped like documents or needing realtime sync. Let your data structure choose for you.
File storage covers profile pictures, invoices, documents and video, and you still have to configure access permissions, upload restrictions and size limits. Realtime features suit messaging, live dashboards and booking systems. Serverless functions let you run custom code, such as processing a payment webhook, sending an email after signup or calling an external API, without maintaining an always running server. They have execution limits and runtime constraints, so they don’t suit every workload, but they give you real custom logic without a traditional server.
What still needs trusted server side logic
This is where BaaS is most often misunderstood. Some developers assume that because authentication, data and storage are available, the whole application can run straight from the browser. That assumption creates serious security problems.
Think about a subscription product. A user buys a premium plan, and your system has to receive the payment confirmation, verify it, activate the subscription and update the account. None of that can be trusted to frontend code, because a user can manipulate requests, change client side state or try to bypass restrictions. Those steps must run in a trusted environment, whether that is a serverless function, an API route or a dedicated service.
The same applies to payment webhooks, privileged calls to external APIs and any heavy background processing. Showing a list of products can happen in the browser. Calculating a discount, verifying a payment or granting premium access cannot. You don’t necessarily need a full Django or Node.js application for these jobs, but you do need a secure place to run them.
Authentication is not authorisation
If I could put one warning in front of every founder using BaaS, it would be this one. Having a login system does not make your application secure.
Imagine a project management tool where users create organisations, invite teammates and manage projects. Now suppose one user discovers another organisation’s ID and tries to fetch its projects. If your database permissions are misconfigured, they may succeed. Choosing Supabase, Firebase or Appwrite does not prevent that. You have to write the access rules, and they must be enforced by the data layer, not merely hidden behind buttons in the interface.
Get Peterkimbeghi’s stories in your inbox
Join Medium for free to get updates from this writer.
In Supabase, the tool for this is Row Level Security, which lets you write policies that decide which rows a user can read or change. Firebase does the same job with Security Rules. Writing a policy is not enough, though. You have to test it. Check that users can reach their own records and cannot reach another organisation’s, that an ordinary member cannot perform administrator actions and that unauthenticated requests are rejected. A working login tells you nothing about any of this.
Architecture and testing still matter
Using BaaS doesn’t remove the need for architecture. It is tempting to scatter database queries, payment logic and permission checks across your components, and that works until the product grows. Keep clear boundaries instead. The frontend handles presentation, the platform handles data and identity, and separate modules hold your business rules and your integrations with payment, email and verification providers. None of these needs its own server. They can all live in one application, as long as you keep them apart.
Testing matters just as much. A platform can give you reliable infrastructure, but it cannot guarantee your code is correct. For a marketplace, that means confirming buyers see only their own orders, sellers manage only their own products, payments are verified before orders are marked paid and duplicate payment notifications are handled safely. Test your database policies separately from the frontend, because an interface can hide an admin button while a determined user sends the underlying request directly. Supabase and similar platforms offer local tooling for testing changes before you deploy, and it is worth using.
Can it scale, and when do you need a custom backend?
Yes, a BaaS based MVP can scale, and plenty of products grow comfortably on managed platforms. But scale depends on your design as much as on the platform. Poorly structured queries get slow and expensive as data grows, needless requests create avoidable load and heavy jobs can strain a system that wasn’t built for them. Watch database performance, connection limits, caching, background processing, provider rate limits, monitoring and backups. Watch pricing too. A free plan may be fine for development, but production use adds costs for database resources, storage, bandwidth and function executions.
There is no universal user count at which a startup needs its own backend. Consider one when your business logic has outgrown the platform’s functions, when you need long running jobs or specialised processing, when you want tighter control over infrastructure or when complex integrations are easier to manage in a dedicated service. Even then, you rarely need to start over. A hybrid setup, where a Next.js frontend talks to a custom API that sits in front of Supabase, gives you control exactly where you need it and keeps the managed parts you already rely on.
A practical example
Imagine a SaaS product that helps small businesses manage customer records and projects. A sensible launch stack would use Next.js for the interface, Supabase PostgreSQL for data, Supabase Auth for identity, Supabase Storage for documents, Row Level Security for access control, server functions for trusted operations and a payment provider like Stripe for subscriptions.
You don’t need a separate backend server for each feature, but you do need to design the database carefully, configure organisation-level access, validate requests and test everything. When someone creates an organisation, the system must link them to it correctly. When someone else joins, it must verify their membership before showing any projects. When a customer pays, a trusted server-side operation must confirm the payment before premium features unlock. That is how BaaS and real backend engineering fit together.
Don’t confuse managed infrastructure with managed responsibility
So can you build a production-ready MVP without a custom backend? Absolutely, and for many startups it is the sensible choice. Let the platform carry the infrastructure while you concentrate on what makes your product different.
But you remain accountable for security, authorisation, business logic, database design, testing and scalability. A production-ready MVP isn’t defined by how many backend services you built yourself. It is defined by whether the product reliably delivers its value, protects its users and their data and can handle the demands placed on it. Build what makes your product different, delegate what existing infrastructure does well and bring in custom services when your real requirements justify them. Sometimes the smartest engineering decision is knowing what you don’t need to build.
Quick answers
Can I build a production ready app on Supabase alone? Many teams do. It provides PostgreSQL, authentication, storage, realtime features and Edge Functions, though you may still need extra services or custom server side logic.
Is Firebase enough for an MVP? Often, yes, depending on your data model, business logic, security needs and integrations.
Do I still need a backend developer? You may not need someone to run a traditional server, but you still need backend engineering knowledge for database design, authorisation and server-side logic.
Is BaaS secure enough for production? It can be, but security depends on how you configure it. Set proper access policies, protect credentials, validate requests and test your boundaries.
Can I migrate to a custom backend later? Yes. It is far easier if your business logic is organised, your data structures are documented, and your app isn’t tightly coupled to one provider.
BaaS or custom backend? Use BaaS when it fits your needs and helps you launch faster. Build a custom backend for specialised processing, complex logic or infrastructure control. You can also combine them.
Peter Kimbeghi is a software developer and the founder of BuildLaunch Studio, a software development agency. He helps founders launch MVPs, SaaS products and AI tools with Django, FastAPI, Next.js, PostgreSQL and Bubble.io. Follow for more practical guidance on building MVPs, and get in touch if you want help choosing the right architecture for yours.
