Services
DSP development company: what gets built in a demand-side platform you own
Updated Sep 25, 2026
Facts 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
Which parts of a DSP does a development company 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.
| Component | Job | The hard part |
|---|---|---|
| Bidder | Evaluates each bid request against live campaigns and answers with a price or a no-bid | The deadline belongs to the exchange and includes the network |
| Supply adapters | Map each exchange's OpenRTB version and extensions into one internal model | Every exchange has its own fields, tests and change schedule |
| Targeting index | Finds eligible campaigns for a request without scanning all of them | Updating the index while bidding continues |
| Budget pacing | Spreads spend across a campaign's flight | Several regions spending from one budget without overspending |
| Frequency capping | Limits impressions per user | Consistent counts across regions and identity sources |
| Bid pricing | Sets the price for each impression, with or without a model | First-price auctions need a strategy for not overpaying |
| Campaign management and API | Where advertisers set budgets, targeting, schedules and creatives | Roles, approvals and an API that agencies automate against |
| Creative management | Stores, checks and serves ad markup | Each exchange's creative review rules |
| Event pipeline and reporting | Counts wins, impressions, clicks and conversions | Duplicates, late events and joins back to the bid |
| Billing | Invoices from billable events | Numbers that match the exchange's numbers closely enough to invoice from |
| Traffic quality and consent | Filters invalid traffic; applies consent signals per market | What the system may store and pass on |
Which decisions shape a DSP build?
- Deadline arithmetic.OpenRTB defines
tmaxas 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 istmaxminus 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?
| Stage | Output | Evidence it is done |
|---|---|---|
| 1. Brief | Channel, first exchanges, traffic volume, data rights, money flow, who runs it | Written answers the whole team signs off |
| 2. Bidder and first adapter | A bidder answering one exchange's test traffic | Correct responses against the exchange's specification tests |
| 3. Load test | Recorded or synthetic traffic sent at a fixed rate | p99 and p99.9 inside the internal deadline per exchange |
| 4. Certification | The exchange approves the integration | Live traffic flowing, no-bids and bids counted |
| 5. Low-budget period | Real bids with a small capped budget | Win and billing notices reconciled with the exchange's report |
| 6. Campaign tools and pacing | First advertiser running a full flight | Spend on target by the end of the flight, within the agreed tolerance |
| 7. Scale | More exchanges, regions and channels | The 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?
- Which DSP or bidder of yours is live with real traffic, and who operates it today?
- What are the per-exchange timeout rate and response-time percentiles, measured where?
- How do budgets stay consistent across regions, and what is the worst overspend you have seen in a test?
- How are win and billing notices reconciled with the exchange's numbers?
- Which exchanges have you integrated and certified, and on which OpenRTB versions?
- 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 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.
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]IAB Tech Lab, OpenRTB 2.6 specification (tmax, auction type, no-bid responses, win and billing notices). Specification · checked Sep 23, 2026
- [2]Google, Authorized Buyers Real-time Bidding: peer guide (deadline range, the 85 percent rule, trading locations). Official documentation · checked Sep 23, 2026
- [3]Epom, White Label DSP pricing (Light, Pro and Enterprise plans). Vendor's own page · checked Sep 23, 2026
- [4]Epom, Terms of Service (source code rights and erasure of account data). Vendor's published terms · checked Sep 23, 2026
- [5]TeqBlaze, White Label DSP (no published price; factors the vendor says set the price). Vendor's own page · checked Sep 23, 2026
- [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
Building this system with an outside team?
Send us what you have: a design, a vendor quote or a list of requirements.
Free project intro call, 30 minutes.
We reply within 24 hours.