amBrain

DSP development company: what gets built in a demand-side platform you own

Published Sep 23, 2026Facts checked: Sep 23, 2026

Short answer

A DSP development company builds the parts of a demand-side platform you would otherwise rent: a bidder that answers every exchange inside its deadline, the supply integrations, campaign management with budget pacing and frequency caps, and a reporting and billing pipeline whose numbers match your partners', with the code assigned to you by contract. Check four things: a DSP of theirs live with real traffic, per-exchange timeout rates stated as percentiles, how budgets stay consistent across regions, and a written list of what you receive at the end.

On this page

What does a DSP development company actually build?

A DSP is a bidder surrounded by the systems that decide what the bidder is allowed to spend. The question that comes first, DSP, ad exchange or ad network, and build, license or rent, is covered in your own DSP: build, license or rent. This page is about how the DSP itself is built.

Components of a demand-side platform and the hard part of each
ComponentJobThe hard part
BidderEvaluates each bid request against live campaigns and answers with a price or a no-bidThe deadline belongs to the exchange and includes the network
Supply adaptersMap each exchange's OpenRTB version and extensions into one internal modelEvery exchange has its own fields, tests and change schedule
Targeting indexFinds eligible campaigns for a request without scanning all of themUpdating the index while bidding continues
Budget pacingSpreads spend across a campaign's flightSeveral regions spending from one budget without overspending
Frequency cappingLimits impressions per userConsistent counts across regions and identity sources
Bid pricingSets the price for each impression, with or without a modelFirst-price auctions need a strategy for not overpaying
Campaign management and APIWhere advertisers set budgets, targeting, schedules and creativesRoles, approvals and an API that agencies automate against
Creative managementStores, checks and serves ad markupEach exchange's creative review rules
Event pipeline and reportingCounts wins, impressions, clicks and conversionsDuplicates, late events and joins back to the bid
BillingInvoices from billable eventsNumbers that match the exchange's numbers closely enough to invoice from
Traffic quality and consentFilters invalid traffic; applies consent signals per marketWhat the system may store and pass on

Which decisions shape a DSP build?

  • Deadline arithmetic. OpenRTB defines tmax as the "Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout"[1]. On Google's Authorized Buyers "The deadline typically ranges from 80 to 1000 ms", and Google states: "We require that 85 percent of responses be received within the deadline from the perspective of the trading location and will throttle bidders that cannot consistently achieve this"[2]. The internal budget is tmax minus the network round trip, set per exchange.
  • Where the bidder runs. Google lists its trading locations as Northern Virginia, the San Francisco Bay Area, Amsterdam and Singapore[2]. A bidder far from the exchange spends its budget on the wire, so regions follow supply.
  • Spend is counted on billing events. OpenRTB separates the two notices: "The win notice informs the bidder's pricing algorithms of a success, whereas the billing notice indicates that spend should actually be applied"[1]. Pacing that decrements budgets on wins overcounts spend; pacing on billing events has to live with their delay.
  • First-price auctions. The auction type field reads "1 = First Price, 2 = Second Price Plus"[1]. When an exchange runs a first-price auction, the bid is the price, so the pricing layer needs its own logic for not paying more than the impression is worth.
  • Fast no-bids. A no-bid can be "an empty response with HTTP 204"[1]. Filtering requests you will never buy, and answering them cheaply, is the first saving on servers.
  • The language of the hot path. A garbage-collected bidder pays for collection inside the auction window; whether to tune or rewrite is covered in Go GC pauses in an RTB bidder, and the bidder itself, step by step, on RTB bidder development.

How does a DSP build run?

Stages of a DSP build and the evidence each one produces
StageOutputEvidence it is done
1. BriefChannel, first exchanges, traffic volume, data rights, money flow, who runs itWritten answers the whole team signs off
2. Bidder and first adapterA bidder answering one exchange's test trafficCorrect responses against the exchange's specification tests
3. Load testRecorded or synthetic traffic sent at a fixed ratep99 and p99.9 inside the internal deadline per exchange
4. CertificationThe exchange approves the integrationLive traffic flowing, no-bids and bids counted
5. Low-budget periodReal bids with a small capped budgetWin and billing notices reconciled with the exchange's report
6. Campaign tools and pacingFirst advertiser running a full flightSpend on target by the end of the flight, within the agreed tolerance
7. ScaleMore exchanges, regions and channelsThe same tests passing per exchange and per region

What goes wrong in DSP builds?

  • Regional budgets that do not talk. Each region spending from its local view of a budget overshoots together; pacing needs a shared allocation and a reserve.
  • Reports that disagree with the exchange. The specification's best practice is that "Firing of the billing notice should be server-side and as 'close' as possible to where the exchange books revenue in order to minimize discrepancies between exchange and bidder"[1]. Build the reconciliation before the first invoice, not after the first dispute; see event integrity in ad measurement.
  • Bidding on everything. Requests you never win still cost servers and bandwidth; pre-filtering is a design feature, not an optimisation.
  • Load tests that wait for replies. A generator that stops sending during a stall hides the stall.
  • Models added without a latency budget. Inference in the bid path needs its own deadline and a fallback price; see ML inference inside the bid request.

