Yeah, you're pretty much doomed. If your framework is so great then it should be its own company; conversely if the framework isn't good enough to be its own company then you shouldn't be using it.
Creating your own tools will only add more friction into the process. One thing to be careful of is that a developer may invest time into a project because the developer loves building that project. That doesn't necessarily mean that it is good for the company. You might need to get an outside opinion on this, as the CTO is going to be attached to the project.
What happens when the company grows? Who will maintain the app that's built on his custom framework?
Do startups build their own tools at all? At what stage do they usually start building custom tools?
Most startups I've been a part of have done a combination of both.
It really depends on which parts of the stack the lead devs are most comfortable with. If you've got a front-end ninja leading the charge you'll most likely end up with standard frameworks / generally-recognized-best-practices for the back end, while on the front-end they'll want to push the envelope. And visa versa if you have a backend person leading the team.
A little bleeding-edge is a good thing. I wouldn't shy away from it on premise, but it does require that you trust your CTO 100%; and that they do their homework. Embracing a non-standard framework is great, as long as you truly understand what you're passing up. If your solution is better (and you can talk coherently about why) then more power to you.
As far as onboarding new team members and/or supporting the system once it's built: in my opinion: thorough documentation and test-coverage are the crucial parts there. It'd be rare for a senior developer to be scared away just because you weren't using framework XYZ... but if your choice of framework is undocumented and untested that might make other devs say "screw it, either we're rebuilding this thing with best-practices or I'm walking away" ...not a situation you want.
All that being said: at the end of the day, this person is the CTO... at this phase in your startup the MOST important thing is that you two get to a point where you can talk this kind of stuff out. This is one of the easiest/least-stressful decisions you'll be trusting them with; if you cant get to a point where you feel good with their explanation/decisions, then there might be bigger problems at play here.