If you're a bit bigger, so that you're needing to put webpage projects on a separate machine, so maybe QA can try it, or you can run a demo, you can and should set aside one or more chunks of public DNS hierarchy for the test systems, for example a cert for *.test.example.com can allow a number of test systems at Example Inc to do HTTPS. If you're happy to pay a commercial CA they'll mint such a certificate for fair price upon proof you control example.com. If you want to use Let's Encrypt, they'll need you to have records for test.example.com in public DNS to run proof of control automatically. Provisioning the private key and copies of (periodically updated) certificates to the test boxes is not exactly a difficult problem for a working test environment.
Only if you (perhaps out of paranoia) refuse to do that, should you try what I suggested with a private CA hierarchy for web pages.
If you're building something quite different (not TLS, or genuinely not on the Internet, although what the point of things other than the Internet is I'm not sure) then you can and should roll your own PKI, but that's a huge under-taking, you should already have hired at least one person who knows MORE about this than me or you're already in deep trouble.
But are you telling me that each developer should do this for their personal webpage project just because Chrome might decide to put HTTP-only pages behind a modal dialog?