We built TwoOps because nothing else fit

Last year, we priced out the cloud ops stack we would recommend to a paying customer if Twofold had one. Five categories, the most-recommended tool in each, on real Azure spend for a team like ours. The total came to roughly $3,200 a month.

Twofold is two people. Dakota and Dillon. We were not going to spend that. We were also not going to ignore the problems those tools watch for, because we had watched too many small teams get burned by exactly those failure modes — storage accounts that silently stopped encrypting blobs, VMs running at 8% CPU racking up $400 a month, compliance frameworks that everyone claims and nobody actually tests, production incidents that paged the wrong person at 3 a.m. because nobody had built a real on-call rotation.

So we looked at why the price was so high. None of it was unreasonable. Datadog is genuinely worth $20 per host to a 200-person engineering org. Wiz is genuinely worth $40 per workload to a fintech with continuous CSPM requirements. Spacelift is genuinely worth $50 a run to a team with 30 Terraform repos. The pricing made sense for the customer those tools were designed for: large engineering orgs with platform teams whose full-time job is to operate this infrastructure.

We were not that customer. Most teams aren’t.

The middle market is invisible to enterprise tools

There’s a band of companies — 10 to 500 engineers, running production on Azure, no dedicated platform engineer — where every one of these tools is simultaneously necessary and priced for someone else. The free tier of any one of them is too limited to be useful. The paid tier of any one, multiplied across five categories, exceeds what the team can justify when the budget is being argued against another senior hire. So the team picks nothing, builds a few cron-jobbed bash scripts, and hopes.

You can guess what happens. The bash scripts don’t get maintained. The person who wrote them moves to a different team. Eventually the team adopts one tool, then another, then realizes nothing talks to anything. Drift detection lives in a Slack channel. Cost data lives in a Power BI dashboard nobody opens. Incidents live in PagerDuty. Compliance lives in a Notion doc someone updated 14 months ago.

That gap is what TwoOps was built to fill. One tool, one login, one audit log, six categories of cloud operations work — priced like a tool for a team without a platform engineer, not a tool for a platform engineering org.

What “AI-native” means when we say it

The other thing we noticed shopping for tools is that every product had bolted on an AI feature in the last 18 months. A “chat with your data” sidebar. An “AI summary” of an incident. A generated runbook draft. The bolt-on quality was unmistakable: the chat doesn’t know the topology, the summary doesn’t know the runbook that was already executed, the generated runbook is missing production safeguards. Each AI feature was an island, sitting on top of a product whose information architecture predated the AI by a decade.

When we started TwoOps, Sprint 0 was the model-routing layer: Haiku for triage classification, Sonnet for reasoning, Opus for incident root-cause analysis. Sprint 3 was the context budget — how much topology, how many recent metrics, how many recent changes does each prompt receive. Sprint 13 was embeddings plus semantic cache so repeated questions don’t re-burn tokens. AI is not a feature in TwoOps. It is how the product is shaped.

AI is not a feature in TwoOps. It is the architecture.

The practical result: when you ask TwoOps about an incident, it knows the affected resources, their dependencies, the metrics that were anomalous, the change that landed five minutes earlier, and the runbook your team already wrote for similar incidents. When it generates a remediation PR for IaC drift, it knows the surrounding code in the file it’s patching. When it writes a runbook from your description, it validates the script against a safety scanner before returning it. None of that is hard to use. It’s hard to retrofit. We didn’t retrofit.

Closing the loop

The third thing — and this is the one we’d most want to be remembered for — is that TwoOps closes the loop. Most cloud tools detect. A smaller number explain. Almost none act.

If we tell you a storage account has drifted from your Terraform, we don’t just send a Slack notification. We open the PR. The patch is generated by the same context-aware model that explained the drift. It’s validated against terraform validate before the PR is created. You review and merge — or close, in which case TwoOps records the finding as ignored and stops nagging about that specific drift.

If we tell you a VM is over-provisioned for its workload, we don’t just suggest a smaller SKU. We have the runbook to do the resize, with a dry-run executed in a sandboxed Azure Container Instance, and an approval gate so an admin signs off before the real run hits production.

The detect → explain → act loop is the part that actually saves engineering time. Detection alone produces a worse outcome than nothing — a Slack channel of alerts that get muted within a week, then ignored, then deleted in a quarterly cleanup. Explanation without action means the on-call engineer still has to do the thing manually at 3 a.m., which is the moment automation was supposed to help. Act is the part vendors avoid because act is the part that can break things, and the safety scaffolding to act responsibly takes longer to build than the alerting that surfaces the problem.

We built the safety scaffolding first. Every AI-generated change passes a structural validator (terraform validate, kubectl --dry-run, equivalent for the runbook scripting language). Every runbook executes in a sandboxed Azure Container Instance with no production credentials. Every action that would actually touch production sits behind a human approval gate by default. The audit log is hash-chained — each entry references the hash of the prior entry, so a tampered entry breaks the chain — and signed with our key, so an auditor can verify the log was not modified after the fact.

Detection alone produces a worse outcome than nothing.

Who we built this for

If you’re an engineering lead at a 10–500 person company running production on Azure, without a dedicated platform team or a $40k-a-year tooling budget, TwoOps is for you. Concretely, the people we keep hearing from are CTOs at Series A and B startups, VPs of engineering at small public-sector consultancies, and tech leads at the kind of mid-market SaaS companies nobody has heard of but quietly do $30M ARR.

If you have 20 engineers dedicated to platform, you will outgrow us. That’s fine. We would rather be excellent for the team that has nobody than mediocre for the team that has twenty.

If you are somewhere in between — a few engineers paying attention to ops on top of their day jobs, no dedicated platform hire, growing pressure on cost and compliance — that’s the customer we designed for. The product page has the features and pricing. The signup link is below.

What’s next

Public beta opens Summer 2026. Starter tier will cover two Azure subscriptions and 300 AI queries a month, free, indefinitely. Paid tiers add subscriptions, queries, SSO, and (soon) compliance evidence packs.

We’re publishing a post a week — half technical deep dives (how we built the hash-chained audit log; how we route between Claude models for cost and latency; how to detect Terraform drift with bash if you don’t want to buy anything yet) and half this kind of thing: candid posts about what we’re building, why, and what we got wrong.

If any of this sounds like your problem, join the waitlist at twoops.ai. Early-access invitations go out before public beta opens this summer. We’d love your feedback whether or not you become a paying customer. Especially if you never become a paying customer — that’s where the most useful product feedback comes from.

If your problem is bigger than what TwoOps fits and you’d rather have us help directly, tell us what you’re building.