DEV Community

Eric Kang
Eric Kang

Posted on

How We Built a Growth System Around an AI API—Before Finding Product-Market Fit

In 10 days, BeatAPI reached 400+ signups and about $150 in revenue.

For our three-person team, the numbers were encouraging—but the more useful lesson was what happened behind them. AI has made software easier to build. It has not made distribution easy.

I am a developer, and I currently handle most of our growth. We are building BeatAPI: the professional capability layer for general agents, or, more simply, an “OpenRouter for Agents.” It gives agents one place to access AI models, Social Data, and MCP tools.

At first, I made a list of channels: SEO, X, developer communities, open source, directories, influencers, and UGC. The list kept growing, but it did not tell us what to do next.

The useful change was to stop treating channels as a checklist and give each one a job.

1. Search captures existing demand

We start with questions developers already ask: Which API fits this workflow? How much will the same model and specification cost? How should an agent handle a long-running task?

That leads to competitor pages for switching intent, free tools such as an API cost calculator for concrete decisions, and technical pages that answer one production question with verifiable evidence.

AEO adds a second feedback loop. More developers now begin with an AI assistant, so we ask the same questions from the user’s point of view and inspect the observable research path: which searches the assistant runs, which pages it opens, what it cites, and what evidence is missing.

If the answer lacks a matched comparison, we build one. If it needs structured data, we create a table or calculator. If the assistant relies on documentation, GitHub, or developer communities, we make sure our evidence exists there—not only on our own blog.

Ask like a user → inspect the sources → find the missing evidence → rebuild the content → distribute it where AI research happens

Our research workflow is itself agentic. Firecrawl collects web sources and Codex coordinates the process. Through BeatAPI, we assign different models to different stages: a Claude-family model for long-form drafting, GPT-6 Astra for overall planning, DeepSeek for repeatable execution, and GPT-5.6 Sol for editorial QA.

The models produce options. Our standards decide what gets published.

2. Social Data reveals live demand

Search tells us what people look for. Social Data shows how they describe the problem right now.

Every day, we use BeatAPI’s Social Data API to inspect X timelines, trends, post activity, and surrounding conversations. We shortlist discussions that are relevant and gaining attention.

The API does not automatically publish replies. We read the original post and respond only when we can add something specific: an implementation detail, a production constraint, a cost trade-off, or a useful example.

When interest around GPT-6 Astra and 3D workflows rose, we connected relevant conversations to source-linked examples for Blender, Three.js, WebGL, games, and AI-assisted CAD. With MiniMax H3, we focused on practical observations around typography, UI motion, product shots, and natural-language editing.

Replies reveal questions. Short posts test ideas. Long-form articles turn the strongest ideas into complete arguments.

3. Developer stories turn work into proof

Developers do not buy another endpoint. They buy a completed task, lower cost, a more reliable workflow, or fewer integrations to maintain.

Our daily work already produces useful stories: Why did we choose asynchronous tasks? What happens when a provider fails? Why do we use different models for planning, execution, writing, and QA? Which product assumption turned out to be wrong?

One factual source can become an X post, a LinkedIn story, a DEV article, or a deeper engineering write-up. BeatAPI appears naturally because it is the product being built, used, and corrected—not a promotion pasted onto the end.

4. Open source makes the work verifiable

We do not create repositories only because GitHub is a distribution channel. We open-source workflows we actually use.

BeatDesign is our local-first, open-source workspace for AI image and video creation. It connects a Canvas, shared Assets, a video Editor, and MCP access inside one Project.

We use it for real visual workflows, including TikTok-style UGC videos: develop the idea on the Canvas, generate variations through BeatAPI, move useful outputs into Assets, and finish the sequence on the timeline.

Opening the workflow lets the community inspect it, run it, extend it, and tell us what is missing. It also makes BeatDesign our Customer Zero: a real environment for testing BeatAPI inside an agent-driven creative workflow.

The funnel matters more than the channel list

A GitHub star is not a signup. A signup is not an API key. An API key is not a successful task.

The path we now measure is:

Real question → useful asset → relevant visitor → signup → API key → successful task → repeated use → revenue

Search captures existing intent. Social Data reveals live demand. Developer stories turn work into evidence. Open source lets people verify and extend it.

We still do not know which loop will compound fastest. That is precisely why I am documenting the system now—while the decisions are still uncertain and the lessons are still real.

BeatAPI: https://beatapi.io/

Open-source work: https://github.com/BeatAPI

Top comments (0)