There are many answers to this question depending on the stage of the startup and where they stand in the product development cycle. Also, it depends on the type of software development and the industry sector they play in.
Some types of products and technology stacks lend themselves to test-driven development - in which case a few QA engineers can go a long way. Other products may require manual testing - for instance, software that runs on custom hardware needs full system testing via manual testers - and in those cases, you would need a healthy balance between developers and quality assurance engineers.
The balance also changes depending on the current stage of the company. For a software startup, in the beginning they are really not doing production level coding - they are prototyping and hacking and creating testable MVP's (minimum viable products). During this phase, when the total headcount is below 5 full time equivalent, they can get away without a dedicated software quality assurance (SQA) function and share the burden of testing their software between themselves and their early users / testers.
When the team starts to get beyond 10 people and they are really starting to crank out product releases, quality and reliability becomes important because the lack of these things will result in reputation risk and an erosion of trust by customers.
For non-mission-critical, cloud software systems that are compatible to continuous integration and continuous deployment, you should start standing up a QA department and go for more automation engineers and fewer manual testers.
For companies developing custom software on custom hardware, or companies developing products in highly regulated industries such as healthcare IT or financial services, you may want to move towards a developer-to-SQA ratio of 3:1, moving to 2:1 as the team scales and capping off at 2:1. You would want to have more manual testers than automation engineers in cases where the custom hardware is very complex, or the ultimate quality and user experience requires a human in the loop (such as robotics and haptics).
Special thanks: Martin Trust Centre, MIT
Edit: Javier Rojas, 15/04/20