~11 min read · You paid for "an app and a backend". You assume the backend is something you own. Maybe it is. Maybe it's a folder of configuration in someone else's service. The difference matters more than most buyers realize — and it shows up later, always at the worst possible time.
The first time the question becomes urgent is usually the day Google changes Firebase's pricing.
Or Supabase deprecates a feature. Or a free tier turns out to have always had a quota that nobody read carefully. Or the service you've been using is acquired and the new owners email you to say things are changing in 90 days.
Up to that moment, "the backend" was just a word your developer used and you nodded along to. You knew the app talked to something over the internet. You knew that something stored your users and processed your transactions. You probably didn't know what kind of thing it was, because it never had to matter.
Now it matters. And depending on what you actually bought, your options range from "switch to a competitor in an afternoon" to "rebuild from scratch over six months" — and you can't tell which one you're in without understanding what kind of backend you have.
This article is about the four very different things that commonly get called a "backend", what each one buys you, what each one costs over time, and how to figure out which one is sitting underneath your app.
The Four Kinds of "Backend"
The word "backend" is doing too much work in modern app conversations. It refers to at least four meaningfully different things.
Custom server code. A program someone wrote — usually in Node, Python, Go, Ruby, or similar — that runs on a server you pay for (or your developer pays for on your behalf). It has its own database. It defines its own endpoints. It does whatever your app needs it to do, in code you (or someone you can hire) can read and change. This is the original sense of the word.
Backend as a Service. A platform — Firebase, Supabase, AWS Amplify, Appwrite — that provides authentication, a database, file storage, and a handful of related services through a vendor's SDK. Your app talks directly to the platform. There is no custom code in between, or only a small amount. The platform is the backend.
No-code or low-code stitch. A combination of services — often a spreadsheet-as-database (Airtable, Notion), an automation layer (Zapier, Make, n8n), and possibly a hosted form or builder. The "backend" is the wiring between these services. There's no server code, but there's also no single product underneath it.
A thin layer over someone else's API. Your "backend" is a small custom layer that mostly forwards requests to another service — Shopify, Stripe, OpenAI, an industry-specific SaaS. The interesting business logic lives somewhere else; your code is the glue.
These four are not the same. They cost different amounts to build. They cost different amounts to operate. They lock you in to different degrees. They survive growth differently. And they answer the question "what do I actually own?" with four very different answers.
The buyer who knows which of the four they have is in a much stronger position than the buyer who doesn't — even if they don't write a single line of code themselves.
What You Actually Own in Each Case
This is where the differences become consequential.
With custom server code, you own all of it. The code is in a repository you control. The database is on a server you (or your developer) configured. The data is yours, in a format you can export, query, or migrate to a different host. If you wanted to take your entire backend and move it to a different server tomorrow, you could — slowly, but you could. The work is real but bounded.
With Backend as a Service, you own the configuration but not the platform. Your data lives in the vendor's system. The way you query it is through their SDK. The authentication flow is theirs. The file storage is theirs. If you wanted to leave Firebase tomorrow, you'd have to: export your data (usually possible, sometimes painful), reimplement every backend feature you'd been getting for free, rewrite every piece of your mobile app that talks to Firebase, and migrate your existing users without losing any of them. This isn't impossible. It's typically a multi-month project, and it's the reason Backend as a Service lock-in is real even when nobody designed it to be.
With a no-code stitch, you own each service's data individually, but the connections between them are inside the automation platform. Your customers are in Airtable. Your purchase events are in Stripe. The logic that turns a Stripe charge into a row in Airtable lives in Zapier. If Zapier disappears tomorrow, the logic disappears with it — even though the underlying data is still in your spreadsheets. You own the parts. You don't own the way they cooperate.
With a thin glue layer, you own the glue but not the substance. The interesting business logic lives in Shopify or Stripe or wherever else, and your relationship to it is through their API. If they change the API — which they do, often — you have to follow. The portability of your "backend" depends entirely on the portability of the services it wraps.
These four kinds of ownership are all legitimate. None of them is automatically wrong for a given business. But they're all different, and a buyer who's been told "we built you a backend" without being told which kind has bought a different product than they think.
We've written more about the broader ownership spectrum in what owning your code actually buys you. The backend dimension is one specific slice of that conversation.
The Cost Shape
The four kinds of backend have very different cost shapes — both up front and over time.
Custom server code is expensive to build and relatively cheap to operate. A serious custom backend for a typical business app usually costs $8,000–$25,000 to build (within a larger app project), and then a few hundred dollars a month in hosting and maintenance, scaling slowly as you grow.
Backend as a Service is cheap to build and gets expensive at scale. Wiring up Firebase to a Flutter app might take a few days and cost very little. The first few hundred users are essentially free. But Backend as a Service pricing tends to scale with usage in ways that surprise people — reads, writes, function executions, storage — and at meaningful scale, Backend as a Service can become more expensive than custom infrastructure, sometimes dramatically.
No-code stitches are very cheap to build and have a flat-ish cost shape — until you hit the limits of the automation platform. Zapier and Make have task limits per month, and once you cross them, costs jump in steps. The bigger trap is that no-code platforms have logical limits too: there are things they simply cannot do, and the moment your app needs one of those things, the whole backend has to be replaced.
Thin glue layers have a cost shape that's mostly determined by the underlying service. Your costs are mostly Stripe fees, or Shopify subscriptions, or OpenAI usage. Your custom code is small enough that maintaining it is cheap. The risk is that the underlying service raises prices, changes terms, or simply discontinues the API — and your business shape changes with theirs.
If you're trying to evaluate your situation: a useful question is where will my costs be in three years if my app grows 10x? The answer depends entirely on which of the four you have. Custom code: roughly linear. BaaS: probably superlinear, and worth modeling. No-code stitch: a hard wall at some point. Thin glue: whatever the wrapped service does.
This isn't a reason to avoid any of the four. It's a reason to know which you have, so the future cost doesn't ambush you.
The Lock-In Dimension
Lock-in is the part nobody mentions until they need to leave, and then it's all anyone talks about.
Custom code has the least lock-in. The code is yours; the database format is standard; another developer can pick it up. There's friction in moving to a different host, but the friction is bounded and predictable.
Backend as a Service lock-in is much higher than buyers usually realize. It's not that the data is locked in — vendors generally let you export. It's that the application is locked in. Every part of your mobile app that talks to Firebase talks to Firebase specifically, in Firebase's SDK. Migrating to a different backend means rewriting all of those parts. A typical Firebase-based mobile app has Firebase calls in dozens or hundreds of places, and "switch to a different Backend-as-a-Service" often turns out to be cheaper as "build a custom backend" because the work is similar either way.
No-code stitches have the most fragile kind of lock-in: not deep but brittle. Your logic is split across services that don't really know about each other. Recreating it elsewhere is conceptually easy but logistically annoying, and during the migration, things will quietly break in ways that take weeks to discover.
Thin glue layers are locked in to whatever they wrap. If you wrap Shopify, you're a Shopify business; the wrap is just polish on top of that. Migrating away means changing the underlying platform, which is the larger problem.
A useful way to think about lock-in is: if my current vendor doubled their prices tomorrow, what would I do? If the answer is "I'd shop around and switch in a month", you have low lock-in. If the answer is "I'd pay the doubled prices because moving is worse", you have high lock-in. The vendor knows this. They priced the increase accordingly.
This isn't a reason to avoid any of the four. Some lock-in is rational — you're trading flexibility for speed of development, and for an early-stage product that's often the right trade. The mistake isn't choosing lock-in. The mistake is choosing it without knowing.
The Simple Test
If you want to know which kind of backend you have, without reading any code, ask your developer one question:
If you disappeared tomorrow and I needed to move my backend to a different system, what would that take?
The answers map almost perfectly to the four categories.
If the answer is a couple of weeks to set up a new server and move the code — you have custom server code.
If the answer is a few months, because we'd need to migrate off Firebase / Supabase / Amplify — you have Backend as a Service, and you're about to find out exactly how much lock-in is in play.
If the answer is we'd have to rebuild the connections — the data is fine, but the logic between services is inside Zapier / Make / etc. — you have a no-code stitch.
If the answer is most of the backend is Stripe / Shopify / [other service], so it depends on whether you want to keep that platform — you have a thin glue layer.
If the answer is I don't really know — you have a problem that's bigger than the choice of backend, and the next step is finding a developer who does know.
This question is also valuable when hiring a developer for a new build. The way they answer it about projects they've worked on before tells you a lot about how thoughtfully they make backend decisions, and how seriously they take the question of what you'll own when the engagement ends.
The Hybrid Pattern That Often Works
The four categories above are not mutually exclusive. In practice, the backends we recommend for many serious apps are hybrids — and the hybrid is often the best of the four worlds.
A common, healthy pattern looks like this.
Authentication and file storage are handled by a Backend as a Service layer — Firebase Auth, Supabase Auth, or similar. Why? Because authentication is a security-critical, slow-to-build, fast-to-get-wrong category of work, and the Backend as a Service vendors have done it better than most custom implementations would. The lock-in is real but contained — the auth layer is a small fraction of your app, and switching it later is unpleasant but not catastrophic.
The business logic — the rules of what your app actually does, the data shapes that matter to your business, the workflows that define your product — lives in custom server code. This is the part we describe as the "rules app" and "data app" in the three apps inside your app. It's the part of your backend that should be portable, queryable, and ownable, because it's the part that contains your business.
Payments go through Stripe (or similar), wrapped by a thin layer of your own code. The payment logic is too important and too regulated to reinvent, and Stripe is too good at it to compete with. The wrap is small but meaningful.
Routine automations — send an email when X happens, post to Slack when Y happens — can live in a no-code automation layer, because they're not on the critical path and they benefit from being visible and editable by non-developers.
This hybrid is more thoughtful than any of the pure approaches. It uses BaaS where BaaS is genuinely better, custom code where ownership matters, third-party services where someone else has solved the problem more reliably than you could, and automation where flexibility is the point.
The buyer who knows this pattern can have a much more useful conversation about backend choices. The buyer who doesn't tends to end up with a pure-Backend as a Service build (cheap and locked in) or a pure-custom build (slower and more expensive than necessary) — neither of which is wrong, but neither of which is usually optimal.
What This Means for Your App
If you've gotten this far and you're not sure which of the four (or which hybrid) your app actually uses — ask. The conversation costs nothing, and the answer affects every decision about your app for the next few years.
If you have pure Backend as a Service and you're growing past the early-stage point: it's worth understanding what migrating off would look like, even if you don't intend to. The number itself is useful. It tells you what the lock-in is actually worth and whether the pricing power your vendor has over you is worth pre-empting.
If you have a no-code stitch and your business is becoming serious: there's usually a point where the stitch needs to be replaced with at least a small amount of custom code. The signs are slow workflows, hitting platform limits, or business logic getting too complex to manage in Zapier. We touch on this in you bought an MVP — what did you actually get — no-code stitches are a great way to validate, and a poor way to scale.
If you have a thin glue layer and the underlying service is healthy: you're probably fine, and your strategic question is more about that underlying service than about your own code. Watch their roadmap. Watch their pricing. Have a Plan B for the day the API changes.
If you have custom server code and it's been built thoughtfully: you have the most flexible option, the highest up-front cost, and probably the right answer for any business that's planning to operate for a long time. The question is whether the code itself is healthy — and the rest of our cluster, particularly the technical-debt piece, covers that diagnostic.
Backend Is a Word, Not a Thing
The most useful thing about understanding the four kinds of backend is that you stop treating "the backend" as a single thing your developer hands you and start treating it as a set of decisions with consequences.
Some decisions are right for fast iteration and wrong for scale. Some are right for early validation and wrong once the business is real. Some are right for businesses that own their data and wrong for businesses that ride on top of someone else's platform. None of them are wrong in isolation. All of them have downstream effects that determine what the next three years of your app's life feel like.
You don't have to be technical to ask which decisions were made and why. You just have to know that the word "backend" is hiding at least four different products — and that the question of which one you have is much more important than the question of whether it's "working".