First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before trying (and inevitably failing) to run the Javascript gauntlet[1].
Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric. Google is maximally incented to protect their service and has the resources and mindshare to do so. Nobody cares about someone else's bespoke mail service. People who care about mail security but don't trust Google just VPN to a private mail server.
Incidentally, Fortune 500 companies grappled with this problem many moons ago, and have adopted the strategy of "things that need to be sent over secure email will instead send links to an HTTPS web application we run onsite and call 'secure email' even though it's really just 'private file sharing'". Which makes it doubly hard to pitch this as a product idea: most of your market has already rejected the model you're considering.
This is a bad startup idea. Avoid it.
[1] For starters: in browser JS, every function call can be redefined arbitrarily many times before it gets key material, web content is allowed to influence or even rewrite that code, there's no effective way to verify code before running it, code is pulled from multiple sites, there are browser "chrome"-level security flaws still being discovered, there's no solid secure random number generation, functions are timeable, there are solid implementations of only a very few algorithms, and what remains to be implement is hazard-prone. Writing crypto code in JS is hubris, pure and simple.