Searching consultant.dev from inside ChatGPT, a walkthrough

A walkthrough of the consultant.dev ChatGPT App: what it exposes, three example prompts, anonymous versus signed-in surface, and what is intentionally out of scope for v1.

Searching consultant.dev from inside ChatGPT, a walkthrough

The contractor question almost always starts somewhere other than a job board. Someone is asking ChatGPT what a senior data engineer earns in Berlin, what the remote market for cloud architects looks like across the EU, or whether there is real demand for a niche skill before they invest a quarter learning it. Once the picture forms, they move to a job board to look for live roles. That second step now collapses into the first.

consultant.dev is a published ChatGPT App, approved by OpenAI on 2026-05-06. Searching the index from inside the conversation is now the default path for users who already work with ChatGPT for research, comparison, and rate negotiation. This post walks through what the App does, what it exposes, and what is intentionally out of scope for v1.

Why a ChatGPT App

A traditional aggregator forces a lane change. The user has a question, opens a tab, builds a filter, scans a list, and copies a number back to wherever the question started. Every lane change loses context: the rate band gets typed twice, the country list gets narrowed twice, the role title gets re-spelled. The aggregator wins only when the user is ready to commit to a single search.

The App removes the lane change. The contractor stays in the conversation. Filters arrive as natural-language constraints inside the prompt and get translated into the same backend the website talks to. Comparisons across countries and rate bands happen in line with whatever else the user is asking ChatGPT about. The aggregator meets the question where the question already lives.

This is not a marketing claim about future workflow. It is the workflow of every contractor who has ever asked ChatGPT a market question, then opened a second tab to act on it.

What is exposed

The App publishes a small, honest set of tools through the Model Context Protocol. Each one maps to a single backend capability:

  • search_roles: search live contractor and consultant roles by skill, country, region, day-rate band, and remote flag. Returns role title, company, country, posted date, day-rate or salary band when present, and a deep link.
  • role_detail: fetch the full description and posting metadata for one role from the deep link.
  • rate_distribution: return the day-rate distribution (p25, p50, p75) for a skill or role across a chosen geography. Used when the user is asking a market question rather than a sourcing question.
  • list_countries and list_skills: discoverability tools that surface the country and skill vocabularies the index recognises, so the assistant can normalise free-text country names and skill phrases against what the backend understands.

There is nothing else under the hood. No background agent, no scheduled action, no email capture inside ChatGPT. The App is a thin protocol surface in front of the same index the website queries.

Three walked prompts

The fastest way to see what the App actually does is to walk three prompts that exercise different shapes of question.

Remote Python contracts paying €700+/day in EU. The assistant translates skill (Python), region (EU member states), remote flag (true), and day-rate floor (€700) into a single search_roles call. The result comes back as a ranked card list with title, company, country flag, day rate, and a deep link to the consultant.dev role page. The user can ask follow-ups in the same turn ("only the ones posted this week", "drop the agency listings") and the assistant reissues the call with tightened parameters. No filter UI, no re-typing.

Senior data engineer roles in Germany this week. A recency + role + country query. The assistant calls search_roles with role_title="senior data engineer", country="DE", and a posted-after window of seven days. Cards return with the German market subset; the user clicks through to the consultant.dev role page when one looks worth pursuing. The deep link carries the necessary context, so the role page does not need to re-derive the search filters.

Day-rate distribution for cloud architects across UK, NL, SE. This one is the differentiator. A standard job board cannot answer it without the user opening three filtered searches, eyeballing a few dozen postings each, and forming a mental average. The App calls rate_distribution once per country and returns three small distributions (p25, p50, p75 in local currency, normalised to EUR alongside) in a single response. The user gets a comparable shape of three markets in a single turn. Sourcing and market-research collapse into one action.

These prompts are illustrative, not exhaustive. The same surface answers questions about contract length, language requirements, sector mix, and which sources cover which countries.

What the index is drawing from

The numbers behind the App match the website. Tens of thousands of live contractor and consultant roles, refreshed throughout the day, indexed across 100+ countries, drawn from hundreds of upstream sources spanning generalist boards, specialist contractor platforms, agency feeds, government registers, and direct employer pages. Source coverage is the moat: the App is only as useful as the underlying breadth of live roles, and that breadth is what consultant.dev has spent its time building.

Every role card carries a deep link to the consultant.dev role page. The App does not host the role detail itself; it leans on the canonical page so the user can verify the source, read the full description, and follow through to the original posting. That keeps attribution clean and keeps the App honest about what it is: a conversational interface in front of the same index, not a parallel dataset.

Anonymous versus signed-in

The App is open to anyone. An anonymous ChatGPT user can search, filter, and pull role details without an account. That is by design: the public market data is exactly that, public, and putting a sign-in wall on a research question would defeat the point.

Signing in to consultant.dev unlocks the parts that depend on a profile. Saved searches that notify on new matches. Draft cover letters generated against a stored CV. A match feed personalised against the user's skill graph and rate floor. None of those are forced into the App; the conversational surface stays focused on search and market data. Profile-driven features remain on the website where the profile lives.

The intent is to keep the App page off the sign-up funnel. A user comes for the answer; if they want the matching product, they can move to consultant.dev when the work calls for it.

What is not in v1

A few things are out of scope for the launch, deliberately:

  • Apply inside ChatGPT. The App links out to the source posting on the consultant.dev role page. Apply flows are too varied across upstream sources to compress into a single in-conversation action without losing fidelity.
  • CV parsing from ChatGPT. The App does not ingest a resume from the conversation. CV-driven matching requires the consultant.dev profile flow, which lives behind sign-in for storage and retention reasons.
  • Multilingual assistant text. The conversational surface ships English-only at v1. The underlying role data covers many languages already; the assistant scaffolding around it does not yet localise.

What lands next depends on real usage. The first wave of telemetry will tell us where the assistant struggles to translate intent (likely sector-specific role titles and currency-band normalisation), and which markets see the most traffic. v2 will follow that signal, not a roadmap built in advance.

Try it

The App is live in ChatGPT now: https://chatgpt.com/apps/consultant-dev/asdk_app_69ea56e748ac819192dd2f40d48eb23a. The website remains the same: https://consultant.dev. Anything that works inside the App works on the website too, and vice versa, against the same index.

If a country or sector feels under-covered for the kind of work you do, that is a useful signal. Source coverage is what we spend time on; the App makes the gaps visible faster than the website does, because asking a question is cheaper than building a filter.