This is, unlike most plugs, actually not bad; the tool looks neat. But I am not your audience. I already have a strong grasp of AWS offerings and tools and know exactly what I want; what I don't have is the inclination to do it for development. If I did, I have Pulumi when I need to build cloud infrastructure and I'm allergic to visual tools at pretty much every level that isn't literally making a GUI.

The problem that I have, and it is probably intractable is 1) I don't want to manage developers YOLOing dev stuff around at work and having a gigantic bill show up because a developer randomed something expensive and didn't know/didn't care to monitor it, and 2) I don't want to deal with the expense or the slowness (of deploys and redeploys, and that includes the AWS resources--ever gone "ugh, I need to burn this down and start fresh" on a dev environment in AWS? it takes forever) of using AWS for development on personal projects.

Thanks for replying with your initial reaction. It's good to get your perspective.

Visual tools: If you are proficient at writing CFN templates or have found another tool to do that, cool. FWIW, our customers tell us they find the visualization useful when onboarding other engineers onto a project and then when they have a split screen between the template and the visualization to see how the CFN template is built.

Yoloing Developers: Heh. I'm stealing that phrase. But seriously, this is a common concern and a reason why managing accounts and namespacing for dev/test/staging/prod environments is a big deal. (plug - we do that too) At AWS dev managers get daily reports on the cost of each developer's accounts. While serverless tends to be much cheaper for dev environments than containers or EC2 instances, there are indeed ways to run costs up.

Deploying and redeploying: That's precisely why our CLI enables development against live cloud resources. When you use stackery local invoke, it assumes the function’s IAM role and fetches the function’s env var values. This enables rapid, and accurate, local function development. On the infrastructure side, it's common for our users to make up to 5 or more changes to their architecture in a day. The more you can do with the building blocks, the less code you need.

Thanks for taking a look.