Search for the cost to build an ad exchange and every result comes from someone with a position to defend. Development agencies quote the build — a bounded number, because the thing they sell has an end date. Platform vendors assert that buying is cheaper — a conclusion, because the thing they sell is the alternative. Neither is lying, exactly. Each is pricing the part of the problem its business model touches and leaving out the part it doesn’t.
The part both leave out is the same part, and it is the expensive one: what it costs to operate the exchange after it exists.
Our guide to setting up an RTB exchange describes the system as running on two clocks. The auction clock is synchronous and short — a bid request arrives, the auction clears, a response goes back a few hundred milliseconds later. It can be specified completely, tested exhaustively, and finished. The settlement clock is asynchronous and open-ended — win notices that arrive after the auction is forgotten, discrepancies against a buyer’s numbers, floors that drift out of date, seats whose behaviour changes without notice. It has no terminal state.
Every build quote you will ever receive prices the first clock. The decision between building and buying turns on the second, and the second is not a line item in a quote — it is a staffing commitment that recurs every year you operate.
So this article will not hand you a total. A total computed for someone else’s exchange — someone else’s traffic, salaries, seat count — is noise with a currency symbol on it. Instead it decomposes the cost into six categories, and for each one says what it covers, what drives it up or down, and the arithmetic to run with your own numbers. It ends with the honest version of the build-vs-buy answer, including the cases where building wins.
One disclosure up front: Floxis sells the buy side of this decision. The categories below are structured so you can check every step without trusting us.
Table of Contents
- Why the published numbers are useless
- The two clocks, and which one the quote covers
- The build: getting to a working auction
- Seat integrations and the adapter treadmill
- What does infrastructure cost at your QPS?
- The settlement loop: the cost that never closes
- Yield operations: the loop that sets every price
- Monitoring and on-call
- Compliance: ads.txt, sellers.json, schain, consent
- When does building your own exchange win?
- When buying wins
- The worksheet: price it with your own numbers
- Key takeaways
- Buying the second clock: where Floxis fits
- Sources and standards worth bookmarking
Why the published numbers are useless
An agency quote is scoped to the specification you handed over, and the specification you can write before operating an exchange describes the auction clock: endpoint, validation, fan-out, ranking, response. The deliverable ends at handover. Everything in this article’s later categories — adapters drifting, reconciliation, on-call, compliance upkeep — is absent not through dishonesty but through scope: you did not ask for a recurring cost, so none was quoted.
A vendor’s “buying is cheaper” claim has the opposite defect. It compares the vendor’s fee against a build estimate — usually a large round one — that the vendor supplied itself, and the build estimate it argues against is, again, the first clock. Winning an argument against a number you invented is not analysis.
The third failure is subtler: even an honest total does not transfer. The cost of an exchange is a function of your queries per second, your seat count, your engineering salaries, and whether the people doing the work already exist on your payroll. Two operators can run the same architecture at costs that differ by multiples, and both numbers are correct. The only portable form of the answer is the one this article gives: categories, drivers, and arithmetic.
The two clocks, and which one the quote covers
The distinction that organizes everything else: an exchange has a component you can finish and a loop you cannot, and they are priced in different units.
The auction clock is priced in project units — engineer-months to a milestone. Once the endpoint validates correctly, the router enforces its deadline, and the auction picks reproducible winners, that work mostly stays done. Our setup guide walks the whole chain and sizes the working auction at weeks for an experienced team, which is precisely why so many exchange projects are mis-scoped: it is the estimate people quote, and it covers only this clock.
The settlement clock is priced in staffing units — a fraction of your team, forever. Win notices must be credited to auctions that have already expired from memory. Your counts must be reconciled against each buyer’s counts, monthly, bilaterally. Floors that were right at integration drift quietly wrong. Seats degrade without announcing it. None of this work completes; it is only ever kept up with.
Hold that frame while pricing each category below. Categories one and two are mostly project-priced. Categories three through six are mostly staffing-priced, and they are the ones a build quote cannot contain.
The build: getting to a working auction
This is the category every quote covers, so the job here is not to price it for you but to show which inputs to interrogate. The formula is trivial:
Build cost = team size × calendar months × loaded monthly cost per engineer.
You know your loaded cost — call it E per engineer-year, and use the real number with employer costs, not the salary. The two other factors are where quotes go wrong.
What drives the build up:
- Formats. A banner-only exchange is the minimum. Video adds VAST handling and a second event stream (the auction win and the playback impression are different events with different failure modes); native adds asset-level validation; CTV adds both plus device quirks. Each format is a real slice of scope, not a checkbox.
- The latency target. Hitting a published bid timeout at volume is not free — connection pooling per seat, TLS termination at the edge, deadline-aware cancellation. Floxis publishes a 200–300 ms DSP bid timeout in production, which is a reasonable anchor for what demand partners expect; engineering to consistently meet a number like that under load is a meaningful share of the build.
- The data pipeline. A log-level record of every bid, win and drop is what makes categories four and five affordable later. Teams that cut it from the build pay for the omission every month afterward, in reconciliation arguments they cannot win.
What drives it down: a strictly scoped launch (one format, one region, JSON only), an engineering team that has built real-time systems before, and the fact that Prebid Server exists as an open-source implementation whose request-path decisions you can simply read instead of rediscovering.
The one audit to run on any build quote: find the line where it ends. If the end state is “a working auction that passes the test suite,” the quote is scoped to the easy part, and everything below is your unpriced remainder.
Seat integrations and the adapter treadmill
An exchange with no demand connected is a very fast auction over nothing, so the second category starts the day the first ends. Each demand seat is an integration project: even partners who are fully OpenRTB-native have dialects — proprietary ext fields, auction-type assumptions, currency handling, macro conventions, QPS caps — and partners who speak no RTB at all need a custom adapter built from scratch. Call the effort W engineer-weeks per seat and calibrate it from your own first three integrations, because nothing else will predict it: your first OpenRTB-native seat may land in days, your first tag-based one may take an order more.
Integration, though, is not the real cost. The real cost is that every integrated seat becomes a protocol relationship you maintain. Partners upgrade OpenRTB versions on their own schedule, deprecate fields, add newly required ones, change their creative rules, and expect your side to keep up. Our white label ad exchange guide calls adapter maintenance the hidden cost nobody budgets for, and it compounds for a mechanical reason: the load scales with your success. More demand means more seats, and more seats means more of your engineering week spent on other people’s changelogs.
| Variable | What it is | Where you get it |
|---|---|---|
| N | Demand seats connected | Your sales pipeline |
| W | Engineer-weeks to integrate one seat | Your first three integrations |
| T | Maintenance touches per seat per year | Partner changelogs — assume it is not zero |
| D | Engineer-days per touch | Your incident history |
Year-one integration cost is roughly N × W in engineer-weeks. The steady state is N × T × D engineer-days per year, forever, with N only growing. That second expression is the first of the recurring costs a build quote does not contain.
What does infrastructure cost at your QPS?
The infrastructure bill is the most mechanical of the six categories, and the one where intuition fails hardest, because an exchange’s defining behaviour — fan-out — multiplies traffic instead of merely serving it. Every inbound bid request you accept becomes up to one outbound request per connected seat, so your egress is not your traffic; it is your traffic times your demand count.
Run the arithmetic on illustrative inputs to see the shape. At 10,000 inbound QPS, fanning each request out to 10 seats with a 4 KB payload, you are pushing 10,000 × 10 × 4 KB = 400 MB per second of egress — about 3.2 Gbit/s — before a single response has come back. Over a 30-day month (roughly 2.6 million seconds), that same 10,000 QPS is about 26 billion inbound requests and, at that fan-out, 260 billion outbound ones. And if the build included the log-level ledger it should have, storage joins the bill: a 1 KB record per auction at 10,000 QPS is roughly 26 TB a month before compression. None of those are your numbers — substitute your own QPS, fan-out, payload size and retention, then multiply by the bandwidth and storage rates your provider actually charges.
What drives the bill up: unshaped fan-out (sending every seat everything), video and CTV payloads, verbose JSON, and multi-region deployment — which you will want anyway, because giving demand partners a real 200–300 ms window means being network-near them, not near yourself.
What drives it down is more interesting, because most of it is operational rather than architectural. Traffic shaping — sending each seat only the traffic it has demonstrated it will bid on — directly divides the egress bill, and it is settlement-clock work: someone has to watch per-seat bid behaviour and keep the shaping current. Compression and per-partner Protocol Buffers help at the margin. And the hosting model matters: metered per-GB cloud egress and committed bandwidth on dedicated servers produce very different bills for exactly this traffic shape, so price both against your numbers before trusting either.
The settlement loop: the cost that never closes
This is the category that decides most build-vs-buy questions, and it is the one no quote contains, because it is not a build at all. It is the operating loop our setup guide spends its second half on: crediting win notices to auctions whose in-memory records have already expired, keeping the win URL and the billing URL separate so revenue is counted at the billable event and not before, and running the bid-to-win discrepancy counter that tells you the loop is alive.
The recurring work looks like this. Every demand partner is a bilateral, monthly reconciliation against numbers computed by their system, not yours — and the tie-breaker in every dispute is log-level data. If your build kept a complete bid, win and drop ledger, reconciliation is a query; if it didn’t, reconciliation is an argument, and you lose arguments with the side that pays the invoices. Floors need revisiting on a cycle, because a floor that was right in March is quietly costing you money in June — either a person owns that review or you build automation for it, which is more build. Seat health needs the same attention: bid rates sag, creative rejections spike, and the difference between catching it in a day and catching it in a quarter is real revenue.
Price this as a fraction of a person: H × E, where H is the share of a full-time role the loop consumes and E is your loaded cost. What drives H up is almost entirely the number of partners — each one adds a reconciliation relationship — plus the quality of your data pipeline, which is decided back in the build. What never drives H to zero is the nature of the work: it is not a backlog you finish, it is a loop you keep turning. This is the line item that converts “the build came in on budget” into “why does the exchange need two more people than the plan said.”
Yield operations: the loop that sets every price
The settlement loop decides what you get paid. This one decides what you charge, and it is the category both quotes and build plans leave out, because it does not look like engineering.
Somebody has to decide the floor on each segment. Somebody has to decide the margin, and revisit it when a partner’s buying changes. Somebody has to decide which traffic is worth sending to which seat, and which segments cost more in QPS than they return. None of these are one-time decisions. A floor that paid for itself last quarter stops paying when a buyer changes how it bids; a margin that cleared fine at your old traffic mix suppresses fill at the new one. The inputs move continuously, so the decisions expire continuously.
Price it the way you priced the settlement loop: hours per cycle, times cycles per year, times the number of endpoints and partners you run. Most operators at small and mid scale run this monthly, by hand, in a spreadsheet — affordable precisely because it is too infrequent to be good.
The harder cost is not the hours, though. It is that you usually cannot tell whether the change worked. Raise a floor and watch revenue rise, and you have learned nothing: the week was different in a dozen other ways. Establishing that a yield change actually paid requires running it against a control — the same traffic, split, with one arm left alone — and measuring the difference. Almost nobody building their own exchange builds that, because it is a second system on top of the first: deterministic request splitting, per-arm accounting, a statistical test that knows when a difference is real rather than noise, and an automatic revert for when it is not.
So the honest version of this line item is that you pay for it either way. You pay in salary for someone to tune by hand and hope, or you pay in engineering to build the measurement harness that tells them whether the tuning worked. The build quote covers neither.
Monitoring and on-call
An exchange fails silently, and it fails in the direction of losing money. A broken adapter looks like a soft decline in bid rate. A stalled settlement loop looks like falling fill, because an exchange that cannot confirm wins cannot pace, so it throttles — a failure chain the setup guide traces in detail. Nothing pages you by default; you have to build the thing that pages you.
The build side of this category is bounded: the metric set (bid rate, win rate, bid-to-win discrepancy, per-seat latency percentiles, drop reasons counted separately), the alert thresholds calibrated against your own baselines, the dashboards. It is real work, but it is project-priced and it ends.
The recurring side is the rota, and it is a staffing constraint rather than a technical one. An exchange is 24/7 revenue infrastructure: when it is down or degraded, the meter runs. Someone must be reachable at 3 a.m., and a rotation that does not burn people out needs more people than a minimal build team contains — if the whole exchange team is two engineers, on-call is not a rotation, it is a lifestyle, and it will price itself into your attrition instead of your budget. Count the humans your on-call policy actually requires, multiply by the share of their cost the rota represents, and put it in the worksheet. It is one of the largest honest differences between running an exchange and having built one.
Compliance: ads.txt, sellers.json, schain, consent
The compliance surface is small compared to the auction, and skipping it is not an option, because its failure mode is not a fine — it is demand quietly filtering you out of the supply path.
Four pieces recur. Ads.txt and app-ads.txt mean crawling your supply partners’ authorization files on a schedule and refusing traffic that fails the check — a crawler you build once and operate forever. Sellers.json means publishing and maintaining an accurate registry of everyone selling through you; buyers’ systems read it, and staleness reads as opacity. The schain object means validating the full supply path on every request. And consent — the IAB TCF string for GDPR, GPP for US state privacy — must pass through your exchange unmodified, because an exchange that drops or rewrites consent strings makes every downstream partner non-compliant on its behalf, invisibly, until an audit finds it.
The initial implementation is modest next to the auction build. The recurring cost is the point: the crawler runs continuously, sellers.json changes every time your partner roster does, and the privacy frameworks are moving targets that add jurisdictions and versions on their own schedule. Budget a small but permanent slice of engineering attention, and treat any plan that marks compliance “done” as a plan with a gap in it.
When does building your own exchange win?
A vendor article that concludes “buy” in every scenario is an advertisement, so here is the honest boundary: there are four conditions under which building is the correct answer, and if one of them genuinely holds for you, the worksheet below will show it. The test for each is deliberately strict, because the failure mode in this decision is flattering yourself into the build.
You already employ the engineers. If your team runs adjacent real-time systems — a bidder, a large event pipeline, an ad server — then the marginal cost of the second clock is low, because the people, the on-call rota, and the operational habits exist for other reasons. The condition is already employ, not could hire: headcount added specifically for the exchange belongs in the build’s price, not outside it.
Your auction logic is the differentiation. If your edge is the mechanism itself — a pricing model, an allocation strategy, auction behaviour a shared platform cannot express — then owning the auction code is owning the moat, and a vendor’s configurability will eventually be the ceiling you hit. Be precise about this one: differentiation in inventory, relationships, or margin structure is not auction-logic differentiation, and most of what operators call “our special auction” survives contact with a configurable floor-and-margin engine.
Your volume is past the crossover. Vendor pricing that scales with usage — per-request, or a share of cleared media — grows with your success, while the cost of headcount plus hardware is closer to a step function. At some volume the lines cross and building becomes the cheaper steady state. The crossover is real; whether you are past it is arithmetic against a real vendor quote and your own worksheet numbers, not a feeling.
You cannot accept a third party in the path. Some contracts, regulatory postures, or data-governance regimes rule out an outside platform touching the transaction or the bid-stream data at all. If that is your constraint, the economics are moot and the build is the price of the constraint.
When buying wins
The inverse conditions describe most operators who are asking the question. You would be hiring specifically to build and staff the exchange, so every category above is incremental headcount plus hiring risk. Your differentiation lives in supply relationships, demand access, and the margin you keep — things an exchange platform carries rather than competes with. Your volume is below the crossover, or you cannot yet know it, because you have no operating data. And no contract forbids infrastructure you do not own.
Buying also converts variance into a contract, which is worth something even when the expected costs are close. A build is an estimate with schedule risk and key-person risk attached; the categories in this article are exactly the places builds overrun, because they are the ones the plan did not price. A vendor fee is a number someone signed.
Honesty cuts both ways, though: buying is not free of the categories, it reassigns them. You still pay an integration effort to launch, you still own your commercial relationships and objectives, and you take on a new cost — vendor risk — that the build path does not have. That last one is a due-diligence problem, and our white label ad exchange guide is the checklist for it: the QPS and latency evidence to demand, the SLA language to require, and the red flags that should stop a conversation. There is also a legitimate sequenced path: operating on a platform first generates the seat counts, traffic shape, and discrepancy history that make a later build spec honest — most teams speccing a build from zero are guessing at every variable in this article.
The worksheet: price it with your own numbers
Every variable below is yours to supply; that is the point. Fill the build column from your own salaries and quotes, and the buy column from a real vendor conversation — not from a number an article invented, this one included.
| Category | Year-one (build) | Steady-state annual (build) | Buy path |
|---|---|---|---|
| Working auction | Team × months × loaded cost | Near zero — it stays built | Platform’s problem |
| Seat integrations | N seats × W weeks | New seats only | Reduced: platform adapters, your commercial work |
| Adapter maintenance | Small — nothing has drifted yet | N × T touches × D days | Platform’s problem |
| Infrastructure | Peak-sized compute + egress + log storage | Same, growing with volume | Inside the vendor fee |
| Settlement loop | Partial year | H × E, growing with partner count | Reduced: ledger and tooling from platform, decisions yours |
| Yield operations | Manual tuning from month one | Hours × cycles × endpoints, forever — plus the holdout harness if you want to know it worked | Platform’s problem: objective set per endpoint, proven against a live control |
| Monitoring and on-call | Telemetry build + rota | Rota, permanently | Platform’s problem for the infrastructure layer |
| Compliance | Implementation | Permanent slice of attention | Largely platform-carried; your registry stays accurate |
| Vendor fee | — | — | The quote you negotiate |
Two rules for reading the totals. First, compare steady states, not first years: year one flatters whichever side you already prefer (the build’s year one is all project energy and no drift; the buy path’s year one carries integration). The steady-state annual is the cost you pay forever, and it is where the decision lives. Second, run a three-year total as a cross-check, because it forces the build’s recurring categories — the ones quotes omit — to appear the same number of times as the vendor fee they are being compared against.
Key takeaways
| Point | Detail |
|---|---|
| Both published answers are scoped, not wrong | Agencies price the build they sell; vendors argue against a build estimate they supplied. Neither prices operations |
| The build is project-priced; the operation is staffing-priced | A working auction is weeks of engineering. The settlement loop is a fraction of a team, forever |
| Fan-out multiplies your infrastructure bill | Egress is traffic × seats. Shaping divides it back down — and shaping is ongoing operational work |
| Adapter maintenance scales with success | Every new seat is a protocol relationship. N × T × D per year, and N only grows |
| Log-level data is the cheapest thing you will ever build | With it, reconciliation is a query. Without it, an argument you lose |
| Building wins under four conditions | Engineers already employed, genuinely differentiated auction logic, volume past the crossover, or no third party allowed in the path |
| Yield tuning is a cost line | Floors, margins and shaping expire continuously; budget the hours, or the holdout harness that proves the hours worked |
| Decide on the steady state | Year-one totals flatter whichever side you prefer. Compare what each path costs every year, forever |
Buying the second clock: where Floxis fits
If the worksheet points you at buying, what you are actually buying is the second clock, and that is the standard to evaluate any platform against — ours included.
Floxis is a white-label RTB exchange you run as your own: your domain, your branding, your invoicing, with your margin applied per transaction at a rate you set. Against this article’s categories — the build is already done and speaks OpenRTB 2.5 and 2.6, Prebid, VAST and JS tags, with endpoints configurable from 1 to 100k+ QPS, a 200–300 ms DSP bid timeout, and live clusters in the US, EMEA and APAC. The adapter treadmill is carried for you: custom adapters for non-standard partners are built and maintained as part of the platform. The settlement loop reads from a log-level bid, win and drop ledger that lands in your reporting about a minute after the auction. The compliance surface — ads.txt with its own crawler, sellers.json, full schain validation with supply-path analysis, TCF and GPP passthrough — is built in, as is invalid-traffic and creative scanning you can bring your own key for or have Floxis run.
Before any of that, every request is enriched: geography resolved in real time down to country, region and city, and user sync run server-side and as pixel sync to lift match rates. This is the line that does not appear in a build quote at all, and it is the one that pays on traffic you already have — a buyer that can locate and recognise the user bids more often, and higher, on the identical impression.
The two categories this article says never close are the two that are automated.
Yield operations run as a closed loop. You set an objective per endpoint — net revenue, fill, or win volume — and the engine blocks, scores and floors every auction toward it. Floors are set per segment from that segment’s own observed clearing prices rather than a number somebody typed, and margin self-tunes within the minimum and maximum you set. Critically, it is measured rather than assumed: every lever runs off, then shadow, then enforce, against a live holdout that is the untouched status quo, and a safety breaker reverts enforcement the moment a test arm’s bid rate falls below 80% of that holdout. That last property is the one to press every vendor on, ours included — an optimizer that cannot tell you what it earned against a control is asking you to take uplift on faith.
The investigation loop has an assistant. Monitoring tells you something changed; working out what usually costs an afternoon across four differently-grouped reports. The Floxis AI assistant answers that question from your own log-level data — performance with elapsed-aligned period-over-period comparison, supply and demand partner health, competitiveness and timeout profiles, drop reasons, unmonetized and unauthorized inventory, and your live shaping and filtering configuration. It is read-only: it investigates and recommends, you make the change. Data-backed answers carry a deep link into the underlying report, so an answer is something you can open and check rather than something you trust.
The one number this article will not invent is the vendor fee — ours included, since inventing the other side’s numbers is exactly the failure the first section describes. Pricing is scoped against your traffic and margin structure in a demo, which is also the conversation that fills in the last column of the worksheet. Book a technical walkthrough, bring your QPS and seat numbers, and run the comparison on your own arithmetic.