If you really need this, seems like you'd be better served by the low code solutions on the cloud providers (AWS Elastic Beanstalk, Google App Engine, Azure App Service).
If you really need this, seems like you'd be better served by the low code solutions on the cloud providers (AWS Elastic Beanstalk, Google App Engine, Azure App Service).
The answer seems to be that people are starting with simple tools (beanstalk, heroku, GAE etc) but then quickly approaching their limits in terms of both features and cost - and move to "native" AWS / GCP / Azure. At this point they need to rebuild the infra from scratch, write all the IaC, etc. This is painful, slow and expensive. So it's either simplicity or extensibility, pick one.
We thought that someone must find a better way, it could just as well be us. The idea is to generate IaC in the background on top of a "real" cloud provider like AWS, making it seem to the user just as if they were using a PaaS. Until they want more - and at this point instead of moving to a different platform they can just extend TF however they like. No big one-off DevOps effort needed. Chances are that it can be done by the same person who built the backend, even if they never worked with AWS or Terraform before. Much smoother learning curve.
Also, many tech scaleups end up building "in-house herokus", often backed by Terraform. This was one of the motivations of us as founders, they had to do this more than once.
Where is model really works is what companies like Railway and render has done. You also own the compute and storage and retail that to end users. Your potential end users would rather prefer easily to use cloud provider than going to AWS and setting up PaaS on top of that. Your potential customer has got the time and effort for that.