Python in production for regulators

Most code we write outlives the team that wrote it. The regulators and government bodies we work with have systems still in service that were first deployed in 2010 — and which will probably still be in service in 2035. The language you pick determines what that future maintenance feels like.

We write almost all of it in Python. Here's why.

Readability is a long-term cost

Python's syntax is closer to plain English than any production language we've used. Anyone with light programming background can read it, including the policy people who eventually have to audit business logic in court. We've literally had auditors point to a Python function and ask for behaviour clarifications — try that with Scala.

In a domain where you might need to defend an algorithm in front of a parliamentary committee, language readability is a regulatory feature, not just an engineering nicety.

Type hints closed the only gap

Python's old criticism — "too dynamic for serious work" — has been steadily dismantled since type hints landed in 3.5. With strict mypy and a modern editor, refactors are now as safe as a statically-typed language, but the code stays Python-readable. We treat type hints as mandatory across the codebase. It's the single highest-leverage change a team can make.

The ecosystem doesn't move on without you

Python has been a top-three language by usage for 15 years. The libraries we picked in 2008 (Plone, Postgres bindings, Pillow, Requests) are still maintained, still receiving security updates, still has the developer pool to hire from. Compare to Node.js — anyone who picked a 2015-era framework has rewritten it twice by now.

AI, data, web, ops, even modern UI all have first-class Python support. That breadth means we can solve adjacent problems (build a chatbot, run an ETL job, serve a dashboard) without leaving the language. For a small team of senior engineers, that's a force multiplier.

Hiring patterns we trust

There's an inexhaustible supply of mid-level Python developers. There's also a small but real population of senior Python engineers who care about software craft — Plone core contributors, scientific-computing veterans, ops-and-platform people. Python has been the language of "don't ship rubbish" engineers for long enough that the culture is established.

Where we wouldn't pick Python

Performance-critical inner loops on commodity hardware: Rust or Go. Browser frontend: TypeScript or Svelte. Embedded: C or Rust. Heavy numerical research: probably still Python (with NumPy / JAX) but the line is closer than people admit.

For everything else we do — backend services, CMSes, integrations, ETL pipelines, AI orchestration, ops tooling — Python is the unsexy correct answer.