Adcontrol
Self-serve ad sales for publishers
-
2
This case study is a better sales page than your actual sales page. The line that sells AdControl is right here, in your customer's own words: building campaign creation, ad serving, reporting and billing in-house "just wasn't realistic." That is the enemy every publisher feels, and Somoim starting a real ad business without building any of it is the whole promise. Your H1, "Ad Monetization, From the First Step to Success," says none of that.
And you are underusing two facts from this story that would stop a publisher mid-scroll: ad-ops effort cut by more than half, and a first advertiser who has rebooked eight times in seven months because AdNote lets them rebook with zero coordination.
Put that on the homepage: run a real ad business without building the ad tech, and watch advertisers rebook themselves. Was the eight-rebooking Duo story the exception, or is that self-rebooking loop repeatable across your publishers?
-
1This is probably the best comment we've gotten on here. You basically rewrote our homepage in a few lines. You're right that the real hook is "building it in-house wasn't realistic," and that we've been leading with the outcome (success) instead of the pain. We're going to fix that. On your question, the 8x is still just one advertiser for now, so I won't oversell that exact number. But we run around 130 publishers in Korea at this point, and advertisers rebooking two or three times or more is pretty common across them. So the loop itself isn't a fluke. Duo is just the far end of it. And instead of guessing why it keeps happening, we actually asked. Duo told us it wasn't only about fit, though the targeting fit was real and the numbers held up. They said everywhere else booking is manual, so re-running a campaign means emails and back and forth. With us the system was already set up, so they just re-ran it themselves. A few times. Without even telling Somoim. So I think it's more about the system than about any one advertiser. The rebooking comes from the booking experience itself. Duo is just the first place we got to watch it go all the way, and it taught us that how an advertiser books is a big part of whether they come back. That's what we're building around now. And yeah, we're taking your homepage line. Thanks for this.
-
1
You've found something bigger than a homepage line, and I'd make sure you don't under-position it twice. "The rebooking comes from the booking experience itself, advertisers re-run without even telling the publisher" isn't a detail about Duo. It's a different and stronger identity for the whole product.
Here's the shift. Every ad platform sells the same thing to publishers: "monetize your audience." That's a one-sided promise, and it's what your "build without building" line already improved. But the self-rebooking loop means you're quietly two-sided: the publisher gets revenue that compounds with zero ops precisely because the advertiser gets a booking experience frictionless enough to self-serve. Most ad-tech makes the publisher do the reselling. You make the advertiser resell themselves. That's the actual moat, and it's more defensible than "we set up the system," because a competitor can copy your dashboard but not the fact that advertisers already have a no-friction habit loop running on your rails.
And it double-proves itself. Advertisers don't repeat things that don't work, so "they rebook unprompted" is simultaneously your proof of results and your growth mechanism, the same fact doing two jobs. Your instinct to not oversell the 8x is exactly right, and it makes the claim stronger, not weaker: "advertisers commonly rebook themselves across 130 publishers, no coordination" is more believable than one outlier and still stops a publisher mid-scroll.
So the homepage line evolves: not just "run an ad business without building the tech," but "run one where advertisers rebook themselves." When you rebuild around the booking experience, are you instrumenting the advertiser side, time-to-rebook, unprompted-rebook rate — as your core metric? Because if self-rebooking is the moat, that number is the one that tells you it's still working.
-
-
-
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
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
"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
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
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
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
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
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
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
Appreciate it. Just sent you a note.
-
-
-
-
Comment