Fivetran’s replacement of a $65,000-a-year status-page subscription shows the full build cost

Fivetran says two engineers used AI coding agents to replace a status-page subscription that cost about $65,000 a year. The work took about four months, and Fivetran says the replacement now serves roughly 26,000 notification subscribers. The replacement is currently public at status.fivetran.com. Fivetran estimates a $109,500 build cost and an annual run rate, or expected yearly operating cost, of $12,400 to $25,000. It gives a rough 2.5-year payback, which is the time annual savings need to recover the build cost.

This case helps an operator examine one rented software line item. The decision must include product fit, specification, migration, recurring operation, and payback. It must also count production hardening: the security, integration, testing, and release work that makes the first version safe to operate. Fivetran’s quick prototype was the smaller part of that path.

Fivetran published its account on Aug. 7, 2026. A Hacker News submission linked to the post on Aug. 11. The submission date establishes only when the post reached Hacker News. The hours come from tracked work-item estimates, not timesheets, and exclude untracked management, QA, and design time. Fivetran used an illustrative rate of $100 per engineering hour. These are self-reported estimates, not audited costs.

The old $65,000 subscription had become a poor fit

Fivetran had pushed Atlassian Statuspage beyond the product’s usual shape. To report service-level status and uptime, it added Google Cloud Functions, BigQuery calculations, an incident tracker, and incident-process automation. The subscription cost about $65,000 a year, driven largely by per-subscriber pricing for roughly 26,000 people. Fivetran estimates that engineers spent at least another $10,000 a year maintaining the custom layer.

Fivetran also reports slow or failed first loads, updates that did not always propagate, and API rate limits that affected its automation. The price rose with subscriber count, although much of Fivetran’s required behavior already lived in custom code. That fit and pricing mismatch made the line item worth examining.

The replacement remained a high-consequence system. It needed a public page, an admin panel, a few read endpoints, and an email queue for tens of thousands of incident notifications. However, the scope was narrow enough to specify, and Fivetran could run both systems in parallel. The company could stop the build if the replacement failed to earn trust.

The fast first version depended on 300 hours before feature work

A minimum viable product, or MVP, is the first version with enough working features to test the main product idea. Fivetran’s MVP took an estimated 162 hours. Before that feature work began, the team spent 52 hours on requirements and design, 88 hours preparing context for the agents, and 160 hours on agent tooling and orchestration.

The preparation included product and technical specifications, an OpenAPI schema that defined every API endpoint, design assets, project rules, six agent roles, and reusable coding instructions. The engineers defined the API, data model, acceptance rules, and development process. The agents produced code within those boundaries.

The prototype repository ran from Mar. 4 through Apr. 15, 2026. In those six weeks, the team opened 46 pull requests; eight did not merge because they were duplicates or dead ends. The first three weeks focused mainly on context and reusable instructions. Most features then landed in about two weeks.

The estimates for the six phases sum to 1,049 hours. Fivetran rounds the full path to production to about 1,050 hours, equal to about 131 person-days or 6.6 person-months.

Scroll sideways to see all 3 columns.

Work	Estimated hours	Share of total
Requirements and design	52	5%
Agent context preparation	88	8%
Agent tooling and orchestration	160	15%
MVP	162	16%
Production hardening and rollout	537	51%
Pre-release bug fixing	50	5%
Total to production	About 1,050	100%

Source: Fivetran’s estimates from tracked work items. The 537 hours of hardening and rollout plus 50 hours of pre-release fixes are the basis for its statement that production hardening consumed 56% of the total effort.

At the illustrative $100 hourly rate, Fivetran values the engineering labor at about $105,000. AI tokens added at most $4,500, for an estimated total of about $109,500. Labor remained the main cost.

Production hardening and rollout consumed most of the work

For Fivetran, production hardening also included infrastructure, audit records, migration, scale tests, bug fixes, and controlled release. The company finished the MVP at the end of April and put the replacement into public use in late July.

