What we do

Seven kinds of work that shouldn't still need a person.

They overlap more than you'd expect, because underneath they are the same job: something arrives as a document, a file, a message or a web page, and somebody on your team has to read it and retype what matters somewhere else. If yours is close to one of these but not quite, it's still worth asking.

The work

Start with the one that sounds like your week.

Reading the things nobody has time to read

PDFs, scanned reports, contracts, hearing and meeting recordings. What comes back is a table: one row per thing you actually needed, with a pointer to the page or the timestamp it came from, so any line can be checked against the source in about five seconds.

Captions and transcripts fall out of the same pass. If your meeting video has to meet accessibility requirements, that is already done rather than a second job with a second invoice.

This is the one with a real example behind it

The report someone rebuilds by hand every month

The recurring report. Two exports that should reconcile and don't. The workbook one person understands and everyone else is quietly afraid of. The same deliverable regenerated from new data, several days a month, forever.

It becomes a job that runs on a schedule and checks its own arithmetic. Excel or Google Sheets usually stays as the way people look at it, because that is what they already know. What changes is that nothing gets retyped to get it there, and it does not break silently when somebody inserts a row in the wrong place.

Dashboards that are current without anyone touching them

A dashboard is only as trustworthy as the last time somebody remembered to refresh it. If a Tableau or Power BI view is fed by a CSV re-uploaded every Monday, the number on screen is partly a guess about how recent it is, and everyone in the room knows it.

We put scheduled, validated data behind it instead: pulled on a timer, checked before it lands, and loud when a source stops answering. Nobody has to remember anything, and the date on the screen is the real one.

The inbox work that never ends

Sorting and routing. Pulling what matters out of attachments and filing it where it belongs. Drafting the repetitive replies that only differ by three fields. Chasing the thing that always needs chasing.

None of it is hard. It is just constant, and it lands on the person you would rather have doing something else. Anything that goes out under your name still gets a person to send it — the draft is the part that stops taking an hour.

Data that's on a website and nowhere else

Permit portals, agency databases, public registers, listings — sites with no export button and no API, where the only way to get the data is a person and a mouse.

We collect it on a schedule, keep the history so you can see what changed and when, and check the shape of what comes back. If a page changes underneath the collector, you hear about it rather than getting a quietly empty file.

Two systems that don't talk to each other

The unglamorous middle: moving records between systems, renaming and reformatting fields, converting files, and validating both ends so a bad row gets caught at the door instead of three weeks later.

It is the least visible work on this page. It is also usually the thing that stops everything else from needing a person in the loop.

The automation you already paid for, that stopped working

A vendor built something and moved on, or the person who wrote it left and took the context with them. It can be audited, documented and repaired, and you get a plain description of what it is actually doing, which is often the more useful half.

Sometimes the honest answer is that it should be replaced rather than propped up. We would rather say that than bill you to keep it upright.


Examples

What a build actually looks like.

Four shapes the work usually takes. Yours will be its own thing, but the pattern holds: you hand over the mess, we build the pass that reads it, and what comes back is something you can sort, check and argue with.

  1. A three-hour scoping meeting

    You have
    A recording, a sign-in sheet, and two days of somebody's week about to disappear into a scrub bar.
    We build
    A pass that transcribes the audio, separates the speakers, groups comments by topic, and merges the same point raised four times into one.
    You get
    A sheet with one row per distinct comment — who raised it, where it sits in the recording, and an empty column for your response.
  2. A shelf of final reports

    You have
    Years of technical reports, with the mitigation measures existing only as prose inside two-hundred-page PDFs.
    We build
    Extraction of each measure with its number, phase, responsible party and timing — scored for confidence, and measured against a test set built by hand from your own documents.
    You get
    A table you can filter, sort and hand to a client, plus a queue holding anything the system wasn't sure enough about.
  3. The monthly report that eats four days

    You have
    Three exports, one workbook, a set of pivot tables, and the same four days of somebody’s month, every month.
    We build
    A scheduled job that pulls each source, reconciles them against each other, and regenerates the workbook — stopping loudly if two sources disagree instead of quietly picking one.
    You get
    The same file people already know how to read, on the first of the month, without anyone building it.
  4. Permits with the dates buried in them

    You have
    Conditions of approval, monitoring obligations and reporting deadlines, all written as sentences inside scanned PDFs.
    We build
    Extraction of every date and obligation, pushed into the calendar your team already uses, with a reminder ahead of each one.
    You get
    Warnings before things are due, and a list you can audit line by line against the document it came from.

These four are illustrations of the kind of work, not projects we're claiming to have done. There is one real project on this site, it is named, and it has its own page: the Scripps cruise report index.


Scope

Start small enough to check.

We start small and narrow — one task, one document type, one report, one meeting series. Something with a clear before and after, where you can tell within a few weeks whether it worked.

Where the work involves reading documents, we build a test set out of your real files first, so there's an actual measurement rather than a feeling. Then it goes live — on your hardware or on ours, whichever suits you — and you have something you can check.

Big rollouts that touch everything at once are how these projects go wrong. There's usually no reason to start that way.

Where we're not the right fit.

If the work genuinely needs professional judgment — deciding whether a finding is significant, writing the argument, signing off on it — that's yours and it should stay yours. What we can do is get the raw material in front of you sorted, so more of your week goes to that part.

We're also not the right call if you want something running by Friday with no way to check whether it's correct. That's how an automation ends up running for a year before anyone notices it has been quietly wrong the whole time.

And if the honest fix is a change to how the work is organised rather than software, we'd rather say so.

Not sure which of these is yours?

That's a normal place to start. Describe the task that eats the most time and we'll work out together whether there's something here.

Book 20 minutes