3
10 Comments

[Founder Notes #1] Advertisers Were Already There. Publishers Just Couldn't Catch Them.

Over the last few years, we spoke with dozens of publishers — care services, communities, commerce apps, content platforms. The businesses looked different. The moment they got stuck looked almost identical.

Whenever we met a publisher about to start selling ads, we kept seeing the same scene. An ad inquiry lands in the inbox. It should be good news — someone wants to pay to advertise on your service. But the person stares at the reply and hesitates. "What price do I quote? Which placement can I sell? Where do I collect the creative, how do I block off the schedule? Who handles the report and the settlement when it's over?"

Traffic, loyal users, even advertisers showing up on their own — and still, starting an ad business was the hard part. This is the story of how our team kept watching that, and slowly defined the real problem.

At first, we thought it was "they can't find advertisers"

Honestly, we were confident about that assumption. If publishers weren't making money from ads, the obvious explanation was that they couldn't find advertisers. So we spent months thinking about distribution, demand, and sales.

We were solving the wrong problem.

Because when we actually talked to them, advertisers were often the ones reaching out first. One care-services publisher told us inquiries came in steadily. The problem was what came next: there was no way to turn them into campaigns.

To run a single ad properly, you need more than you'd think — an ad server to deliver it, inventory to sell, measurement to confirm it's running, and reporting to show the results. Without that bundle, an inquiry simply can't be answered. That's why the reply got stuck.

"So just build it, right?"

We asked the same thing. But building it was the first wall.

Ads are unfamiliar territory for most product teams. Someone from the business side has to sit in early and explain how ads are actually sold, booked, delivered, and reported. At one publisher, just aligning on that took several people a few weeks. And it's expensive: in several conversations, teams described the in-house path as a year-long project with a six-figure cost — before maintenance even began. Outsourcing didn't fully solve it either. The upfront cost was still high, and every market change raised the same question: who maintains this?

Even if you build it, that's not the end

Even at teams that managed to build it, the real work started after.

Quoting advertisers, prepping campaigns, contracts, collecting and uploading creatives, swapping creatives mid-flight, talking after the campaign ends. One team said a single campaign meant 60–100 emails back and forth. In between, creative versions drift, schedules slip, and one small mistake turns into a trust problem with the advertiser. At one high-traffic service, a single person was effectively running ad ops and managing every creative by hand. Another team told us, "the more tools we added, the more complicated ops got."

The longer we watched, the clearer it got: selling ads isn't selling a placement. It's running a system, operations, and sales — all at once.

And even then, the math was uncomfortable. Direct ads needed ops time, sometimes sales time, and constant coordination — but revenue came in unevenly. So teams kept postponing it. Not because demand was missing, but because they weren't set up to catch it.

Everyone lands on the same answer

Facing all of this, most publishers reach the same conclusion: just plug in network ads — AdMob, AdSense. One line of code and you're live.

But that convenience has a cost. For many of the publishers we met, network ads meant low CPMs, limited control over pricing and placement, thin reporting, and very little say over how an ad affected the user experience. They'd love to sell premium direct deals, but they don't have the system to receive them — so they stay on low rates and compromised UX. A lot of them were there not by choice, but because there was no other way.

Here's the problem we defined

Step back, and the real problem comes into focus.

Every service was rebuilding the same thing — an ad-product management screen, a booking flow, reports, a settlement process. Different industries, different sizes, the same problem underneath. Everyone was carving the same wheel, each in a slightly different shape, and paying dearly to do it.

So we flipped the question: instead of re-carving that wheel every time, what if we standardized that layer once, for everyone?

Looking back, the answer feels obvious. At the time, it wasn't. For months, we thought the challenge was demand. It turned out demand was already there. The real challenge was everything that happened after someone said, "We want to buy an ad."

That realization became the starting point for Ad Control — the system publishers needed after demand showed up.

Next time

How we actually started solving it — what we focused on first, what the first version looked like, and the first "oh, this could work" moment. More in the next note.

posted toAvatar for product Adcontrol
Adcontrol
  1. 2

    "That's why the reply got stuck" is doing a lot of work in this paragraph and I want to highlight it because most people miss it.

    Most teams blame the salesperson or the customer when things go quiet. Almost always, what's actually happening is that one side is waiting on something from the other and neither side has visibility into what the other needs to move. The reply didn't get stuck because of bad intent. It got stuck because nobody was tracking what "ready to reply" actually required.

    This is the same pattern I keep seeing in knowledge work: a founder says "I'll get back to you Tuesday" and on Tuesday they've forgotten what they were going to say. The signal of "I owe a reply" got buried under 15 other things. The owning party doesn't even know they're blocking.

    Curious whether your eventual "tracking who owes what to whom" product would surface the missing inputs explicitly (e.g., "you can't reply until X and Y are confirmed") or just send a reminder. The first one seems more useful but harder to build.

    1. 1

      I think that's exactly what we slowly realized.

      At first we looked at it like a communication problem — someone forgot to reply, someone was waiting on someone else, and things stalled.

      But the more publishers we spoke with, the more it felt like a system problem. In many cases, there wasn't even a clear definition of what "ready to reply" meant. Pricing wasn't standardized. Inventory wasn't organized. There was no booking flow, no approval flow, no reporting process.

      So rather than building a layer that reminds people to respond, we ended up focusing on standardizing the things that need to exist before a response is even possible.

      Looking back, that's probably why the problem was so easy to misdiagnose. What looked like a communication failure was often missing infrastructure underneath.

      1. 1

        "Missing infrastructure underneath" is the sharper way to say what I was circling. That's the same distinction your readers will eventually need to internalize: the question isn't "did I forget to reply" but "did the system ever make reply possible."

        For knowledge work, the infrastructure is messier than yours because the inputs aren't standardized — email is a stream, calls are scattered, voice notes are scattered more. The thing I'm building (What Next) tries to be the standardization layer for "what does the conversation actually need before this thread can move." So your comment lands almost exactly where I'm trying to land.

        The two-product thing you described — "we could have built reminders, but instead we built the inputs the reminder would have relied on" — is a pattern I think is undervalued. Most products in our space skip straight to the reminder and wonder why adoption stalls. You've described the discipline I'd want to design for.

        Genuinely curious whether you and I are working on adjacent versions of the same problem, and I'd love to discuss further via email if possible. What you'd get out of it: a sanity check on whether the knowledge-work version of your "missing infrastructure" insight holds up against what you've learned in publishing. What I'd get out of it: a real-world case study of what happens when you skip the reminder layer and build the inputs instead.

        If you're up for it, drop your email here and I am sure we can help one another.

        1. 1

          I think that's a really interesting way to frame it.

          What stood out to me is that both of us seem to have started from symptoms and gradually worked backwards to the underlying infrastructure problem. The domains are obviously different, but the pattern feels surprisingly similar.

          I enjoyed the discussion and you've definitely given me a few things to think about regarding how these problems show up outside of publishing.

          Looking forward to seeing where you take What Next.

          1. 1

            Thanks — this conversation genuinely sharpened how I think about the "build the inputs first" discipline. "Symptoms working backwards to underlying infrastructure" is a phrase I want to steal.

            Best of luck with the rest of the Founder Notes series. I'll be reading.

  2. 2

    What I found interesting wasn't the shift itself.

    It was how long the original explanation remained believable.

    In situations like that, I'm always curious which assumptions became easier to see only after you stopped treating the first diagnosis as true.

    1. 1

      That's a great question.

      Looking back, the biggest hidden assumption was that ad revenue starts with demand.

      Once we stopped treating "they can't find advertisers" as the answer, we started noticing how often demand was already showing up on its own.

      The conversations changed. Instead of asking "How do we bring advertisers to publishers?", we started asking "What happens after an advertiser reaches out?"

      That's when all the operational gaps became visible — pricing, inventory management, booking, reporting, settlement, and everything required to turn interest into a campaign.

      The demand problem was easy to see because it sits at the front of the funnel. The system problem was harder to see because it only appears after someone actually wants to buy.

      1. 1

        That's actually the part I'd be most curious about.

        Reading your reply, I found myself wondering whether the difficult lesson was discovering the system problem or deciding the demand problem no longer deserved to sit at the center of the explanation.

        Those can sound similar, but they don't always lead to the same conclusion.

        I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.

        What's the best email to reach you on?

        1. 1

          Thanks for the thoughtful read. I think you're right that those two lessons are related, but not quite the same.

          Happy to continue the conversation. If you'd like to discuss Ad Control or our product in more detail, please reach out at contact@adrop.io and mention that you found us through our Indie Hackers post.

          Would be glad to hear your thoughts.

          1. 1

            Appreciate it. Just sent you a note.