The team tracked 72 production work items and another 17 pre-release bugs. It moved the prototype into Fivetran’s production GitHub repository and common Bazel build system. The team added Okta authentication and role-based permissions for staging and production. It also built a Cloud SQL Postgres staging environment with continuous deployment and structured logging. The team rewired the incident and status integrations, built a Java client for the product dashboard, and used a feature flag, which is a switch that controlled the new integration path during rollout.

Subscriber migration alone required about 40 hours of scripting, followed by data corrections. The migration requirement was to move about 26,000 subscribers without lost or duplicate notifications. The team also tested a sustained 9,000 notifications in five minutes. Other fixes covered special characters, old incidents in uptime calculations, maintenance-window state changes, and differences between the old and new uptime results.

The rollout kept the most difficult actions until the end. Fivetran first completed QA in staging. It then ran the new production system for weeks with live data and automation, while customer traffic and notifications stayed off. Next, a DNS change moved customer traffic, with notifications still off. The team enabled notifications last.

After cutover, a real incident that Fivetran classifies as P1 triggered the new system to send notifications to about 26,000 subscribers. That event supplied production evidence for the notification path and the staged release sequence.

The annual run rate sets the payback period

Fivetran forecasts an annual run rate of about $12,400 to $25,000. It lists about $2,400 to $4,800 for infrastructure and about $10,000 for ongoing engineering, based on roughly one-tenth of a full-time role. Those listed components sum to $12,400 to $14,800. The source does not itemize the amount behind the $25,000 upper bound.

Fivetran estimates annual savings of about $40,000 to $53,000 against the previous subscription. Against the estimated $109,500 build, it gives a rough payback period of 2.5 years.

A 2.5-year recovery period gives estimate errors time to matter. New requirements, higher maintenance, infrastructure changes, or a lower vendor price can move the result. Reusable agent instructions and engineering experience have value only if later work uses them.

Fivetran states the buying boundary directly. If the status-page bill were $10,000 a year instead of $65,000, it would probably keep buying. The company does not claim that AI makes SaaS obsolete. The case applies to a narrow, well-specified slice of a general product with a price that does not fit its use.

Screen one software line item through the whole path to production

Start with the work the rented product performs in your company. List the features, data, integrations, administrators, and current failures. A replacement candidate becomes stronger when this scope is stable, narrow, and separate from the vendor’s deeper data, compliance, or network value.

Establish the current annual cost, including the invoice and internal time used to maintain customizations. Identify the unit that drives the vendor price, such as seats, subscribers, events, or data volume. A pricing mismatch exists when that unit raises the bill faster than the value received.

Estimate the build through production, not through the first demonstration. Count requirements, context preparation, tooling, the MVP, integration, authentication, observability, migration, bug fixing, testing, release work, and the annual run rate. An AI token budget or a fast feature sprint cannot stand in for this estimate.

Plan the release before approving the build. A strong candidate can operate beside the existing product and accept representative traffic without irreversible actions. If the team cannot shadow the old system or reverse the cutover, allow more time and cost for risk.

Match the evidence to each failure mode. For a customer-facing release, review the repository and rendered website change before publishing. For a notification or other write path, test duplicate-safe retries so a lost response does not create a second business action. The first AI pilot guide shows how to keep results and exclusions tied to the next decision.

Set the acceptable payback period before seeing the prototype. Use conservative estimates, then test what happens if migration takes longer or maintenance costs more. Decide whether to continue, narrow the scope, keep buying, or stop.

Keep buying unless the narrow slice clears the payback and cutover tests

If the candidate is a customer-facing web application, BaristaLabs can help define and build the bounded slice through AI-assisted website development, with a first release and clear owner handoff. Discuss one replacement candidate when you have a current cost, a specific product slice, and a decision to make.

Keep buying when the software use is broad, the requirements keep changing, the cutover cannot be isolated, or the conservative payback is weak. Investigate a replacement when a thin, well-specified slice carries misaligned pricing, the full build and annual run rate still meet your payback limit, and the old and new systems can run in parallel before cutover.