There are many things that scale pretty far just by doing them right, without a lot more work.
For a process like calling new customers, I bet they have a halfway-decent CRM and email system to send out invites, track acceptances, and schedule calls. You could manage it with a spreadsheet, but it'll be easier and more reliable and contribute to other CRM tasks to manage it the right way from the beginning. And when the CEO can't do it anymore the whole process seamless shifts to letting VPs or account managers pick up the task (until that doesn't scale).
On the technical side, for an example: it's not very difficult to start with a scalable-by-default architecture, like with one of the "serverless" Docker-image based managed platforms like GCP Cloud Run. If your service fits there, you get scale-to-zero and scale up for basically free.
The trick, as always, is deciding what to do when you hit some feature that would be easier on a single stateful server. Do you bail, and go single-server or push through? If you stay with serverless, you're better positioned for future growth. But, you might hit that next feature that makes you go single server, and have wasted the work to stay serverless. This is what makes this stuff hard.
There are many things that scale pretty far just by doing them right, without a lot more work.
For a process like calling new customers, I bet they have a halfway-decent CRM and email system to send out invites, track acceptances, and schedule calls. You could manage it with a spreadsheet, but it'll be easier and more reliable and contribute to other CRM tasks to manage it the right way from the beginning. And when the CEO can't do it anymore the whole process seamless shifts to letting VPs or account managers pick up the task (until that doesn't scale).
On the technical side, for an example: it's not very difficult to start with a scalable-by-default architecture, like with one of the "serverless" Docker-image based managed platforms like GCP Cloud Run. If your service fits there, you get scale-to-zero and scale up for basically free.
The trick, as always, is deciding what to do when you hit some feature that would be easier on a single stateful server. Do you bail, and go single-server or push through? If you stay with serverless, you're better positioned for future growth. But, you might hit that next feature that makes you go single server, and have wasted the work to stay serverless. This is what makes this stuff hard.