Prospects couldn't compare our pricing with Fivetran's. I built the tool that gave them one number to take to their boss.
Technical
COMPANY
Meltano
YEAR
2026
STATUS
Shipped to live website
ROLE
Product designer and product lead - I owned the brief, scope, design, and shipping decisions
Meltano in a data ingestion tool that moves a company's data from its apps and databases into one place (Data warehouse) for analysis. Our biggest competitor, Fivetran, charges by how much data you move (Monthly Active Rows), but we charged by how long the work takes (Compute time). I built a savings estimator that translates one into the other, and it now opens a line of communication after every demo with a prospect or an existing Fivetran customer.
Impact
An approximate but real number that our sales team could defend
"You'll save money" turned into a per-connector range and one savings percentage, which most Fivetran-switch conversation now starts from.
Honest and practical saving ranges that can be trusted
The model showed an estimated savings range, backed by the type of connector (Database, Bulk or API), not a raw number which can easily be defeated.
From just an idea in a conversation to getting it shipped
I found the problem, discussed it on a call, modelled the pricing, won team buy-in with a Figma prototype, and handed engineering with a PRD and closely shipped it
PROBLEM
Two pricing models, no way to compare them
Charges for MAR - Monthly Active Rows
You pay for every row synced each month. The bill grows with data volume, even when the work is quick, so even the large databases get expensive fast. Prospects were quite frustrated with the cost.
Charges per hour of compute
You pay for the time your pipelines run for. The bill grows with how long and how often syncs run, not how much data they move. Prospects can’t know this number until they’ve used Meltano.
Fivetran bills per row of data moved each month (Monthly Active Rows). Meltano bills per hour of computing time. It's like comparing a taxi that charges per kilometre with one that charges per minute. A prospect holding a Fivetran invoice had no way to turn it into a Meltano number, so "you'll save money" stayed a claim, not an answer. I heard the same question on most customer calls I joined: "what would I actually pay?"
Nobody asked for a calculator. I saw a sales conversation that kept stalling at the same point and decided to fix it. I had a call with Aaron (Our founder) to brainstorm how we can fix this.
PROBLEM
To build a Meltano savings calculator, I had to know the Fivetran's pricing model, which was not public.
I collected Fivetran's published price points into a spreadsheet. Cost at different row volumes across Standard, Enterprise and Business Critical plans. I used AI to propose a pattern. It suggested tax-style brackets, where each extra million rows costs less than the last.
I didn't trust the first answer. I wrote every worked example with a sense-check anyone could redo by hand. For example: Postgres at 10M rows costs $1,358, because the first 4M are already in the $1,010 base and the remaining 6M cost $58 each. I was able to come to a pricing formula that worked!
After the formula confirmed to work, it also showed what doesn't move the Fivetran bill. The connector count, number of users and sync frequency. Only row volume and plan mattered. That shaped what inputs I'd need from users who'd use the savings estimator.
Savings depend on what kind of connector you run
Each data source a company plugs in is a "connector". Row-based pricing charges for volume. Compute pricing charges for work. The gap depends on how much data a connector moves versus how long the work takes.
Databases move millions to billions of rows, which is expensive on Fivetran, but the queries take 7–15 minutes on Meltano's compute time, so Meltano's bill stays small. The biggest gap.
Bulk exports move millions of rows per export, Meltano mostly pays for 12–20 minutes of compute time. A large gap.
App APIs like Instagram, LinkedIn, Google Ads, Salesforce etc. move fewer rows, and both tools hit the same rate limits, so syncs usually take 15–40 minutes either way. A moderate gap.
Sync frequency narrows the gap. More runs add Meltano compute hours while Fivetran's price stays the same, so hourly syncs shift the band down 5 points and 15-minute syncs shift it down 10. So one blanket savings claim would have been wrong for most prospects. The estimator classifies each connector and applies a band:
Three real comparisons can’t prove a precise number, so I didn’t go after claiming one. I made each band wide enough to hold the real spread in sync times, then checked them against real cases.
No new components were made, so every decision went into what inputs to take and what output needs to be shown
HIGHLIGHT
Ask only what a Fivetran customer already knows
A connector from a dropdown, monthly rows on a slider with readable steps (10K to 1B+), and sync frequency. All three are readable off a Fivetran usage page. I wanted to include processing/compute time, but that direction was rejected since Fivetran never exposed their compute resources and duration. So the prospects don't have it, and asking for it would make them do our maths.
HIGHLIGHT
Start from their connectors, not abstract categories.
Picking "Postgres" assigns its type automatically from a list of 100 connectors. The prospect never needs to learn what Bulk, API or Database means.
HIGHLIGHT
Show ranges, not a promise
Each connector shows its Fivetran price and a savings range. The summary shows the Meltano cost as a range and one rounded headline: "You will save approximately 31%". A vendor calculator is usually presumed biased, so I set one rule. No number appears unless the formula and the savings table can defend it. Fivetran's is priced on its cheapest plan (Standard) so that Fivetran's bill doesn't look inflated.
HIGHLIGHT
Design for the person who never touches the tool
Whoever runs the numbers rarely signs the contract. I made sure that our URL captures all the connectors a user selects, so that each scenario lives in the URL, so it can be shared as a link and the report is laid out for a manager reading it cold. Later, we also added 'Share this view" button.
I got buy-in with a Figma prototype before spending engineering time
Once the pricing model held up, I didn't go straight to build. I prototyped the full flow in Figma, using the existing site's styles, and walked Aaron (Our founder and CEO) and Kyle (Sales head) through it with real outputs from the formula. Review concluded with an extra feature to download a report as PDF so that it could be shared with the leadership.
I owned the problem framing, pricing model, savings logic, UX, Figma prototype, copy and QA. A front-end engineer built it into the site and connected the APIs. Every output could be checked against a known answer before launch. The spec also listed what must never appear in the UI.
15+ demos booked after prospects saw how much they could save if they switch to Meltano from Fivetran
The estimator became the opening move in Fivetran-switch conversations on calls with prospects, in-person conferences and events
I and our sales team used the savings estimator in every Fivetran-switch demo since May '26
Estimates landed within 5%-15% accuracy of real Fivetran invoices that our customers shared
The savings estimator became a conversation starter and became the default signature line in every sales conversation
What I'd do differently
Instrument it from day one. I can describe how I and our sales team used it, but I can't show a funnel from visit to report to demo. I'd ship event tracking with the first release of our pricing estimator.
Publish the method behind the bands. I noticed that prospects trusted the number more once they saw how it worked when I was on a call with them. A short "how we estimate" panel might have increased the trust for every reader, not just the ones I spoke to.
TL;DR
PROBLEM
Fivetran, our biggest competitor, charges by how much data you move. Meltano charges by how long the work takes. Prospects couldn’t compare the two, so “you’ll save money” stayed a claim nobody could check, and sales conversations stalled on it.
WHAT I DID
With no brief, I turned Fivetran’s public pricing into a formula and checked it against real prices. I worked out that savings depend on the type of data source, then designed an estimator that turns a prospect’s own setup into one savings figure. I got team buy-in with a Figma prototype and handed engineering a testable spec.
RESULT
The estimator went live on meltano.com and now follows every demo with a prospect or Fivetran customer. Real cases matched or beat its estimates, never fell short. 15+ demos booked after prospects saw how much they could save if they switch to Meltano from Fivetran.