When you are developing a service you go through a series of trials to make sure it really works and can do enough of what the customer wants. Proof-of-concept, alpha and beta trials, pre-production, soft-launch – there’s a number of ways to work through this to get ready for market. Today, the received wisdom is to get it into the hands of users as soon as you can, and continue to develop based on their feedback until it’s ready to go out into the big wide world.
Ah yes, the real world where time frames have to be met and money has to be made. Often we don’t have the luxury of endless iterations until perfection is achieved, we have to go with what we’ve got, warts and all. Or we don’t have the money to build everything so it’s robust and infinitely scalable from Day One. That often means compromises, chewing-gum and string solutions rather than proper systems and processes. This is normally OK as long as the core elements are robust. And as long as you don’t have too many customers.
So, you launch a system that’s not quite ready and can’t scale. Well, probably the main platform will but some of the support processes, which are based on bits of paper, excel spreadsheets and lots of Virtual Assistants, won’t. As soon as you get too successful, they will fall over and you’ll have lots of unhappy customers. Or probably, lots of unhappy would-be customers, which is worse (trust me, I’ve been there).
It’s not ideal but it is manageable. The important thing is to know when the flakier parts of the system are likely to fall over and how you are going to replace them. That means having plans with costs and timescales. Then you can monitor the load across the system and prioritise action on those parts that are getting close to the max, so you switch them out before they fail.
It’s a bit like building a railroad, you only need enough track down for the train to travel the next day. As long as it’s built when the locomotive comes along, you’re fine.