A software development team shipping features got a lot faster with AI writing a good share of the code. The platform that code runs on sadly can't keep up with that speed, so you end up with an application that's ready for customers and a foundation underneath it that was set up for a proof of concept and forgotten after that.
I've been building cloud platforms for almost a decade, and it's not the technology that changed so much, but the pressure on the work that changed most.
The red velvet pillow your software lives on
Software is what you build. The features people see and click on, the screens, the logic, the thing your customers actually pay for.
The platform is what it runs on. Your accounts and environments, so the separation between where you test things and where your customers use them. The network, and who or what can reach it. Where your data lives. Where the logs end up when something goes wrong, and how a new version gets to production without having to fear for disruptions.
Those two get mixed up in budget conversations more often than you'd think, which is how a company ends up funding features generously and the environment they run in barely at all.
Where the overlap runs out
A platform has to be built for your workload, and that's most of the reason it takes longer. There's overlap between companies, plenty of it, but the requirements are never identical and working out which ones apply to you is the actual job.
It usually starts with the data. Public data asks far less of you than personal data does, and once personal data is in play then where it's stored, who can reach it, how long you keep it and how you prove any of that stops being a detail you add later and becomes part of the design.
Then availability. How long can you be unreachable on a Tuesday afternoon before it costs you real money or real trust, and how much duplication are you willing to pay for to avoid it. Running the same thing in two places raises part of your bill, and for some businesses that's obviously worth it while for others it very much isn't.
Then performance and where your users sit, because someone connecting from another continent has a slower experience than your local test does, and that's decided by where you put things rather than by how the code is written.
Almost none of that changes the functionality of your application. All of it changes the platform you need. That's why this part comes with conversations and customization instead of a template you can drop in.
There's a second reason too. The providers keep moving. AWS and Azure release services constantly, deprecate others, and change how things are structured, so the infrastructure as code that describes your platform has to follow along. Older guidance still reads as perfectly sensible while being out of date, and this is where AI is less reliable than it is with application code. It'll hand you a pattern that was correct three years ago with total confidence, and you need to know enough already to notice. That's based on what I run into in practice rather than on a study I can point you to.
A bug is not the same as being gone
A bug in your application is annoying. You fix it, you ship again, most people didn't even notice. Your application not being available at all is a whole different thing. So is not being able to work out why it went down, or how long it'll take to get it back.
Two numbers are important to agree upon before you need them:
- How long you can be down before it really hurts?
- How much data you can afford to lose if you have to fall back to a backup.
Those two answers decide a lot about how the platform gets built.
A concrete example: most cloud regions are made up of separate data centers a small distance apart, called availability zones. Spreading your application and its database across two of them means one of those buildings can have a bad day without taking you offline. It costs a bit more and it's a decision you make at design time, because retrofitting it later means moving a live database, which is a hassle you prefer to avoid.
Own that sh*t
Scaling shows this most clearly. Going from twenty users to a thousand tends to need remarkably few changes in the application and quite a lot in the platform it lands on. If the foundation was never designed to grow with you, you're not scaling this quarter regardless of how quickly your team writes code.
Which leaves the question of who looks after that layer. You can grow the skill internally, and that's a real option if you've got someone with the interest and the time to keep up with how fast this moves. Or you bring in somebody who has built it before and has them design it properly, which costs money now instead of costing you a migration later while customers are watching.
Either way it's worth deciding on purpose, and preferably before your first genuinely busy month. It's still cheaper than doing it in a hurry, and considerably less cozy than staying on localhost.