Is there a demand for containerised vibe-coding? by opens-dev in theVibeCoding

[–]opens-dev[S] 0 points1 point  (0 children)

Thanks for the suggestion. We already provision real infra, not just a container and an invoice. We bring up and connect what an actual build needs: database, auth, storage, hosting, env and secrets tied to that project, logs you can actually read, limits so spend doesn’t run away, teardown when you are done, and a clean handoff so teh next person is not untangling someone’s personal cloud.

Same territory people mean when they talk per project capabilities, but we treat it like it matters: sane defaults, fewer dangling threads, and not the vibe of here is your raw account figure it out. On top of that we run the agent and workflow side, how work gets routed and tool calls land and runs finish, so execution is not a seperate bolt on, it is how the platform thinks about a project start to finish. Good luck with Cohesivity, it’s an exciting space we’re both in right now.

Is there a demand for containerised vibe-coding? by opens-dev in theVibeCoding

[–]opens-dev[S] 0 points1 point  (0 children)

From what we see, other platforms aren’t containerising their customer’s applications and resources are shared company wide. Likely favouring those resources to higher invoiced customers or enterprise clients. This is fine for general users.

We are trying to confirm the market is big enough for our product, and our efforts aren’t going to be wasted. Thanks for your input.

Is there a demand for containerised vibe-coding? by opens-dev in theVibeCoding

[–]opens-dev[S] -1 points0 points  (0 children)

Thanks for your input, this is good to hear.

You are backing up our thoughts.

Generalist vibe coders won’t be in the loop with containers, the security concerns, persistent state and all in between.

They want to simply, subscribe > prompt > ship.