We started this project on August 30. In those 25 days, 744 new accounts were created on BeatAPI (https://beatapi.io), and we'd made a little over $900 in revenue.
I wish I could say, "This channel brought us exactly this many customers." I can't. Our attribution isn't good enough, and a signup is not the same as someone getting value from the API. But I can share what we actually spent our time doing, why we chose it, and what I'd change.
It all started with a video task of my own
Before any of this, I had a task: make a batch of AI videos. My first instinct was the obvious one — sign up for a few generation APIs and wire them together myself. That got messy fast. Every provider had its own account, its own request shape, its own way of returning a result. I'm not a professional AIGC creator, and I didn't want to click through a different tool's UI for every image and every clip.
What I actually wanted was to point an agent at the whole job and let MCP handle the connections, instead of me doing it by hand. So I built BeatDesign first: an open-source project (https://github.com/BeatAPI/BeatDesign), local-first — a canvas, a timeline, and a place for your assets in one project — where any MCP-capable agent I already used, Codex or Claude Code or Cursor, could drive that same project instead of me operating a separate app.
Once BeatDesign existed, it needed image and video model APIs behind it to actually generate anything. Wiring those in was the direct ancestor of BeatAPI. But it also showed me something: image and video generation was one pain point, not the whole problem. I still wanted to test different models against each other, still needed data my agent couldn't get from a model alone, and still didn't want to be locked into whichever single agent host I happened to be running that day. BeatAPI grew out of trying to fix that more general version of the same problem — one account, one key, reachable from whatever agent I'm using, for the capabilities behind it.
That's also where our approach to growth comes from. I started by writing down my own pain points as I hit them, in the same rough shape as everything below: what happened, what I tried, what didn't work. Turning that into a habit — checking whether other people had the same problem, not just assuming they did — is what led to the research described in the next section.
We didn't start from a content calendar. We started from a pain-point library.
BeatAPI's Social Data API already covers both X and Reddit, so one of the first things we did was point it at the same job. Using our own API, we had an agent search X for "AI," "AI agent," and "AI model" within a 24-hour window. Three searches returned 60 posts. After removing a duplicate and checking timestamps, 21 were actually inside the window. The agent grouped them into five themes, and we could inspect the source posts behind the brief instead of taking a summary on faith. That's a small sample from one platform, not a map of demand — and the Reddit side of that same catalog hasn't had a comparable pass run through it yet, so I'm not going to describe it as done.
That first-party pull became one input into a broader list we've been building: real complaints, not guesses. We ran research passes over Reddit and X threads about AI agents, model APIs, and content tooling, then merged everything into a working spreadsheet — the original post or comment, the subreddit or account, a link back to the source, and our read on how strong the evidence was. Weak or unverifiable entries got marked as such instead of dropped quietly, and cases that only applied to a narrow user type stayed noted as narrow.
That list is still messy and still growing, and most of it hasn't turned into anything published yet. Its job isn't to prove demand — a forum complaint is not a purchase — but it does keep us from writing about a problem we invented in a planning doc. When a page or a post claims someone struggles with X, we want a real thread behind that claim, not a hypothetical persona, and not just my own experience generalized to everyone.
We started with a question someone already had
When you're building an API product, it is tempting to write about your architecture. We did some of that too. But a developer looking for an API usually has a much narrower problem: Will this model do the job? What will the same request cost? How painful is it to switch providers?
That changed the pages we worked on. Instead of writing another broad "best AI APIs" post, we built model guides, same-spec provider comparisons, and a cost calculator (https://beatapi.io/ai-api-cost-calculator). Take a developer comparing video APIs. The advertised price per second isn't enough: they need to know which resolution and duration it covers, whether the request creates an asynchronous task, and how they'll retrieve the result. We wrote a provider comparison around those questions, including the cases where the other provider may be a better fit.
The commercial reason to try BeatAPI is straightforward: find a lower verified price for the same model and specification, then run a real request. The article or calculator should help someone make that decision even if they don't sign up. If it only works as an ad, it's probably a bad answer to the question.
This is our SEO approach: start with a decision a developer is already trying to make, build the most useful answer we can, and give them a sensible next step. We have published those pages. I can't yet tell you how many of the 744 signups each page produced.
We checked what an AI assistant would find
Search results aren't the only way people find an answer anymore. We also tested questions as a user might ask an AI assistant: which provider fits this workflow, how do the prices compare at the same settings, and what does integration involve?
We looked at the assistant's research path. Which pages did it open? What did it cite? Where did it fall back on a vague claim because the source lacked a price unit, a model ID, or an example request? That gave us a practical editing list for our pages, docs, and comparisons.
I wouldn't call this "we cracked AEO." We haven't proved that an assistant recommendation led to a paying customer. What the exercise did was expose weak answers that a human visitor would also have trouble trusting. Adding the missing evidence helped the page stand on its own.
From one verified pain point to several platforms
Once a pain point clears our bar — a real thread, or a first-party result we can show — we don't write it once and stop. The same underlying evidence usually supports more than one piece: a short reply where the conversation is already happening, a longer guide where someone is actively comparing options, and occasionally a founder-voice piece like this one where the context matters as much as the fact.
We rewrite each version instead of copy-pasting it, because a reply on X and a guide someone lands on from search are answering different amounts of the question. But we don't re-derive the underlying evidence each time — the same verified thread, price table, or first-party result gets reused, so the claim doesn't drift between platforms. I'm not going to walk through a specific case here; most of what's in the pipeline right now is still drafted, not published, and I'd rather point to real links once they're live than describe pieces that might still change.
What the numbers do and don't say
The 744 signups are encouraging. But of those accounts, 284 have a billed API usage record, and 33 have topped up. Those numbers point to the next problem: getting someone from curiosity to a useful first call, and from that first call to a reason to return.
I can't honestly divide the signups into "SEO users," "AEO users," and "X reply users" yet. We need better attribution, and I want to hear from people who stopped after signing up. Was the model missing? Was the price comparison unclear? Did the docs or first key get in the way? More posts won't fix an answer or an onboarding step that fails at the moment of use.
So the growth loop we're trying to build is simple: find a real pain point — starting with my own, then verifying it against other people's — answer it with evidence, join the relevant discussion, and watch whether someone can actually complete the task. The next 25 days should tell us which parts of that loop are working and which parts just look busy.
If you've grown a developer product without a big audience, which specific questions or conversations brought you your first serious users? And how did you learn that they came back for a second task, rather than just signing up?
Top comments (0)