I recently built my first proper API product, and now I’m at the part that feels harder than writing the code:
figuring out if people actually need it.
The product is called FastBusiness API.
It started from a problem I kept running into while building other projects. I would need basic company information for an app, dashboard, directory, or internal tool, but getting that information was always more manual than it should have been.
A business name alone is rarely enough.
Usually I would end up searching across company websites, public registers, directories, search results, LinkedIn pages, finance sites, and other sources just to piece together a useful business profile.
Then I would still need to clean it, structure it, decide what was trustworthy, and turn it into something the app could actually use.
After hitting that same problem enough times, I decided to turn the workflow into an API.
The idea is simple:
send a business name, and get back a structured business profile.
The response can include things like:
- website
- industry
- sector
- headquarters
- business type
- country
- ABN/ACN where available
- stock ticker where available
- short description
- confidence score
- source links
The main use cases I had in mind were CRMs, lead enrichment tools, business directories, internal dashboards, sales tools, vendor/customer research, due diligence workflows, and products that need company context without building their own research pipeline.
Building the backend was one challenge.
Turning it into a real product was another.
I had to think through things like API key authentication, usage limits, subscriptions, Stripe billing, documentation, dashboard pages, request costs, error handling, profile generation, refreshing stale data, and making sure the output stayed predictable enough for developers to trust.
That part taught me a lot.
When you are building an API product, the product is not just the endpoint.
The product is also:
- the docs
- the response structure
- the error messages
- the auth flow
- the dashboard
- the pricing
- the onboarding
- the trust signals
- the support around edge cases
That was a big shift in how I thought about it.
At first, I was mainly focused on whether I could make the API work.
Now I’m more focused on whether the API is useful enough, clear enough, and trustworthy enough for someone else to actually rely on it.
That is the part I am trying to figure out now.
Does this solve a real enough problem?
Who feels this pain the most?
Is it small SaaS builders?
CRM developers?
Agencies?
Data teams?
Sales tools?
Internal dashboard builders?
People building directories?
And what would make someone trust the returned data?
Source links?
Confidence scores?
Field-level confidence?
Refresh dates?
Manual overrides?
Better matching when company names are similar?
I am still early, but I have already started improving it based on feedback. I’m trying not to just add more fields for the sake of it. I would rather make the core response more reliable, easier to understand, and easier to integrate.
The biggest lesson so far is that building the tool is only the first part.
The harder part is learning whether the problem matters enough to other people.
Site: https://fastbusinessapi.com
For anyone who has built an API product, enrichment tool, CRM feature, directory, or internal data workflow:
How did you figure out whether people actually needed it?
And what would make company/business data trustworthy enough for you to use inside a real product?
Top comments (0)