AdTechSep 17, 202611 min read

Your Own DSP, Ad Exchange or Ad Network: Build, License or Rent?

Build a DSPAd ExchangeBuild, License or RentWho Builds It
Error loading image

“We want our own DSP” can mean three businesses: a DSP that buys ad space for advertisers, an ad exchange that runs the auction where publishers sell it, or an ad network that resells space it has signed up. Rent a platform to test demand, license one when your business model is standard, and build a custom system when the bidding logic, the data or the margin is what your company sells.

When someone says “we want our own DSP”, they can mean one of three different businesses. A DSP, or demand-side platform, buys ad space automatically on behalf of advertisers. An ad exchange runs the auction where publishers and apps sell that space.

An ad network signs up publishers, packages their space and resells it to advertisers. A DSP, an ad exchange and an ad network share a vocabulary, but they need different software, different partners and a very different amount of work.

The short answer: first decide whether you are building a DSP that buys for advertisers, an ad exchange that runs the auction where publishers sell their space, or an ad network that resells space it has signed up. Then settle where your partners and traffic come from, what data you are allowed to use, and how money moves between everyone involved. Rent a platform to test demand, license one when your business model is standard, and build a custom system when the bidding logic, the data or the margin is what your company sells.

The first step toward your own DSP, ad exchange or ad network is not choosing a technology or a vendor. It is deciding which side of the auction you sit on, and what owning the software would give you that renting an account on someone else's platform does not. The budget, the timeline, the team and the right kind of builder all follow from that one decision.

What is the difference between a DSP, an ad exchange and an ad network?

Many ads bought automatically are sold in an auction that lasts a fraction of a second. Others are bought at a price agreed in advance, with no auction.

In a real-time ad auction, a website or an app sends out a request that says, in effect, “this space is available right now — who wants it, and at what price?” Buyers answer with bids, the exchange picks the winning bid, and the ad is shown. A DSP, an SSP, an ad exchange and an ad network each sit in a different place around that auction:

  • A DSP, or demand-side platform, works for advertisers and agencies. It receives requests for ad space, decides for each one whether it is worth buying and at what price, and sends a bid. Around that bidding engine sit campaign setup, budgets, targeting, the ads themselves and reporting for the people whose money is being spent
  • An SSP, or supply-side platform, works for publishers and apps. It offers their space to many buyers at once, applies the publisher's rules about prices and allowed ads, and pays the publisher. An ad exchange is the marketplace where that auction runs. The large SSPs run their own exchanges, so the two names are often used for the same system
  • An ad network is a business that signs up publishers, packages their space by audience or format, and sells it to advertisers. A small network can start with an ad server — the software that picks which ad to show — and deals agreed directly with advertisers. It can add real-time bidding, the split-second auction described above, later

Choosing between a DSP, an ad exchange and an ad network changes the whole project. A DSP spends advertisers' money, so its hardest problems are deciding what to bid and keeping budgets under control. An exchange stands between other companies' money and other companies' ad space, so its hardest problems are a fair, fast auction and paying everyone correctly. An ad network is a sales business first, and its software can grow step by step.

I want to build my own DSP. What would you suggest?

Start a DSP project with the reason for building one. Companies build their own DSP for a few reasons: they pay platform fees on a large ad budget, they need bidding logic or data that existing platforms do not allow, or they serve a niche — a channel, a region, a type of advertiser — that general platforms serve badly. If none of these is true, renting an account on an existing DSP is the sensible first step, and if a reason to build appears later, it will show up in your own numbers.

If you do have a reason to build your own DSP, write down what its first version must do for one real advertiser. A DSP can grow into a long list of features, and very few of them are needed on day one:

  • A bidder. The engine that receives requests for ad space, checks each one against live campaigns and answers with a bid before the exchange's deadline. The exchange sets that deadline, not you, and an answer that arrives late counts as no bid at all
  • Supply connections. Every exchange or SSP you buy from has its own technical specification, its own testing process and its own contract. One or two connections are enough to start
  • Campaign management. The screens where advertisers or your own team set budgets, targeting, schedules and the ads to show, and the logic that paces spending so a budget lasts the whole campaign instead of running out in the first hour
  • Reporting and billing. What was bought, at what price and with what result, in numbers close enough to your partners' numbers that you can invoice from them
  • Traffic quality and brand safety. Checks that reduce the risk of buying fake traffic or placing ads next to content your advertisers refuse. Specialised vendors sell these checks, so this part is often connected rather than built

