Python

Python automation, APIs & data tooling

Python for three related jobs: automating work that people are doing by hand, building APIs and services with Django or FastAPI, and the data and AI tooling that sits alongside them—each written to be run again by someone other than its author.

The repetitive work stops being manual, and stays auditable afterwards.

Automation and scripting

Data processing, migrations, reporting and scheduled jobs, replacing the spreadsheet step nobody documented.

APIs and web applications

Django and FastAPI services with validation, authentication and background work handled explicitly.

Data tooling

Moving, reconciling and checking data between systems, with the checks written down rather than remembered.

AI and model integration

The Python side of an AI workflow: structured output, evaluation and the deterministic fallbacks around it.

When it fits

  • A person spends a day each month producing the same file.
  • Two systems hold the same data and disagree about it.
  • A model needs to sit inside a process that must stay defensible.
  • A script exists, works, and only one person dares run it.

How it is built

  • Written to be re-run: idempotent where it can be, and safe to stop halfway where it cannot.
  • Dependencies and environments pinned, so it behaves the same on someone else's machine.
  • Type hints and tests on the logic that would be expensive to get wrong.
  • Output that says what it did, so a failed run is diagnosable without reading the code.

Not this

  • Data science research with no decision attached to it
  • Scraping services whose terms forbid it
  • One-off scripts with no owner after delivery

Is this data science?

Not usually. This is engineering work: automation, services and pipelines. Where a model is involved, the emphasis is on making its output reviewable and its failure mode defined.

Can you automate a process we currently do by hand?

Often, and the first step is watching what the process actually is. Automating the described version of a process rather than the real one is the common way this goes wrong.

Who maintains it afterwards?

You do, and it is delivered on that basis: pinned dependencies, a written run procedure, and no dependency on my being available.

Take the session when the work still needs scoping. Send the brief when you already know what needs building.

A clear next step

Start with the decision in front of you.

Get preliminary direction first, or book a focused session when the question is ready.