We built our own status page with AI, replacing a $65k SaaS product | Blog | Fivetran

Solutions

Connectors<br>Pricing<br>Resources

English

Contact SalesLog inStart free

Data insights

We built our own status page with AI, replacing a $65k SaaS product

August 7, 2026

Mike Gordon<br>Vice President, Platform Engineering<br>Fivetran

Anchor Link

Share

Two engineers used AI coding agents to design, build, and ship a production-ready status page — here's what worked, what didn't, and what we'd do differently.

In about 4 months, 2 Fivetran engineers — Valentina Mačković and Jelena Kostic — designed, built, and shipped a replacement for a $65,000-a-year SaaS product, using AI coding agents from requirements through production. It now serves Fivetran's public status page and roughly 26,000 notification subscribers. This is what it actually cost, what actually worked, and what we got wrong.<br>Background: What we were replacing<br>Fivetran's status page was a heavily customized application that ran on Atlassian Statuspage. It did the job it was designed for, but our use of it had drifted well past the native capabilities of the Statuspage framework. Our status page displays a large number of individually monitored services, and we wanted per-service status and uptime for each of them. This is a shape the hosted product was never really built around. So we layered customization on top: Google Cloud Functions computing uptime from our BigQuery data warehouse, an incident tracker syncing state, and automation wiring it into our incident management process.<br>The result was a system with real operational costs on both sides of the ledger:<br>Money: It cost about $65,000 per year , driven substantially by the fact that every notification subscriber is billable. We had ~26,000 of them.<br>Time : We spent a consistent number of hours managing, troubleshooting, and fixing the status page, adding up to at least $10,000 of engineer time per year.<br>Performance: The page loaded slowly, and sometimes failed to load on a first attempt. For a page whose entire purpose is to be available when everything else is not, that is a serious failure mode.<br>Silent failures: We hit cases where updates did not propagate, and we didn’t detect the deficiency.<br>Rate limits: Our own automation ran into the vendor's API rate limits.<br>To be fair to Atlassian, none of this is a scandal. It is what happens when you push a general-purpose product a long way past its intended shape, and it is also the ordinary arithmetic of per-subscriber pricing at 26,000 subscribers. In this post, we’ll show how it’s possible to use AI to replace a system that’s outgrown its requirements.<br>[CTA_MODULE]<br>Why we decided to move<br>The status page sits in an unusual spot. It is a small application — a handful of read endpoints, an admin panel, an email queue — but it carries production-scale consequences. When Fivetran has a bad day, it is the artifact thousands of customers look at, and a mass notification event can mean 50,000+ emails. Low complexity, high stakes.<br>That combination is precisely what made it interesting. A year ago, a DIY status page would have been an easy “no”: the engineering cost dwarfed the license. What changed is that AI shifted where that line sits for a certain class of software — well-specified, modest in complexity, expensive to rent. We would soon find out whether this line shifted far enough.<br>What drove the build-vs-buy decision<br>Three things, in order of weight:<br>Control over reliability. A status page that depends on a third party can only ever be as reliable as that third party, and we could not fix the parts that were slow. Owning it meant we could decouple it from both our own core platform and from an external provider.<br>The pricing model was misaligned with the product. We were paying per subscriber for what is, structurally, a mailing list. Costs scaled with customer growth while the value delivered did not.<br>We wanted the organizational answer, not just the software. Could 2 engineers using AI agents deliberately take something from a PRD to production? If yes, that is a reusable capability. The status page was a good place to find out because the blast radius of getting it wrong was survivable. We could run it in parallel with the old one until we trusted it. We could also call the experiment a failure without pouring a huge amount of time, money, and effort into it.<br>We also want to be honest about the boundary of the conclusion. Fivetran's own product is a SaaS product, and we are not arguing that AI makes SaaS obsolete. A status page is far easier to replace than a data movement platform. But the same logic applies at the margin to any vendor: the more your usage is a thin, well-specified slice of a general product, the more the build side of the equation has moved.<br>How we built it<br>Setting up AI<br>The most important decision the team made was to spend a long time not writing code.<br>Before any feature work, Valentina and Jelena built what amounted to an...