TorForge

About

We build automation, software, and workflows for people who want technology to work for them.

TorForge is a pseudonymous engineering practice. The name is the brand the work is published under, in the way an author uses a pen name.

What we build

Most engagements begin with a description rather than a specification. Someone explains that a report takes a morning to assemble, or that two systems disagree and a person reconciles them by hand every week, or that a process works until a particular file arrives in a slightly different shape.

Our job is to turn that description into something dependable. That means asking enough questions to find the real requirement — which is often not the one first stated — and then building the smallest reliable thing that removes the problem.

You do not need to know what you need, and you do not need the vocabulary. Bringing the problem is enough.

Where the depth is

Automation

Scheduled jobs, data pipelines, document and spreadsheet processing, API integrations between systems that were never designed to talk to each other, and the glue that removes a recurring manual step.

Web scraping

Structured extraction from sites and portals that offer no API, including session handling, pagination, rate limiting and the ongoing maintenance that scraping honestly requires.

Software development

Internal tools, services and interfaces: the small, well-shaped applications that sit between a workflow and the systems it depends on.

Beyond those three

Reverse engineering undocumented formats and protocols, command-line tooling, database work, deployment and self-hosting, and diagnosing why an existing system behaves the way it does.

What we work with

  • AppX / MSI
  • ChromeDriver
  • discord.py
  • JavaScript
  • PowerShell
  • PSWindowsUpdate
  • Python
  • PyYAML
  • Regex
  • Selenium
  • SQLite
  • TamperMonkey
  • Windows
  • Windows Registry
  • Winget

Tools are chosen per problem, not per preference. The case studies show where each one was actually used.

How we work

  1. Understand the workflow first

    Before proposing anything, we map what actually happens today, including the steps people have stopped noticing they do. Most of the useful information is in those steps.

  2. Reduce friction, not headcount

    The goal is to remove the tedious part of a job, not the person doing it. That usually means automating the copying, checking and re-formatting, and leaving the judgement where it belongs.

  3. Build for the day it breaks

    Anything that runs unattended will eventually hit a case nobody predicted. We build for retries, clear failures and recoverable state, so a bad night does not become a lost week.

  4. Document the result

    A system nobody else can operate is a liability. We hand over something readable: what it does, where it runs, how to change it, and what to do when it stops.

  5. Respect the constraints you already have

    Existing tools, licences, compliance rules and the patience of the people using it are all real constraints. A technically elegant answer that ignores them is not an answer.

Judge it by the work

The most useful thing on this site is the work itself. Case studies show the problem and what changed; the writing shows the reasoning.