How to Build a Personal OSINT Workflow on a Laptop: A 5-Component Setup

How to Build a Personal OSINT Workflow on a Laptop

You can do serious open source research with five components on one laptop. The list below is the minimum setup that makes a one-person project auditable, repeatable, and recoverable when something goes wrong. None of it requires an enterprise subscription, and all of it is portable — you can rebuild it on a fresh machine in an afternoon.

Auditable beats sophisticated

A small, well-understood setup is more useful than a large one you half-remember. The bar is "if I closed this laptop and a stranger opened it, could they redo the work?" If the answer is no, the setup is too clever. Strip it back until the answer is yes.

Tip

Component 1: A research browser

A second browser profile dedicated to your project. Not your normal browser, with your saved logins, your history, your cookies, and your email tabs. A clean profile with the extensions you need and nothing else.

Useful extensions:

• uBlock Origin. Fewer trackers, fewer pages that get in your way, fewer popups that break your screenshots.
• Wayback Machine. One click to archive a page, one click to see if a snapshot exists.
• InVID / WeVerify. For the video and image checks described in the rest of this guide.
• SingleFile. Saves a page as a single HTML file you can re-read offline, including images and styles.

The point of the separate profile is not paranoia. The point is that a research session is a different kind of work from your normal browsing, and mixing the two costs you time, focus, and credibility.

Component 2: A notes system with two surfaces

The cheapest workable setup is a folder of plain Markdown files. The point of Markdown is not the syntax — it is that the file is portable, durable, and you can search across it with grep if you have to.

Use two files:

• A running notes file. One section per day, in chronological order. Date headings. Stream of consciousness. This is the file you write in.
• A records file. One row per source, in tabular form. URL, date, claim, source type, confidence, archive URL. This is the file you cite from.

Every record in the records file should be linked from the notes file. Every claim in the notes file should be linked back to a record. The two-way link is what makes the project auditable.

A spreadsheet of links is not a notes system

A spreadsheet of URLs with no annotation is a pile, not a research artifact. The point of the records file is to commit to a claim, a source type, and a confidence level for each item. Without those columns, the file is decoration.

Warning

Component 3: An archive habit

The single most common OSINT failure is discovering that a key page has been deleted, edited, or moved. The fix is to capture a copy that you control, in two places, the moment you decide a page matters:

• A local copy. Save as PDF, single-page HTML, or screenshot, into a folder named after the project.
• An archived copy. Save to the Wayback Machine via the browser extension.

The local copy lets you re-read and re-quote offline. The archived copy lets you prove the page existed at a specific time, even if the original is gone. Both are necessary. Local copies fail when a laptop dies; archived copies fail when a takedown request is honored.

A useful rule: every record in your records file has a local copy path and an archive URL. A record missing either is not yet a record.

Component 4: A model you can talk to

A language model you can paste documents into, with a context window large enough to hold the records for one project. The point is not the size of the model — it is the discipline of always pasting the source, not asking the model to "look it up."

A small open-weight model running locally via Ollama has one big advantage: nothing leaves your machine. That matters when the records are sensitive. For open material, a hosted model is fine, as long as the prompts and inputs are part of your records.

The model is a triage and synthesis tool. It is not a source. The model's output is a paraphrase of the input, and the citation for the output is the input you gave it, not the model's training data.

Component 5: A reproducible export

A small, deliberate step at the end of each project: export the notes, the records, the captures, and the prompt log to a single folder. Drop the folder in cloud storage, on an external drive, or in a long-term archive.

A year from now, when someone asks "where did you get that?", the answer is a folder, not a memory. A research project that you cannot return to is a project that you have to redo.

The scripts that pay for themselves

A few small Python scripts will save you hours over the course of a project. None of them are exotic.

Pull every link from a page

import requests, re, sys
url = sys.argv[1]
html = requests.get(url, timeout=20).text
for href in re.findall(r'href="([^"]+)"', html):
    print(href)

Check whether a list of URLs is still live

import concurrent.futures, requests
urls = open("urls.txt").read().splitlines()

def head(u):
    try:
        r = requests.head(u, timeout=10, allow_redirects=True)
        return u, r.status_code
    except Exception as e:
        return u, f"err:{e.__class__.__name__}"

with concurrent.futures.ThreadPoolExecutor(max_workers=20) as ex:
    for u, code in ex.map(head, urls):
        print(code, u)

Archive a URL to the Wayback Machine

import requests
requests.post(
    "https://web.archive.org/save/",
    headers={"User-Agent": "your-project-name/1.0"},
    data={"url": "https://example.com/page"},
)

The script is the artifact, not the output

When you write a script that helps, keep the script. The next project will want a slightly different version of the same idea, and you will not remember the details in three months. A folder of small scripts is more useful than any single tool.

Tip

What to leave out

A few things to leave out of your default setup:

• Scrapers that require paid APIs. Most projects can be done with requests and a polite sleep between calls.
• Closed-source "OSINT platforms" with no documentation. If you cannot describe what the tool actually did, you cannot describe what your project actually found.
• Anything that requires you to log in with a personal account. Your project's audit trail should not depend on a vendor staying in business.
• Anything that needs a GPU you do not have. Local models are nice; they are not a requirement for a one-person project.

A small, well-understood setup is more useful than a large one you half-remember.