What is the endgame of my BUIDL? This is the question most appchain developers need to answer.
Arguably, there are two directions. This BUIDL will either become an appchain, or become an appchain service.
The former means that the application is deployed on an appchain. The latter means that the application service is locally deployed on multiple appchains that adopt it.
So which way should this appchain developer choose, and how?
Here is a non-exhaustive list of observations.
If this application/service (Call it "App" from here) requires sophisticated supporting infrastructures around the core protocol, it should consider the appchain thesis. For example, the anonymous MACI protocol is not particularly complex on the smart contract level. However, in order to make it work nicely, a lot of supporting infrastructures are needed, including a network of operators, indexing services, campaign toolings, and more. Without these supporting infrastructures, users will have a very hard time to use such a complicated protocol, no matter how important it is to preserve privacy. This is one of the main reasons why aMACI is hosted on the Dora Vota appchain. Note: another reason is that aMACI needs a token economy to make operator service permissionless.
If App requires concentration of certain on-chain resources to work, it should consider the appchain thesis. For example, liquidity providers like Osmosis and Injective need concentration of liquidity. It will be highly inefficient if every appchain provides its own liquidity. Therefore, DEXes have to be appchains, and there won't be many of them.
If App cannot function well in a cross-chain environment, it might be an appchain service. For example, a domain service appchain might not work because it is unnecessary for users from one appchain to retrieve its user domain name from another appchain, even if it's doable.
If an App serves in a sovereign sensitive or security sensitive domain, it might be an appchain service. For example, a multisig wallet service should probably be deployed on home chains instead of a "multisig" appchain. Plus, a "bank chain" violates basic appchain principles (that Apps want sovereign independence) as well as blockchain ideals in general.
These criterias are not exhaustive. And it is true that some applications can choose either direction. For example, a quadratic funding protocol can either happen on a single appchain or deployed separately to client appchains. The AEZ Quadratic Funding grant program runs on Dora Vota as a generic supporting program for the Atom Economic Zone and the appchain ecosystem. In contrast, the Injective Grant DAO's quadratic funding rounds were deployed on the Injective blockchain. Note: in the case of quadratic funding, a lot of complexity has been handled by the DoraHacks platform. Therefore, the protocol deployment becomes flexible. This is in contrast to the case of anonymous MACI, which requires far more complex supporting infrastructures on the protocol level.
Another example is NFT platforms - Stargaze vs. Talis. The Stargaze platform is appchain thesis, and Talis is an appchain service. The strength of Talis is that many appchains might want their own platforms, use their native tokens to denominate their NFTs, and keep their NFT assets locally. These rightful desires make Talis a unique option as an NFT-platform-as-Service. Though Stargaze is still promising as an independent NFT platform and for its concentrated user pool.
Lastly, consumer Apps might lean towards appchain thesis because they can use native tokens to subsidize critical growth stages - doing so with foreign reserves will significantly increase cost.
To put these examples on a Venn Diagram:
Conclusion
Appchain developers can either choose to adopt the appchain thesis or the appchain service thesis for their BUIDLs, depending on the nature of the BUIDL.