The intersection of what I kept getting burned by

I have been working in DevOps and platform engineering for years, mostly around cloud infrastructure, Kubernetes, CI/CD, and on-call operations.

What I enjoyed most wasn’t writing YAML or Terraform for the sake of it, it was designing systems that don’t fall apart under pressure.

But I kept seeing the same failure mode, across companies of all sizes:

Infrastructure didn’t break because people were careless.
It broke because of false certainty.

Assumed defaults.
Copied “best practices”.
Confident advice that wasn’t quite right.

Those mistakes don’t show up immediately. They show up during incidents, when someone has to own the outcome.

That’s the intersection that led me to build CodeWeave - where DevOps, architecture, and AI have to be held to a higher bar than “sounds reasonable”.

Reusing patterns (not starting from zero)

Luckily, I wasn’t starting from scratch.

I’d already spent years:

• Designing production cloud architectures
• Building Terraform modules and CI/CD pipelines
• Writing internal runbooks after real incidents
• Watching how senior engineers reason about risk

So instead of trying to invent something flashy, I focused on encoding those patterns.

CodeWeave is built around a simple rule:
If something can’t be confirmed from official documentation or clear inputs, it must not guess.
That decision shaped everything.

• Outputs are complete, not snippets
• Missing inputs are flagged explicitly
• Trade-offs are explained, not hidden
• The result is something you can realistically run through
  terraform init → plan → apply
  and take responsibility for in production

Organic interest (without pushing links everywhere)

After launching, I shared a few demos and real scenarios publicly, mostly showing how CodeWeave handled actual production problems I’d seen before.

What resonated wasn’t “AI for DevOps”.
It was “this doesn’t guess”.

Engineers started asking questions like:

• “How does it know what not to generate?”
• “What happens when inputs are missing?”
• “Would you trust this during an incident?”

I didn’t try to answer everything with marketing copy. I just explained the design decisions honestly and stayed active in the comments.

Most of the traction so far has come from:

• Technical discussions
• Demos of real incidents
• People sharing it internally with “this is interesting, take a look”

No growth hacks - just showing the work.

Being explicit about the ICP

One mistake I’ve made before (and seen others make) is being vague about who a product is really for.

So with CodeWeave, I was intentional.

It’s for:

• Startup founders without a full platform team
• DevOps / platform engineers who own production
• Teams that want speed without sacrificing safety

It’s not for:

• Toy projects
• Pure experimentation
• People who just want quick snippets

That clarity makes everything easier:

• Messaging
• Feature prioritisation
• Pricing
• Support conversations

Not everyone needs this, and that’s fine.

Limiting the free tier on purpose

CodeWeave runs real models and produces structured, high-effort outputs, so the costs are real.

The free tier is intentionally limited:

• Enough to understand the value
• Not enough to rely on it indefinitely

The idea is simple:
People who’ve felt the pain, outages, bad deploys, firefighting - immediately see the value. For them, the price is trivial compared to the cost of one mistake.

Interestingly, limiting the free tier has improved the quality of users and feedback significantly.

What actually motivates people to pay

The biggest lesson I’ve learned (again) is this:

People don’t pay for “nice tools”.
They pay to reduce risk, save time, or avoid expensive mistakes.
CodeWeave exists because:

• Infrastructure mistakes compound
• AI confidence without grounding is dangerous
• Speed without guardrails eventually backfires

This isn’t about automation for its own sake.
It’s about better decisions at the point where intent meets reality.

What’s next

Right now, the focus is on trust:

• Better grounding
• Clearer refusal behaviour
• More environment-aware outputs
• Stronger runbooks and validation steps

Next phases include:

• Guardrail-aware deployments
• Smarter routing across models based on task and risk
• Living runbooks that evolve with the system

The goal is not to replace engineers, it’s to make it harder to make avoidable mistakes.

If this resonates, I’d genuinely love feedback from other builders and engineers here.

You can check out CodeWeave here:
👉 https://copilot.codeweave.co/

Happy to go deep on any of the design decisions.