I am Shashank Agarwal, the creator of API.market and founder and CEO of Noveum AI. Before either company, I built a personalized reading app called PipFeed.
The app did not become the business I hoped it would. But a service inside it turned out to be useful on its own.
That experience changed how I think about building products: a product can struggle while one of its components solves a problem people will pay to remove.
The useful component inside a difficult business
PipFeed needed to extract article content from web pages so the reading experience could work. That meant building infrastructure to turn messy pages into usable content.
After closing the mobile app, I continued with the parsing API. I described that pivot publicly in a November 2023 update.
There are two separate decisions in a pivot like this.
First, does the component have value beyond the original product? A parsing service might help a reading app, a research workflow, or a content-processing pipeline.
Second, can someone else use it without inheriting all the complexity of your application? That requires a clear interface, understandable inputs and outputs, documentation, and a way to pay.
The second question is where a useful internal service becomes an actual product.
An API needs a commercial workflow
Putting an endpoint on the internet is only part of selling an API.
A developer needs to discover it, decide whether it fits, understand the price, make an authenticated request, and inspect the result. A provider needs to publish the service, meter usage, manage access, and support customers.
The experience selling the PipFeed API pushed me toward these problems. I explain that origin in API.market's early About Us documentation.
I built API.market around the journey on both sides of the transaction. It is a marketplace for APIs and AI models, with discovery, access, provider publishing, metering, and billing.
For someone building an API product, I would start by writing down the first five minutes of a customer's experience:
- What problem brought them to the page?
- Can they see the required inputs and a realistic output?
- Can they understand how the service charges for usage?
- Can they make a request and inspect a failure?
- Do they know what to do next if the service fits?
A marketplace does not remove the need for a good API. It has to make the API easier to evaluate and use.
What AI agents change
The customer operating an API is increasingly an AI agent acting on a person's behalf.
That creates an additional interface problem. A human can read a pricing page, compare documentation, and reason about an error. An agent needs discoverable operations, usable schemas, authentication, and boundaries around paid actions.
API.market's MCP gateway is one way we connect compatible AI clients to the marketplace. The gateway gives the client a path to discover services and call operations.
Connecting a tool does not settle every decision. The underlying API still has its own behavior, limits, and pricing. An agent's ability to make a call should be considered separately from permission to incur a charge or take a consequential action.
An example: a workflow that extracts ten articles should establish which parser to use, what the calls cost, what counts as a valid extraction, and what to do when a page cannot be parsed. “The tool returned something” is a weak acceptance criterion.
Why this connects to Noveum
I worked on production machine learning at AWS and Amazon, including the original SageMaker launch team and later personalization work at Prime Video. That background made the operational side of AI familiar: a working model is one part of a working system.
At Noveum, the focus is production AI agents. Teams need to capture what happened, evaluate whether the behavior met the task's requirements, investigate failures, and review evidence for a change.
The connection to API.market is practical. One business helps developers and agents access tools. The other helps teams examine what agents actually do.
Consider an agent that extracts an article and summarizes it. A successful HTTP response does not establish that the extraction included the relevant section, that the summary is grounded, or that the workflow stayed within its budget. Those are different checks.
That distinction is useful even if you never use either product. Define the intended outcome before choosing the tools, and inspect the evidence before calling the workflow successful.
The lesson I keep coming back to
The path from PipFeed to API.market was not a straight line. It involved recognizing that the app and the service inside it had different customers and different business possibilities.
For builders, the useful question is concrete: which piece of your product already removes a recurring problem for someone else?
Then do the less visible work: make it understandable, accessible, measurable, and supportable.
I write about that work, production AI, and developer products on LinkedIn.
Disclosure: I founded Noveum AI and created API.market. The product examples above describe my own companies. They are not independent product reviews.
Top comments (0)