The current idea is great, and I appreciate you sharing it with the community. The following is additional feedback, not meant as a replacement of your idea 
What I think the proposition is missing is the “who builds what and when” and “why would they bother” piece. It reads to me like trying to fix things by just adding more code (an SDK), and not by getting people excited to build. The same point you make in the “headwinds” section apply for this idea: it’s currently possible to create self contained, single file HTML dapps (i made a few I shared on X and with colleagues, they would qualify as mini apps), so if an SDK like this would exist, why would someone build a mini-app?
Building stuff for users on Polkadot is currently too hard and I acknowledge that. You gotta fight with wallets, fight nodes and complicated tech stuff, APIs also change very often, and it takes ages. In short, developping a dApp has a clear cost (maintenance & keeping up with upgrades), and the only reward mechanisms are either through treasury/grants or by manually building in a fee to a utility.batch call (cumbersome and confusing thing to present to a user).
So not many people do it, or they give up after releasing a V0-beta. Plus, even if you build something cool (like what we saw with the ordinals, to date it remains a visible bump in the charts), there’s no real way to keep earning from it easily. You just hope it helps your main, bigger project, or you ask the treasuries for money.
I believe we need to make it super easy for anyone (especially normal web devs) to build small, useful, and most importantly PROFITABLE things on Polkadot that people actually want to use. The key is that those builders should get paid automatically when people use their stuff. No asking the treasury or complicated grant applications for every little thing.
So maybe instead of mini-apps we can take the idea of a nice toolkit, like what the UX bounty is currently doing here: a thing that hides all the complicated Polkadot stuff, and add to it the incentivisation part (on-chain logic?).
Want to send DOT? One line of code. Want to use a smart contract? One line of code. An AI could even write this code for you, like what we showcased at the Parity retreat in December during the hackathon with the invited ecosystem teams, or the Façade project we have internally aiming to abstract away the set of decentralized APIs that the different Polkadot units provide. (if you like the sound of this, please reach out!!)
The crucial part is that if your little tool gets used and it involves a fee (even a tiny one), you automatically get a cut. By design, and not shoe horned on top. The hypothesis hinges on:
- If it’s easy and you can make money, more people will build. Not just hardcore crypto devs or hobby tinkerers. The builders have a vested interest in making their dapp/mini-app succeed, and thus Polkadot APIs used.
- Lots of small, useful tools mean users actually have things to click on and interact with. Solves the “nothing to do” feeling and the “same dapp but just with different colors”, so more diversity.
When builders try to make successful little tools despite the hurdles (CUDA isn’t fun to work with, but people use it to build cool stuff), we have designed a way to sustain continuous development: because success == they earn. In some sense, making those who use Polkadot win, will make Polkadot win. And I’m sure they’ll talk about it too, so free marketing & excellent inbound.
Giving people a reason to build here will help in the long run, because FWIW, Farcaster built a community around its social protocol first and then added the frames stuff, to add utility within the community vs a gimmick to bootstrap it.
A tangential (but crucial) point will of course be: who gets to select or curate the mini-apps that make the cut to the place we send people to (Nova/Polkadot App)? Without a distribution channel, success is difficult and we remain at the mercy of others.
So your idea would be in essence building a sort of “mall” and fill it with lots of cool little “shops” (the mini apps) that people want to visit. So far so good. What I suggest is to make sure the shopkeepers (developers) actually want to run them, and if they run them well (read: they are profitable), they are happy and have a chance to stick around as the sole stewards of their success.
I hope my answer helps to add some perspective! Happy to chat about it in a burger place soon, leaving the picture out for now 