Istak case study: we built a country based B2B company discovery system
A map led operator workspace that turns country and category searches into a persistent company catalogue.
We developed an operational discovery dashboard for Istak. An operator selects a country, chooses a buyer category, runs a search, and reviews companies with the search state preserved in the database. The map shows which categories have been processed; the United States also supports a separate state level scope.

SELECT country | optional US state
→ CHOOSE importer / distributor / wholesaler / retail chain / online store
→ RUN category search through backend
→ STORE deduplicated company records and versioned progress
→ REVIEW catalogue and map statusThe business task
Istak needed a repeatable way to discover potential B2B buyers across markets. A web search alone leaves an operator with scattered links and no clear record of which country, buyer type or state has already been covered. We shaped the first working stage around a searchable country catalogue, a geographic overview and durable results.
From an open search to a defined search scope
The discovery task was specific: identify possible buyers of alcoholic beverages and spirits, then keep enough context to decide which sites deserve further review. An importer and an online store are different commercial profiles. Combining them in one undifferentiated query would make both the results and the operator's progress harder to interpret. We therefore made buyer type an explicit input, not a label added after results arrived.
Geography is equally important. The country directory lets the operator move between markets without losing the search state. The US needed a finer level: a national query and a California query should be distinguishable even when they find the same company. That requirement shaped the search API, database keys and progress display together.
What we built
We delivered a React and Vite dashboard with a jsVectorMap world map, a Fastify API and PostgreSQL persistence. The operator can search five buyer categories: importers, distributors, wholesalers, retail chains and online stores. For the US, the interface offers All USA or any of the 50 states, with separate progress for each state.
One interface, separate responsibilities
The React client handles selection, map state, the company list and operator feedback. It requests countries and their completed-category counts from the API, then refreshes the map colour series when those asynchronous results arrive. The map is therefore a view of saved work, rather than a decorative world graphic or a manually maintained spreadsheet of finished markets.
Fastify handles search requests and provider access. PostgreSQL holds companies, their discovery context and progress by geography and category. This split lets the browser render and filter the workflow while the backend remains the authority for saved results and status.
An operator's path through the system
The operator selects a country on the map or from the searchable list. For the US, they can narrow the scope to a state. After choosing a category, the dashboard sends that exact scope to the backend. The response fills the company catalogue and updates the category state. Opening a company shows its source and available descriptive evidence; returning to the country retains the saved results and progress.
A concrete run, without invented company names
Consider an operator selecting Germany and the distributor category. The dashboard requests a search for that market and buyer profile. The server obtains web results, saves usable company records and updates the category status. The interface then loads the saved catalogue, instead of treating the new results as a temporary list.
The US follows the same interaction with an extra scope. Choosing California records a state code alongside the category; choosing All USA leaves the state scope empty. The state picker shows its own company and completed-category counts. A company may appear in more than one category or state, but the operator sees those discovery paths attached to one stored company record.
Map and progress as an operating view
The map is connected to the API's country state. It uses five increasing green levels for one through five completed current search categories. A completed category means its versioned query pack finished; it does not mean the whole market has been exhausted. The US state picker maintains its own category counts and results, so a California run is not confused with a national run.
What the green levels actually mean
The dashboard has five buyer categories and five corresponding progress steps on the world map. A country moves from zero to one completed category when a current-version category run finishes successfully; the colour deepens as more distinct categories finish. For the US, the world map reflects the national scope, while the state picker carries the separate state progress. This prevents a set of state searches from making the whole country look complete.
The system distinguishes completed and failed searches and ties progress to the current search configuration. An unsuccessful run cannot colour a market as complete, and an earlier result cannot silently stand in for a revised search. The operator sees a useful progress signal without mistaking it for a guarantee of full market coverage.
Search, storage and data boundaries
The backend runs searches suited to the selected buyer category and geography through Brave Search. It removes repeated company domains and saves results with their discovery context in PostgreSQL. The system also saves whether each category search has run successfully, so the operator can return to a market later. Search snippets remain material for review, not verified contacts or qualified buyers.
How a web result becomes a catalogue entry
Search wording changes with the buyer category and selected geography. A distributor search asks a different question from an online-store search; a state search stays distinct from a national one. The operator can therefore choose a meaningful scope and see its outcome separately from other searches.
The backend normalizes website domains and avoids adding the same company repeatedly to a market catalogue. It preserves enough source context for the operator to inspect why a company appeared and which searches found it. Results are organized for review rather than promoted directly into verified contacts or a ready-to-contact sales list.
Engineering choices and tradeoffs
Search access and credentials remain on the server. Runs are bounded so the operator receives a clear result and status. Broad discovery can include candidates that still need review; a national domain can help organize the list but cannot establish a company's location or relevance. These choices keep the search stage useful without presenting discovery as completed qualification.
Predictable limits and honest failure states
The browser does not need the search provider credential. Searches go through the backend, where access and failures can be handled consistently. If a search fails, the interface reports the problem and preserves an honest status rather than presenting an empty table as a successful search.
Each run has a practical limit. This makes progress understandable, but a completed category means the configured search finished, not that every possible company was found. The operator can decide whether to refine the search, repeat it later or review the current catalogue. We deliberately kept this distinction visible in the product and the case study.
The delivered result
Istak now has a working operator system that links geography, buyer category, search results and processing state. The implemented stage covers discovery and review. AI analysis, CRM synchronization and email outreach are separate future stages; no sales conversion or time saving figure is claimed here.
A usable first stage with clear next decisions
The result is a coherent discovery stage: choose the market and buyer profile, run a controlled search, retain sources and deduplicated companies, and see which scopes have already been processed. Operators can return to a country or state and continue from saved data rather than reconstructing the session from browser memory.
The next business decision is qualification: which discovered sites are genuine potential partners and which contacts can be verified from authoritative sources. The current system does not make that decision automatically. Presenting the delivered search stage on its own keeps this case useful to a team evaluating a comparable dashboard, without turning a product roadmap into a claim of completed outreach.
The implemented data path
- Country / US state + buyer category
- Fastify query pack → Brave Search
- Normalize and deduplicate results
- PostgreSQL company + category state
- Company catalogue + map progress
Need a similar operational dashboard or data workflow?
Discuss a project · See product development · AI specialist in Armenia · More case studies