For a publisher's own sites and apps, existing SSPs and Prebid Server are usually enough. Building one suits companies that sell space for other publishers.
An SSP, or supply-side platform, is the software that offers a publisher's ad space to many buyers at once and pays the publisher for what sells. A publisher that sells ad space only on its own sites or apps rarely needs to build one. It can sell through existing SSPs and run its own auction among them with Prebid Server, an open-source program. An SSP of your own makes sense when selling other publishers' ad space is your business. Even then, a rented SSP can be enough until your volume makes its fees too high or your publishers need something it cannot do. If you build, hire a firm that hands over the code and sets the SSP up under your company's domain and name.
The short answer: if you sell only your own ad space, start with existing SSPs and Prebid Server. If you sell space for many publishers, compare the cost of a rented SSP with the cost of running your own at the volume you expect. Whoever builds it, your company should own the code, the SSP's domain and the contracts with buyers.
A publisher's page or app sends an ad request each time it has space to fill. The SSP turns that request into bid requests for demand-side platforms (DSPs), the software advertisers use to buy ad space. It collects their bids, picks the winner and records the sale, so that it can pay the publisher later. The publisher sets rules in the SSP too, such as the lowest price it accepts, called a floor, and the kinds of ads it refuses.
Every auction has a deadline. IAB Tech Lab, a non-profit body that writes technical standards for digital advertising, publishes OpenRTB, a standard for bid requests. Version 2.6, read on 23 October 2026, defines the field tmax as the “Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout.” A bid that arrives later counts as no bid.
The SSP handles the money as well. It counts the ads that were shown and charges the buyers, then pays each publisher its share. When those counts disagree with a buyer's counts, someone has to find out why before the invoices go out.
Prebid Server can be enough for a publisher that sells only its own ad space, if the publisher's team or a hosting provider runs it. It is built for header bidding. In header bidding, a publisher asks several SSPs and ad exchanges for bids at once, before its ad server decides which ad to show. An ad exchange runs auctions for ad space much as an SSP does.
Prebid.org's overview page, read the same day, says: “Prebid Server is an open-source solution for server-to-server header bidding.” The page says there are “230+ server-side bid adapters”, ready-made connections to sources of bids such as SSPs and exchanges.
According to the same page, Prebid Server checks each incoming request, applies privacy rules and calls the bid adapters. Once they have answered, or “the timeout period has expired”, it sends its answer back to whatever sent the request, such as a web page or an app.
With Prebid Server, the publisher runs the auction among the SSPs and exchanges it works with, usually without contracts of its own with DSPs. Each SSP still pays the publisher for the ad space it sells, and most connections to DSPs stay with the SSPs.
The overview page describes two common scenarios: “Tech-savvy publishers” and “Managed service providers: for everyone else”. It says: “There are no configuration tools provided by the open source community.” It also warns that installing Prebid Server “is not nearly as easy as Prebid.js”, Prebid's header bidding code that runs in the visitor's browser.
The prebid-server code on GitHub, read the same day, is published under the Apache License 2.0, an open-source licence. It lets anyone use and change the code, including for business. A publisher can run it on its own servers or use a provider that hosts it. The overview page says hosted providers also “provide tools to manage stored requests”.
An SSP of your own fits a business that sells ad space for other publishers. Ad networks, app monetisation companies and groups of publishers that sell their space together are examples. For them, the auction and its fees are the product, and rented software limits changes to both.
Building can also make sense when a rented SSP charges for every request or every sale and your volume keeps growing. A third reason is an auction rule or ad format your publishers need that none of the rented products you have tried supports.
An SSP earns nothing until DSPs agree to receive its bid requests, and each DSP connection is a separate integration, test and contract. Before you build, write down which DSPs have agreed to connect to your SSP and which publishers will bring their ad space at launch.
Renting means the vendor runs the software and you use it under a contract, sometimes under your own brand. Epom, an ad server vendor, sells its SSP module as an extra to its ad server plans. Its pricing page, read the same day, starts the plans at $250 per month and prices the “SSP module” at “$0.001 per 1000 ext.reqs”. The module lets you “connect custom DSP endpoints”. Another extra, a “White-label solution” at $250 per month, lets you “Use your company's name, logo, and domain instead of default ones.”
A rented product with your brand on it still belongs to the vendor. The Epom Server Terms and Conditions, read the same day, state: “This Agreement does not constitute a sale and does not convey any rights of ownership in or to the Software.” The same terms say the client owns its “Account Data”, the usage information and traffic patterns from its use of the software, and that “all Account Data shall be erased from the Software within thirty (30) days of non-renewal or earlier termination”. Plan the export of your data before a contract ends.
Other vendors write their contracts differently, so read the ownership section before you compare prices. Per-request prices depend on what the vendor counts as a request, and Epom's page does not define “ext.reqs”. Ask for that definition in writing, and ask which domain your publishers will list as the seller of their ad space.
Buyers check where ad space comes from before they bid. A publisher lists every system allowed to sell its space in a file called ads.txt on its own website. Apps use a companion file, app-ads.txt. Version 1.1 of the ads.txt specification, read the same day, defines the first field of each line as “The canonical domain name of the SSP, Exchange, Header Wrapper, etc system that bidders connect to.”
The third field of an ads.txt line shows whether the publisher works with that system directly. The specification says “DIRECT” means the publisher “directly controls the account” named in the line. It adds that this “tends to mean a direct business contract between the Publisher and the advertising system”.
The SSP publishes a file called sellers.json, which names every seller whose ad space it sells. Version 1.0 of the sellers.json specification, dated July 2019 and read the same day, says: “Advertising systems should post the sellers.json file on their root domain and any subdomains as needed.”
The file has to list every seller: “All sellers must be included even if they are confidential.” Each seller ID stands for one company. In the words of the specification, “Every seller_id must map to only a single entity that is paid for inventory transacted with that seller_id.”
The SSP's domain can also appear in bid requests. OpenRTB 2.6 recommends a SupplyChain object in each bid request: a list of the companies involved in selling the ad space and paid along the way, which may be marked as incomplete. Its field asi is defined in the same words as the first field of an ads.txt line: the domain of the system that bidders connect to.
For ad space shown to people in the EU, there is one more framework to consider. IAB Europe, an advertising industry body, runs the Transparency and Consent Framework (TCF), which passes each person's privacy choices, such as consent, from the publisher's site or app to ad tech companies. IAB Europe calls the TCF “a voluntary standard”. Its page for vendors, read the same day, says vendors “can be Ad servers, measurement providers, advertising agencies, DSPs, SSPs, and more”. The page adds: “Vendors must register to participate in the TCF.”
Every file and registration above names a domain or a company. Check that each item below ends up with your company:
The domain is usually the hardest item to change later. A new domain means a new line in every publisher's ads.txt file. Until a publisher adds that line, buyers who check ads.txt may treat sales of its space through your SSP as unauthorised.
Ask the builder to name every part of its own code or third-party code that stays outside your ownership, with the licence for each part. Open-source code inside the SSP, such as Prebid Server, keeps its own licence. The article on checking a dedicated team and keeping the code yours covers contract wording in general.
General checks for any ad tech supplier are in the article on building, licensing or renting a DSP or ad exchange. Building an SSP raises six more questions:
A firm that has run an SSP can answer most of these by showing files, logs and reports. If a confidentiality agreement keeps a client's name private, ask the firm to arrange a call with that client instead.
Spend the most time on the counting questions, because publishers are paid from the SSP's numbers. The article on why ad reports don't match bidder logs explains where two sets of counts drift apart.
Building starts with a one-off cost for the first version: the auction, connections to publishers and DSPs, the files above, reporting and payouts. After launch, the running costs cover servers, network traffic, monitoring, the people on call and fees such as the annual TCF vendor fee.
An SSP's network traffic grows with the number of DSPs as well as the number of ad requests. For each ad request, the SSP sends a separate bid request to every DSP it invites, so each new DSP adds requests, traffic and servers.
Renting turns most of those costs into the vendor's fees, such as Epom's plan fee and its price per 1,000 “ext.reqs”. Compare both options at the volume you expect in two years. Count the cost of leaving too, such as new ads.txt lines at every publisher if the domain belongs to the vendor.
amBrain's list of services includes this line: “amBrain builds supply-side platforms (SSP) for publishers.” In AdTech, amBrain also works on DSP development, real-time bidding platforms, and ad exchange engineering. RTBBidder is a demand-side platform amBrain built for a client.
amBrain has been building software since 2019. It works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” If amBrain is on your shortlist, ask it the same questions as any other firm, including which reusable components it means.
This article is not a case study and describes no client work. RTBBidder is named only as a DSP amBrain built, and the article gives no figures about it.
Prebid.org, IAB Tech Lab, IAB Europe and Epom appear as examples from their own pages, and the article claims no relationship between amBrain and any of them. It gives no amBrain prices or timelines. It is not legal advice either: consent and data rules differ by country, so check them with a lawyer.
Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.
Book a Call