You've just stepped into your role as CTO, only to inherit a revenue-generating system that's gasping for air. With 3,000 daily active users pushing the infrastructure to its — or the team's — limits, what's your next move?
Starting with B (finding quick wins) to do C (refactor) is definitely the way to go. Like you said starting with B gains trust with the company that hired you and allows you to get familiar with the system.
You asked for extra ideas for option B. Perhaps you may be able to duplicate the cloud infrastructure and split the user base over the two copies of your system.
You write that refactoring is more messy than a rebuild. Refactoring is more risky, but rewrites are always vastly underestimated. You might make the refactoring less risky by adding a lot of unit tests/integration tests first.
Starting with B (finding quick wins) to do C (refactor) is definitely the way to go. Like you said starting with B gains trust with the company that hired you and allows you to get familiar with the system.
You asked for extra ideas for option B. Perhaps you may be able to duplicate the cloud infrastructure and split the user base over the two copies of your system.
You write that refactoring is more messy than a rebuild. Refactoring is more risky, but rewrites are always vastly underestimated. You might make the refactoring less risky by adding a lot of unit tests/integration tests first.