Python Development — APIs, Automation and Data Work

Why Python for this work

It is not a religious choice. Python wins here because the libraries already exist for the boring parts — parsing files nobody documented, talking to APIs with inconsistent authentication, scheduling work reliably — and because the next developer who touches it will be able to read it.

For anything CPU-bound and latency-critical it is the wrong tool and we will say so. Most business software is neither.

How the work is structured

Small, deployable pieces rather than one large rewrite. The first thing we ship should be useful on its own, because plans that only pay off at the end tend not to reach the end.

Tests on the parts where being wrong is expensive — money, customer data, anything that sends email. Not a coverage target for its own sake.

Django, FastAPI, or neither

Django when there is a database, an admin and users to manage — its admin alone saves weeks of building screens nobody outside the company will ever see. FastAPI when the job is an API and speed of response matters more than batteries included.

And sometimes neither. A scheduled script of two hundred lines that runs reliably and can be read in one sitting is a better answer than a framework, and it is the recommendation we give more often than clients expect.

Taking over somebody else's code

A good deal of our Python work starts with an inherited codebase, no tests and the original developer unavailable. The first job is not features. It is getting it running locally, writing tests around the parts that handle money or customer data, and finding out what is actually safe to change.

That phase feels slow and is what makes everything afterwards fast. Skipping it is how a two-week change becomes a three-month outage.

Who owns it afterwards

Automation nobody understands becomes a liability the day it breaks, and the person who wrote it is the only one who can fix it. That is a worse position than the manual process it replaced, because at least somebody knew how that worked.

So the handover matters as much as the build: a README that explains why, not just how; environment setup that works from a clean machine; and a walkthrough with whoever will be on call when it fails at month end. If you would rather we kept running it, that is fine too — but it should be a choice rather than a dependency you discovered later.

Where automation pays, and where it does not

A task worth automating is frequent, rule-based and currently done by a person who resents it. A monthly report assembled from four systems qualifies. A judgement call dressed up as a process does not, and automating it usually produces confident wrong answers faster.

We would rather work out the arithmetic with you first — how long the task takes, how often, and what the build costs — than deliver something that saves twenty minutes a month.

What you get

• Working code in your repository, not ours
• Deployment that someone other than us can run
• Documentation aimed at the next developer, not at impressing you
• Monitoring, so a failure is something you hear about rather than discover
• An honest view on whether the automation saves enough to justify building it