4,200 SDK installs in 2 weeks: what worked, what didn't

We shipped the first version of the lulu-ads SDK in mid-July. As of July 28, the counters read: 4,231 installs across the last 30 days — 1,968 on PyPI, 2,263 on npm — with 3,641 of them in the last seven days. The curve is bending the right way.

Better than either number: our first two organic publishers signed up with zero outreach — a developer running a Prometheus MCP server and another running a web-search MCP. Nobody emailed them. They found the SDK, read the README, and signed up.

Small numbers by web standards. But this is a category that barely exists yet, so here's the honest breakdown — what produced those numbers, and the three expensive lessons hiding underneath them.

What worked

Same name, both registries. pip install lulu-ads and npm install lulu-ads — identical name, identical promise. Installs split nearly evenly between ecosystems, which means single-registry publishing would have roughly halved us. The boring move was the right one.

Keeping the one-line promise honest. We market "one line of code," so the line has to actually do everything. Early on it didn't — the data field was one line, but getting the rendered sponsored card needed two more manual steps, and we discovered our own server had it only half-wired. We collapsed it into a single call (enable_lulu_ads) that wires everything, present and future tools included. Every gap between the promise and the code is paid for in trust, multiplied by installs.

First-party servers as living proof. Our demo servers — a creative-scoring MCP and a flights MCP — are addable in one command and carry the SDK in production. A live server you can try in ten seconds converts better than any pitch page, and our first tracked conversions came through them. If you're building infrastructure, run something real on it where people can watch.

What didn't — the expensive lessons

We ran at 0% ad delivery in production and didn't know. The SDK had a tight per-call time budget built on a warm-connection assumption. Real hosts reconnect per message — so in production, nearly every call hit a cold connection, blew the budget, and quietly failed open. The ad was fetched, then discarded, on almost every single call. Our local tests passed the whole time, because local connections are always warm. The fix was detecting coldness per call instead of assuming it away — but the lesson is bigger than the bug: instrument your delivery rate from day one. Your local tests lie. (We wrote about the engineering budget itself — this was its hardest test yet.)

We put an API key in a URL. Briefly. Rebuilding our signup flow around magic links, the shortest path was to carry the freshly created API key through the emailed redirect. It shipped. It was caught the same day and torn out — keys are now created only in-session, shown once, never in any URL — but "briefly in production" is still in production. The lesson: the shortest path and the right path diverge exactly when you're tired, and secrets in URLs is the classic place they diverge.

"Monetize your server" converted worse than we hoped. Our lead pitch was money. Developers consistently cared about something else first: nobody is using my server. Growth is the felt pain; monetization is a means to it. So we inverted the whole pitch — grow first, and let the growth pay for itself — and rebuilt the funnel around that order. The numbers post you're reading is part of that shift.

What's next

Two things. First, the growth flywheel: "Promote your MCP" — letting publishers reinvest their 70% share into cross-promotion across the network, so a server's earnings buy its next users. Second, the written version of everything we've learned: How to grow your MCP server, and the free MCP Growth Kit — the playbook plus skills your agent can run.

We'll publish the next numbers when they're worth reading — including the ones that go the wrong way.