Company Profile • AI & Developer Tools
Firetiger Built a Watchtower for Every Deploy - Then Cursor Bought the View
A seven-person startup taught AI agents to babysit your deploys and tell you, in one word, whether the change was healthy. Two years and $7.6M later, Cursor absorbed the team to close the loop from writing code to running it.
For most of software's history, watching production was a human job. Someone kept a browser tab open on a wall of dashboards, waited for a red line to spike, and then went digging. Firetiger looked at that ritual, decided it was the wrong job for a human in 2026, and handed it to an AI agent instead. The company's one-line promise: know every change is healthy in production.
That sentence sounds modest until you notice what it replaces. Firetiger does not sell you a dashboard and wish you luck. It attaches an agent to every pull request, reads the diff, works out what the change is supposed to do, and then watches the rollout across staging, canary and production. Minutes later it hands back a single verdict compared against the pre-deploy baseline - and it keeps watching for up to 24 hours in case something breaks on a delay.
01What Firetiger actually did
The product the market saw was called Change Monitors. When a developer opened a PR, Firetiger read the diff, built a monitoring plan tailored to that change, and then tracked staging, canary and production independently so it could compare them. It was not just error-counting. The pitch was intent verification: did the change accomplish what it set out to do, not merely avoid throwing exceptions? One verdict per deploy, with root cause attached when the answer was bad.
Underneath that simple interface sat the part the founders clearly cared about most: the data layer. Firetiger built what it called a telemetry lakehouse - an observability database that stores logs, metrics and traces cheaply on S3 as Apache Iceberg tables of Parquet files, queried schema-on-read by an embedded DuckDB engine and collected through OpenTelemetry. Keeping raw data on object storage cost roughly a tenth of a traditional database, with the trade-off that complex queries take seconds to minutes rather than the sub-second snap of a hosted dashboard. The argument was that telemetry built for the human-operations era captured too little detail to feed an agent the context it needs. So Firetiger stored more, stored it cheaply, and pointed the agents at it.
02The problem it was solving
The uncomfortable subtext of the AI-coding boom is that when machines write more of the code, machines also write more of the bugs - faster than any on-call human can triage them. Coding agents will happily ship a change; almost nothing was watching to see whether that change behaved once it hit real traffic. Firetiger built the missing half of the loop: ship a change, see how it behaves, respond when something goes wrong.
Early customers put a number on it. Firetiger reported a 32% decrease in change-related issues within two weeks of turning the product on. That is the kind of figure that gets you meetings.
03How it was different from Datadog and Grafana
Two design choices separated Firetiger from the incumbents. The first was orientation: the platform was built agent-first, not dashboard-first. A Datadog or a Grafana assumes a person is in the loop reading charts. Firetiger assumed the reader was a machine that needed structured, queryable context and a decision at the end.
The second choice was the invoice. Firetiger argued that observability vendors "make more money when you write more data to them, not when you make your software more reliable" - which is exactly why teams delete logs they later wish they had kept. So Firetiger billed for the work its agents did - $5 per pull request monitored, fifty cents an investigation - and left data volume out of the meter entirely, with ingestion unlimited. Storing everything cheaply on S3 was what made that pricing possible, and it doubled as a quiet critique of the whole category.
Bars are illustrative of the pricing philosophy, not audited billing data.
04Who was behind it
Firetiger was founded in 2024 by Rustam Lalkaka and Achille Roussel, two engineers whose resumes read like a tour of internet infrastructure: Cloudflare, Segment, Twitch and Twilio between them. That pedigree is why the seed round looked the way it did. In February 2026 the company raised $7.6M led by Sequoia Capital, with angel checks from Cloudflare CEO Matthew Prince - whose company the founders had helped build - and Segment co-founder Calvin French-Owen.
The two brought complementary obsessions. Lalkaka spent roughly seven years at Cloudflare, rising to VP of Product and shipping infrastructure used by billions - the person who had watched, up close, what production reliability means at scale. Roussel was the distributed-systems engineer: at Segment and then Twilio he led Centrifuge, the pipeline that reliably moved billions of events a day, and on the side he authored open source that a lot of the industry quietly runs on, including kafka-go, parquet-go, and the WASI port of the Go language. When people like that tell you telemetry is stored wrong, the telemetry is probably stored wrong.
The stated ambition went further than dashboards. Firetiger described a near future of "human-less software factories" where agents write code, agents verify it in production, agents find and fix what is broken, and humans steer toward outcomes that matter. It is a big claim, and the product was only the first floor of that building - but the direction explains why the company built a data layer far heavier than a PR-checker strictly needs.
Named customers included Clerk, Kernel, Avora, Architect, Town, Voxel, Judgment Labs and Hyperspell - one founding engineer at Kernel said Change Monitoring had become "standard practice across the majority of PRs." The integration list told you who the product was for: OpenTelemetry and Datadog for signals; GitHub and Linear for code and tickets; Postgres, MySQL, Clickhouse and Iceberg for data; AWS and GCP for cloud; Slack, PagerDuty, Gmail and Intercom for where humans actually get pinged.
05Then Cursor bought the view
In August 2026, roughly 18 months after founding, the story took its final turn. Cursor announced that the Firetiger team was joining to co-develop production-environment agents. The framing was less a trophy acquisition than a puzzle piece clicking in: Cursor's agents write and ship code; Firetiger's agents watch what happens next. Together they could ship a change, see how it behaves, and respond when something goes wrong - the loop that neither side had closed alone. The standalone product was wound down: signups closed, existing customers given end dates, the technology folded into Cursor.
It is a clean lesson for founders watching the AI gold rush. Firetiger did not try to out-Datadog Datadog. It found the one workflow the coding-agent era had forgotten - does this deploy actually work? - built it precisely, and became the exact thing a bigger platform needed. The reward for answering a narrow question well was a fast, strategic exit into the company shipping the code Firetiger was built to watch.
06Where it fits, and where it wouldn't
Firetiger fit teams shipping often enough that manual deploy-watching had become a tax - fast-moving engineering orgs already sending telemetry through OpenTelemetry and deploying through GitHub. It fit the emerging world where AI writes a growing share of the diffs and someone, or something, has to grade them.
It fit less well where there is little to watch. A team that ships monthly, runs thin telemetry, or has no canary stage gives the agents little baseline to compare against - and the honest verdict there is "inconclusive," which is not what anyone is paying $599 a month to hear. Firetiger's bet was that the world is moving the other way: toward more changes, more automation, and less patience for a human squinting at a dashboard at 3am. Cursor, evidently, agreed.