How We Made TinyFish Easier to Find on the Road to 300K Users

Four months to 100,000 users. Another 18 days to 200,000. Then 10 days to 300,000.

Those are the numbers people see. My part of the story starts with a spreadsheet.

When I joined TinyFish, the company was working toward an ambitious goal: 100,000 users by October. For Lily and me, part of the work was figuring out how people could discover TinyFish and understand what they could use it for.

We started by mapping our existing blogs and researching keywords. We looked at the questions people were asking, where our content had gaps, and which opportunities made sense for our products.

At the same time, we were identifying AI and MCP directories where TinyFish should have a presence. Someone exploring tools for their agent might encounter us there before ever visiting our website. We wanted them to find a useful explanation of who we were.

There was plenty to do. The spreadsheet was unlikely to suffer from neglect!

As we went deeper into the research, our questions became more specific. We still wanted to know where TinyFish was missing. But we also wanted to understand what happened when it did appear.

Which page was showing up? Was it answering the question someone had actually asked?

Finding a keyword was only the beginning

The early research helped us identify topics worth covering. It also brought us back to articles we already had.

A gap could suggest a new piece of content, but it could also mean an existing page needed a clearer explanation. Before adding another assignment, we needed to understand what the person searching was trying to do.

Someone searching for a web search API might want to understand its capabilities and start using it. Someone asking how agentic search works needs an explanation of the concept. Someone considering a production architecture needs enough detail to make a decision.

Those questions are related, but they don’t all belong on the same page. It would have been easy to turn every keyword into another blog idea. Research has a way of producing an impressive amount of homework.

The more useful question became: what kind of answer does this person need, and where should we put it?

The page behind the ranking mattered

One finding made that question especially concrete.

Our keyword map recorded a search for “web agent” appearing through a blog category page, while the intended owner was a TinyAgent product page.

TinyFish was appearing, which was useful. But someone arriving on a category page still had to browse through articles and assemble the answer themselves. The product page had a different responsibility: explain what the Agent could do and help them decide whether it suited their task.

That distinction changed how we looked at visibility. We began mapping keywords to individual products, separating those from questions better served by educational articles. Related phrases could strengthen one page instead of becoming several pages with overlapping purposes.

The map gave us a clearer way to discuss what each page should cover and where supporting content should point. It also identified recommendations for product copy and internal links that needed their own implementation work.

Completing the spreadsheet didn’t automatically update the website. An unfortunate limitation of spreadsheets. We hadn’t suddenly changed direction. We were becoming more precise about where to spend our time.

Sometimes the next useful article was already published

That thinking brought us back to existing content.

A guide can still be useful and have something missing. Products evolve, and readers arrive with different levels of experience. An explanation that works for someone building an integration may leave a first-time user unsure where to begin.

Our getting-started guide became a practical example. The article already explained how to build with TinyFish through code. When we did a refresh for the article, we added a no-code path for people trying TinyFish through their AI assistant.

Readers could try a task through the assistant, then continue into the API instructions when they needed to build something themselves.

The guide gained another front door!

We also added an AI-assistant section to the web-agent explainer and everyday tasks to the use-case article. These additions helped connect the product to something a reader might actually want done.

For me, this became an important part of prioritization. Before creating another page, it was worth asking whether we already had the right one and needed to make it more useful. An article being published didn’t mean we were finished with it. Sometimes it meant we finally had something concrete to improve.

Giving related articles different jobs

We applied the same thinking to groups of content.

Our Agentic Search tracker brought related pieces together, including a definition article, a RAG comparison and a production-architecture guide. The definition article introduced the concept. The comparison addressed a choice readers might be facing. The architecture guide went deeper into how a production system works.

Looking at those pieces together made it easier to see what we covered and where another explanation might be needed. It also helped us organize content around the products it supported. An educational article could explain the broader problem, while a product page explained TinyFish’s role in solving it.

Some of these articles were already published even before we had done the keyword research. The mapping helped us bring structure to work that was already developing, alongside identifying the next opportunities.

Every new keyword didn’t need a new page. Sometimes it needed a better home in one we already had.

Hitting publish created another to-do list

After the work that went into an article, we still needed to help it reach people beyond our blog.

That meant adapting it for Medium and LinkedIn. Each platform needed its own version, followed by another round of checking images and links. Sometimes the canonical tag, which identifies our blog as the original source, went missing too. We had an agency handling the republishing, but the process still involved plenty of back-and-forth QA. Copy, paste, fix, review. Repeat with the next article.

Lily built a badass workflow to handle the repetitive prep. She doesn’t come from a technical background, which made watching her build it herself even more impressive.

Every weekday morning, it checks our blog for new posts. TinyFetch extracts the article content, including images and links, and Claude prepares separate versions for Medium and LinkedIn.

The workflow checks numbers and links against the original article, flags unsupported details, and sends the drafts to Slack for review. Medium copies identify our blog as the original publisher. A person still reads, edits and hits publish. Having a draft ready is helpful. Giving it permission to publish itself is a different decision.

Our search-API benchmark article was one example of the handoff. Its content and images carried into a new draft, which reached the social team with the source attached and instructions for review.

It was satisfying to put our own product to work this way. We were spending our days explaining what TinyFish could do, and Lily used it to solve a problem that kept making those days longer.

Looking beyond our own website

Alongside our publishing and distribution, we continued looking at where TinyFish could appear elsewhere.

The directory work had started with a straightforward goal: establish an accurate presence in places where people were discovering AI tools and MCP servers.

Submitting a profile and getting it published were separate steps. Completing a form didn’t mean a listing was live. Once accepted, the information could still need updating as the product changed.

The tracker helped us keep those stages visible. GEO research added another question: when an AI assistant answered something relevant to TinyFish, which sources did it cite?

We examined those pages to understand the kinds of explanations being surfaced and where TinyFish’s presence was weak. That helped make our content and placement priorities more specific.

One opportunity was a third-party article covering web search tools for AI agents. The research identified it as a relevant inclusion target, and the team secured a placement through a reciprocal content arrangement.

That gave us a concrete connection between research and action. We had identified a relevant discovery surface and worked to get TinyFish represented there.

It also required care in how we interpreted the result. Being included on a page didn’t tell us how many people discovered TinyFish through it and a page being cited didn’t mean every answer citing it recommended us.

There was still more to learn after the placement went live.

Learning what progress actually looked like

Working across all these directories made us more careful about what each result could tell us. A ranking showed where a page appeared for a search. A citation showed that an answer used a source. A referred visit showed that someone reached our website.

Each answered a different question.

The same distinction applied to execution. A refresh marked as a priority was still a plan. A syndication draft still needed someone to publish it. A directory submission was still waiting until the listing was accepted.

Keeping those differences visible helped us understand what was done and what needed another follow-up.

It also gave us a more honest way to tell this story.

TinyFish reaching 300K was a company-wide milestone, built through months of work across the team. Our contribution was the ongoing effort to make TinyFish easier to discover and explain, wherever someone first encountered it.

When I started, I was looking for opportunities we were missing. Over time, I began asking more specific questions about the explanations we already had and how they reached people.

Who needs this article? What are they trying to understand? Where should they go next?

Those questions will keep guiding the work as TinyFish grows.

And yes, the spreadsheet is still open!!!