It's not a tool I have ever thought was great!
As you pointed out, though, it's not an issue with Terraform, and the above case can be solved by manually managing the dependency with lifecycle management. So, I agree that most cases are often inflicted by things outside of Terraform.
As a database analogy, most of the problems I’ve seen are similar where people chose not to learn how their tools worked and then said it was the database’s fault that they were making billion-row joins or O(n) queries because they knew what they wanted and the database should have had Do What I Meant mode.
It's wrapping Pulumi and managing the state file for that. Yet another abstraction layer on-top of it all.
I'd love to be proven wrong if they can output Pulumi code from their application code?
Even then, I'm not sure what the monetization play here is? You're standing on the shoulders of Pulumi and you're open-source. If you go down the managed route and host the state files you'll be in direct competition with Pulumi's cloud offering...
1) Rampant copy-and-pasting instead of attempting any sort of code reuse
2) Reinventing the wheel poorly: instead of bringing in an existing module, they'll attempt to build their own half-baked one.
3) Poor ops practices like manually editing configuration through the console, then complaining about drift when TF overwrites their changes.
4) Lack of systems and networking fundamentals, like DNS or load balancing. If you don't understand it, how can you hope to configure something properly?Note this only applies to our OOTB providers which use Pulumi as our deployment engine of choice.
When you take away our providers Nitric becomes a communication layer between your application and any deployment engine that implements the Nitric deployment API: https://nitric.io/docs/reference/providers/custom/building-c...
This allows collecting a Bill of Materials of cloud concepts (e.g. APIs, topics, buckets, queues, policies etc.) and providing them however you like with code. This could be templating IaC, directly executing IaC, rolling your own solution or anything in between.
As for how we make money, currently we're doing consulting and dog-fooding our own tooling while working with existing teams struggling with more traditional deployment setups to make them more productive, their feedback is used to make own product even better :).