Build or rent the DSP?

The rent side is well documented. The Trade Desk states: "We generate revenue by charging our clients a platform fee generally based on a percentage of our clients' total platform spend"[6]. Epom's white-label DSP Light plan costs "5% of your ad spend or $250 per month, whichever is higher" with "Up to 5 000 QPS", the Pro plan the same 5% or $2,000 a month, and the Enterprise plan is priced on request[3]; at $1 million of monthly spend, 5% is $50,000 a month.

Epom's terms state that "Epom is not granting Client any rights whatsoever in the Software source code" and that "all Account Data shall be erased from the Software within thirty (30) days of non-renewal or earlier termination"[4]. TeqBlaze publishes no white-label DSP price; its page says the price "depends on several factors, including platform configuration, infrastructure requirements, integrations, feature customization, and ongoing support needs"[5].

A DSP you own replaces the percentage with servers, bandwidth and a team, and the question becomes which of the two grows faster with your business. What a DSP costs sets out the drivers, white-label DSP vs own DSP puts the two side by side, and Epom alternative and The Trade Desk alternatives cover the rented options one by one.

What should you ask a DSP development company?

  1. 1.Which DSP or bidder of yours is live with real traffic, and who operates it today?
  2. 2.What are the per-exchange timeout rate and response-time percentiles, measured where?
  3. 3.How do budgets stay consistent across regions, and what is the worst overspend you have seen in a test?
  4. 4.How are win and billing notices reconciled with the exchange's numbers?
  5. 5.Which exchanges have you integrated and certified, and on which OpenRTB versions?
  6. 6.What do we own at the end: code, build and deployment scripts, runbooks? Does anything stay yours?

Who should not build a custom DSP?

  • Advertisers and agencies testing programmatic with a modest budget. A seat on an existing DSP costs less than a build.
  • Teams without supply agreements. A bidder with no exchange to bid on is idle; secure access first.
  • Publishers and networks selling direct campaigns. They need an ad server, not a DSP; see AdButler alternatives.

About amBrain

  • DSP development, real-time bidding platforms, and ad exchange engineering.
  • amBrain is a software development company specializing in trading platforms, matching engines, real-time bidding systems, and casino platform engineering.
  • amBrain builds ML inference inside the bidder: the model decides the bid within the auction window.
  • amBrain builds ad servers: targeting, frequency capping and reporting.
  • amBrain builds supply-side platforms (SSP) for publishers.
  • amBrain builds event analytics pipelines for ad tech: collection, processing and reporting of impression and click events.
  • amBrain takes over projects that stalled with another team and brings them to production.
  • Three formats: full delivery, a dedicated team, or engineers embedded in your team.
  • The client keeps full ownership of the product and the code, except our reusable components.

Related on this site: DSP case study.

Frequently asked questions

The bidder, the supply integrations, targeting, budget pacing and frequency capping, campaign management and its API, creative handling, the event pipeline, reporting and billing, and the operations around them.

Whoever the contract says. Ask for code, build and deployment instructions and documentation to be listed as deliverables. White-label terms differ: Epom's terms grant the client no rights in the software source code[4].

Yes, and it usually should. One channel and one or two exchanges give real traffic to test the bidder, pacing and reconciliation before more integrations multiply the work.

Inside each exchange's tmax, which includes network time[1]. Google's deadlines typically range from 80 to 1,000 ms; it requires 85 percent of responses inside the deadline and throttles bidders that cannot consistently achieve this[2].

It depends on traffic, exchanges, channels, campaign tools, data and operations. What a DSP costs explains each driver, next to the fees the rented platforms publish, and lists what a written quote has to contain so that three quotes can be compared.

Product and company names are trademarks of their respective owners and are used only to identify their products. No vendor named here reviewed or endorsed this page.

Sources

  1. [1]IAB Tech Lab, OpenRTB 2.6 specification (tmax, auction type, no-bid responses, win and billing notices). Specification · checked Sep 23, 2026
  2. [2]Google, Authorized Buyers Real-time Bidding: peer guide (deadline range, the 85 percent rule, trading locations). Official documentation · checked Sep 23, 2026
  3. [3]Epom, White Label DSP pricing (Light, Pro and Enterprise plans). Vendor's own page · checked Sep 23, 2026
  4. [4]Epom, Terms of Service (source code rights and erasure of account data). Vendor's published terms · checked Sep 23, 2026
  5. [5]TeqBlaze, White Label DSP (no published price; factors the vendor says set the price). Vendor's own page · checked Sep 23, 2026
  6. [6]The Trade Desk, Inc., Form 10-K for the fiscal year ended December 31, 2025 (platform fee model). Company filing · checked Sep 23, 2026

Related

Free project intro call, 30 minutes.

We reply within 24 hours.

Book a Call