Cut the first version of a DSP down to one channel — websites, mobile apps, connected TV or digital outdoor screens — and one or two supply partners. A DSP that buys one channel well gives you something to sell while the rest is still a plan.

We want to launch an ad exchange. Should we build it, license it or rent it?

There are three routes to a working ad exchange or DSP, and the right one depends on how much of your business lives in the software. Here is what each route gives you, what it takes away, and when it is the right call.

  • Rent: an account on an existing platform, or a white-label version its provider runs under your brand. You get: the fastest start, no servers to run, and a known fee, often a percentage of the ad spend that passes through. You give up: control over the auction and the bidding logic, part of your margin on every ad shown, and some control over your data. Right when: you are testing demand and the software is not what makes you different
  • License an existing ad exchange or ad server and run it yourself. You get: a working product with the standard features already built, and room to configure it. You give up: you follow the vendor's roadmap, licence fees often grow with the traffic you process, and connecting the product to your own data and billing is real work. Right when: your business model is standard for your market and your advantage is in sales, supply or service
  • Build a custom platform. You get: exactly the auction or bidding logic you want, your data in your own systems, no platform fee taken from every ad shown, and ownership of what your contract assigns to you. You give up: the cost and the time of building the first version, and the duty to run the system, pay for its servers and keep up with industry standards afterwards. Right when: the bidding logic, the data or the margin is your product, or an existing platform blocks something central to your business

Mixed answers to build, license or rent are common. An ad network rents an ad server to launch and builds its own once the rental fee starts to hurt. An exchange licenses reporting and billing and builds the auction itself, because the auction is where it has to behave differently from everyone else. Deciding component by component is often smarter than answering once for the whole ad tech project.

I want to build an ad network. Where do I start?

Start an ad network with its two sides, not with software: the publishers and apps that will give you their ad space, and the advertisers who will pay for it. The first question is where each side comes from, and why publishers and advertisers would work with you instead of an existing network or exchange.

The first version of ad network software can be modest: an ad server that decides which ad to show, a dashboard where publishers see what they earned, reporting for advertisers, and a way to pay everyone accurately. To sell to DSPs, the network either connects its ad space to an existing SSP or runs its own auction. To buy from exchanges, it needs a bidder, the same kind of software a DSP runs. Either way, the build gets bigger.

Before any code, decide how an ad network will check traffic quality. A network that pays publishers for fake traffic loses its advertisers, and adding those checks after launch is harder than designing them in from the start.

What has to be decided before anyone writes code?

Before anyone writes code for an ad platform, seven questions need written answers. None of them needs an engineering background to answer, and a company that starts building before it has the answers in writing is guessing with your budget.

  • Which side of the auction are you on? Buying for advertisers, selling for publishers, or both. Doing both at once raises conflict-of-interest questions your partners will ask, so decide it openly
  • Which channels and formats? Website banners, video, mobile apps, connected TV, digital outdoor screens, audio. Each channel has its own standards and its own buyers, and video on connected TV is a different build from banners on websites
  • Where do the partners come from? Name the exchanges, SSPs, DSPs, publishers or advertisers you already have agreements with, or are negotiating with. Every integration has its own specification, testing and contract, and agreements move on their own calendar
  • How much traffic, and how fast? The number of requests you receive, not the number of ads you win, decides how many servers you pay for. The auction deadline is set by your partners. Get both written down as expectations before design starts
  • What data may you use, and where? Which user data you collect or buy, what consent you need, and in which countries. Privacy laws decide what the system may store and pass on to partners. Confirm the specifics with a lawyer in each market before committing to a design
  • How does money move? Who pays whom, how invoices are produced, and how you settle the differences between your numbers and your partners' numbers
  • Who runs it after launch? Partners change their specifications, traffic patterns shift, and a bidding system needs someone watching it every day. Decide now whether that is your team, the builder under a support agreement, or someone you have not hired yet

Written answers to these seven questions are your brief. Handed to three different builders, they produce three proposals you can compare. Without them, you receive three sales presentations that cannot be compared at all.

How much does it cost to build a DSP or an ad exchange?

This article gives no prices. The same phrase — “our own DSP” — covers projects that differ many times over in size, and a number quoted before anyone has heard your answers to the seven questions above is a sales number, not an estimate.

