Haha, thanks 
I’m fine though; I run my own little practice as a Coda expert (and occasional business consultant) for hire, building the “bigger, better, more bad-ass apps” for end clients We’re in touch with Coda and I pass on any feedback I get, but I’m not involved in development or planning of any sort. And, frankly, I don’t think I even could help with actual coding (I’m a has-been coder who burnt out, now I enjoy tinkering with Coda and quickly building ad-hoc solutions that provide value quickly, without long development cycles.)
I agree with your sentiment. Although I also believe Coda has good reasons to build what they’re building now. I don’t think Shishir and co. are bad strategists, and I believe their decisions are driven by sheer data (i.e. people using Coda for “normie” Notion-level stuff vs those few who build badass apps). Coda has been for like what, 6 years in development now? and got its paid tier only recently. Sure they need to think of the business side of things.
Regarding the “DevOps and backend scaling” part — well technically there’s no “backend” behind the docs. These are files, fully loaded into your browser and calculated by Javascript. Occasionally a backend-side runtime would recalculate your doc (API access, automations, cross-doc), but the overall concept is just that — a file that’s processed on the frontend. It could never be as scalable as an e.g. real indexed lazy-loaded database on the backend (which I thought Coda was for a long time before I dug into the doc files). Some improvement may come when they update the way they pack data in those files, but that’s just gonna make them const times smaller and allow for const times more rows, after which the file would become of the same size. That’s why I’m saying that if one picks Coda, they must be well aware that it’s just a file, with all the limitations that come out of it. That’s not good or bad, that’s just how it’s designed.