[BAB] Lesson 5: Why you shouldn't sacrifice decentralization
Blockchain apps are called dApps (decentralized apps). They're decentralized because no one owns/controls the smart contracts. Sure, you built it, but it's out of your hands once it's deployed. At least that's the default behavior.
There are ways to opt-out of decentralization for your app. You can launch an upgradeable contract without governance, take too much of your token for yourself, write your smart contracts so only you can use them, and even build a centralized app that users have to go through. There are valid reasons to use these approaches, but it's my opinion that you shouldn't do this for serious projects. Here's why:
Centralization requires trust
The whole point of blockchain is that you can use it without trusting other users. We can call a smart contract independently to trade your tokens for mine without needing to meet in a dark alley or involve an escrow agent. If the smart contract is centralized in any way, then it's not trustless. I won't use your contract unless I trust you.
Creating a token for your dApp that hands over control to token holders is probably the most common way to decentralize. This comes with the added benefit of allowing you to raise money. However, if your smart contract isn't upgradeable, there's not really anything to govern. Be clear about what control token holders will have, and don't complicate your app with a token if you don't need to.
Don't add centralized layers
Even if you lay a good foundation for your dApp on the blockchain, you can still make centralized choices on top of that. By default, you only need a frontend single-page app to talk directly to the blockchain. The only backend infrastructure you need is the frontend hosting (Vercel and Netlify are probably the easiest to use), and a node of the blockchain that exposes its API (prefer hosting your own, but it's ok to use someone else's node if you trust them).
That's it. You can add other centralized infrastructure, but most of the time you should avoid it. If you have data/images/video/etc. that would be too much to store on-chain, look for decentralized options for hosting (IPFS for example). At the very least, store a hash of the data on-chain so it can be verified and trusted by your frontend.
The one exception to this is performance. Your app still needs to be fast. No one wants to use a slow website, no matter how cool the technology is behind it. It's ok to use caching, pre-fetching, and other typical performance tricks with centralized infrastructure. Just treat the performant results as "optimistic" representations of the actual data. Everything should eventually resolve to the true blockchain data.
-Luke
P.S. Simplifying your off-chain dependencies will also make it easier for other developers to build clients that use your smart contracts. This helps build further trust and a vibrant community.