What is useful is knowing which decisions move the price of an ad platform, because these are the levers you control:

  • Which product it is. A bidder that buys through one exchange, a full DSP with campaign tools for outside advertisers, and an exchange that runs auctions for other companies' money are three different sizes of project
  • How many integrations. Each exchange, SSP, DSP or data provider adds its own specification, testing and later changes. The second integration costs less than the first; the tenth still costs something
  • Traffic volume. Server and network costs grow with the requests you answer, including the auctions you lose. Filtering out requests you will never bid on is one of the first savings to design in
  • Channels and formats. Each new channel — video, mobile apps, connected TV, outdoor screens — brings its own standards, creative checks and reporting
  • Data and targeting. Your own audience data, bought data and matching users across devices each add storage, processing and privacy work
  • Reporting and billing. Invoices that advertisers and publishers accept need numbers that match your partners' numbers closely. This is a real part of the build, not paperwork at the end
  • Traffic quality and brand safety. Checks you build, vendors you connect, or both
  • Who runs it. The team that watches the system every day, and the support hours your partners expect

The cheapest lever on the price of an ad platform is scope. Cutting the first version to one channel, one or two partners and one way of buying or selling saves more money than most technical choices made afterwards.

Who builds custom ad tech software for publishers and advertisers?

Three kinds of suppliers answer when you say “we want our own DSP”, and they are easy to confuse because they use the same words. Platform vendors sell you accounts or licences on their own product. White-label providers run their platform for you under your brand.

Engineering companies build a system to your specification, and the contract decides how much of it becomes yours. All three kinds of ad tech supplier can help; ask each of them what you will own at the end.

If you want something custom built — a bidder, a DSP, an ad exchange or the auction side of an ad network — ask a supplier for these proofs before anything else:

  • A system they built that is live with real traffic, with the client named, or a clear reason why the client cannot be named
  • Who operates that system today, and what happens when a partner's traffic suddenly jumps or a connection breaks
  • A walk-through of something working: a campaign set up, a bid placed, a report produced. A live system tells you more than any slide
  • What they will hand over: the code, the build and deployment instructions, the documentation — and whether anything in the system stays theirs
  • How they handled a partner changing its specification or its auction deadline, with a specific case described
  • Who on their team has built bidding or auction systems before, and whether those people will work on your project or only appear in the proposal

Then listen to what the supplier asks you. A company that can build an ad platform will question your brief before it quotes:

  • Which exchanges, SSPs, DSPs or publishers you already work with, and what stage the agreements are at
  • Which channels and formats you start with
  • How much traffic you expect, and what auction deadlines your partners set
  • What data you have the right to use, and in which countries
  • How you will invoice, and what happens when your numbers and a partner's numbers disagree
  • Who will own and run the system a year after launch

A quick test you can use with any ad tech supplier: ask what they would leave out of the first version. A supplier who has thought about running the system will cut scope before adding features. A proposal that includes everything on day one has not counted what it costs to run.

Does amBrain build DSPs and ad exchanges?

amBrain is a software development company specializing in trading platforms, matching engines, real-time bidding systems, and casino platform engineering. amBrain has been building software since 2019.

In AdTech, amBrain works on DSP development, real-time bidding platforms, and ad exchange engineering.

amBrain built RTBBidder, a demand-side platform, for a client. This article explains how to choose; it is not a case study, and it gives no numbers about that platform.

amBrain works in 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 amBrain's reusable components.

If you are at the beginning of an ad tech project, the useful next step is not a vendor search. It is one page with your answers to seven questions: which side of the auction, which channels, which partners, how much traffic, what data, how money moves and who runs the system. Give the same page to every builder you talk to, and their proposals can be compared line by line.

Have a design like this on the table?

Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.

Related Articles

Error loading image
AdTech
Sep 11, 202610 min read

ML Inference Inside the Bid Request: Feature Fetch, Batching, and the Fallback Price

Read post
Error loading image
AdTech
Sep 10, 202610 min read

Go GC Pauses in an RTB Bidder: Mark Assist, Deadlines, and the Rust Decision

Read post
Error loading image
AdTech
Sep 10, 202610 min read

Ad Measurement Loses Events at Peak: Seams, Duplicate Keys, and the Bidder Join

Read post