# Prospecting workspace

> From 1,907 LinkedIn profiles found to a 1,449-profile research workspace, with source context, activity signals and a draft desk that preserves my edits.

Personal project · Research & outreach tooling · October–November 2026

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/8>)

[Français](<https://zaki.somehow.engineer/read/fr/prospecting-workspace.md>)

## At a glance

| Metric | Value |
| --- | --- |
| My role | Research workflow & implementation |
| Initial scope | Hauts-de-France network |
| Core stack | TypeScript · Python · Local UI |
| Period | October–November 2026 |

## Make prospect research usable

As I began exploring freelance work, prospect research quickly became an information-management problem. Profiles, companies, possible contact details, sources and message drafts all needed to stay connected. I built a workspace that combines browser-assisted research with a local draft queue.

Nine regional keyword searches produced 1,907 distinct profile URLs. The recorded screening added 1,444 profiles with a relevant declared leadership, entrepreneurial or management role. Five existing profiles brought the research workspace to 1,449. The current Airtable count confirms that total; three blank rows are excluded.

| Value | Metric |
| --- | --- |
| 1,907 | Distinct profiles found |
| 1,449 | Profiles in the research workspace |
| 9 | Regional keyword searches |
| 174 | Profile cards in the separate Draft desk |

### Images and media

[Collection, screening and the retained workspace are separate counts. The final bar includes five existing profiles; 463 collected profiles were not imported. These are research records, not customers.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/research-corpus.en.png>)

Research counts: 1,907 profiles found, 1,444 added after screening, and 1,449 in the workspace including five pre-existing profiles.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/research-corpus.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

## Keep the evidence with the person

A TypeScript and Node harness works with an authenticated BrowserOS session. It extracts structured information from the observed page and keeps the profile URL, declared role, location, source context and research depth together. Ambiguous or unsupported interfaces return an explicit limitation.

Airtable holds the research records. A company inspection, a website observation and an agent’s interpretation have separate fields. This helps me distinguish something I saw from a possible conversation angle. A name match or a founder title alone does not establish a company identity, purchasing authority or a need for my work.

TypeScript / Node · BrowserOS · Airtable · Python · HTML / CSS / JavaScript

Research that stays connected to its sources

1. **Discover** — Collect declared profile information and preserve its source.
2. **Qualify** — Check the role, company context and depth of the available evidence.
3. **Organize** — Keep activity signals, unresolved questions and next steps distinct.
4. **Prepare** — Use that context for a draft I can review and edit.

Research and preparation workflow. The local Draft desk uses explicit imports; it does not silently synchronize with Airtable.

## Leave the unknowns visible

The activity map uses explicit French and English phrases in saved professional headlines, with a small set of overrides supported by recorded company notes. In the 27 October snapshot, 522 profiles carry an activity signal and 927 do not have enough evidence for one.

That 36% coverage is useful for choosing where to investigate next. It is not a confidence score or a verified industry classification. The same snapshot has 33 agent-review records, 16 company-inspection notes and 13 recorded websites. Those are different depths of evidence; an agent review can concern a search card rather than a fully inspected profile.

| Value | Metric |
| --- | --- |
| 33 | Profiles with an agent-review record |
| 16 | Profiles with a company-inspection note |
| 13 | Profiles with a recorded website |

### Images and media

[A deliberately incomplete map: an unsupported category stays unknown. The 27 October analysis supplies these classification counts; the 1,449-profile total and coverage-field counts were checked read-only in Airtable on 10 November.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/classification-coverage.en.png>)

Of 1,449 profiles, 522 have an activity signal, 36.0 percent, and 927 lack sufficient evidence, 64.0 percent.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/classification-coverage.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

## Use the map to choose a useful question

Software, services, creative work and operational businesses can suggest different conversations. I used the map to form small research cohorts, then look for the actual company, its offer and the context behind the profile before choosing an approach.

The labels overlap. Someone working on software for retailers can carry both software and commerce signals. A financial term can describe a person’s function or a customer market. The chart counts people with signals, not independent companies or confirmed demand.

### Images and media

[Six of thirteen activity categories from the saved analysis. Counts can overlap and must not be added as a partition. They help choose the next research question, not infer a prospect’s needs.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/activity-signals.en.png>)

Six overlapping profile activity signals: software IT data AI 236, consulting and services 89, marketing media creative 75, property construction 60, health wellbeing 42, and HR recruitment training 39.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/activity-signals.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

## One person, one shared draft

Draft desk turns the selected contact research into a local review queue. The current local state contains 174 profile cards and 677 candidate contact methods. That is a smaller workspace than the full research corpus, and the contact associations still need checking.

Records are grouped by canonical profile URL. One person has a shared subject and message, several possible contact channels and their own history. Names alone do not merge people, and a shared company inbox does not turn two profiles into one. I can inspect the source context, revise the wording and choose a channel.

From a draft to manual tracking

1. **Review & edit** — Check the association and make the subject and body my own.
2. **Send manually** — Copy the reviewed text into Gmail and decide whether to send it.
3. **Record the channel** — Mark the specific contact method used, then finish or reopen the profile.

Contacted and Done are manual workspace declarations. They are not email-provider delivery receipts.

### Images and media

[The existing review interface: context, candidate contact methods and a shared draft. This capture uses three fictional profile cards and demo drafts, not the real prospect database.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/draft-desk-context.webp>)

Draft desk overview with a fictional Alex Démo profile, company context and two candidate email options.

Credit: Draft desk’s existing interface, rendered with a local read-only synthetic fixture. All people, companies, contacts and drafts shown are fictional.

## Keep working while an agent prepares the next batch

An agent can export eligible records and prepare a batch while I keep editing. New drafts append to the queue: the documented example moves a person at 3 / 10 to 3 / 15 without changing their position or draft. Revisions, human-edit flags and completed statuses prevent silent replacement.

A batch is validated as a whole. Reusing the same batch ID with the same content is safe; conflicting reuse or stale revisions are rejected. The local store uses atomic writes and process locks, with migration backups and browser edit recovery when a save fails.

Subject and body edits use a 600 ms autosave delay, and the UI checks for appended work every three seconds. Those are interface settings. The engineering goal is continuity: I can review one message without losing it when the next five arrive.

### Images and media

[The composer keeps editing and the final decision visible. Read-only synthetic rendering of the existing UI; this capture is not a sent message or a backend persistence test.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/draft-desk-composer.webp>)

Draft desk message composer showing an explicitly fictional editable subject and email draft with local save status and manual tracking controls.

Credit: Draft desk’s existing interface, rendered with a local read-only synthetic fixture. All people, companies, contacts and drafts shown are fictional.

## What the project gives me

The recorded Draft desk validation includes 38 Python checks and 59 JavaScript/TypeScript checks, with synthetic UI scenarios for queue continuity, edits, recovery and contact-level tracking. Those figures describe the existing validation record, not a new full test run for this portfolio.

The result is a workspace I can return to: research stays inspectable, drafts stay editable and each person keeps their own context. I have not established a measured reply rate, client-acquisition result or time-saving figure from these records. What I can show is the workflow and the decisions that make it usable.
