What hiring Python developers costs depends on the job
Python work is priced as a list of technologies, but what it costs turns on which of three jobs you have: a service, a pipeline, or a model in production.
Tell us what breaks
What is failing, what it runs on, who is waiting for the output. If our bench does not match, we say so.
Nothing threw an error, and the number still changed
The job ran, nobody was paged, and the invoice total, forecast and board figure all changed. Explaining that is yours.
Senior titles, junior output
The profiles were strong. What comes back needs rewriting, and you find that out at review rather than at estimate.
Fragile code, nobody wrote anything down
There is no requirements pin, so it runs on whatever was installed. A fresh machine builds something different, and nobody can say which parts.
Re-runs that do not agree
The backfill is not idempotent, so running it twice double-counts. Hidden state and out-of-order execution mean last month’s script no longer produces last month’s answer.
Vendor churn and handover gaps
Each new team spends its first month learning what the last one meant, and the reconstruction is billable.
Endless recruiting cycles, missed windows
The role has sat open for months while you promise a board, an investor, a customer or a regulator, on code nobody here can read.
In Monte Carlo's 2023 survey of 200 data professionals, 74 percent said business stakeholders spot these problems first.
When 863,878 public Python notebooks were re-run, four percent came back the same
Python written to answer a question tends to be written once and trusted afterwards. Joao Felipe Pimentel, Leonardo Murta, Vanessa Braganholo and Juliana Freire, presented at the 16th International Conference on Mining Software Repositories in 2019, re-executed 863,878 public Python Jupyter notebooks. About a quarter ran to the end without raising an error. Four percent produced the answer the file had stored. 173,487 finished cleanly and returned something different, and nothing anywhere said so.
Show data table
| Stage | Count | Share of first stage |
|---|---|---|
| Notebooks re-run | 863878 | 100% |
| Ran to the end without an error | 208323 | 24.1% |
| Produced the same results the file had stored | 34836 | 4% |
A second group found the same shape. Sheeba Samuel and Daniel Mietchen, in GigaScience 2024, re-ran 15,817 Python notebooks attached to PubMed Central publications, and 5.6 percent reproduced identically. All of that is public open-source code, because private production code cannot be mined. That leaves you a test, not a verdict: re-run last month's output and see whether last month's number comes back.
Five checks you can run before you hire anybody for Python work
These separate the three jobs, and all five take about two minutes.
- When it goes wrong, does another piece of software notice, or does a person? Software noticing first means a service other software calls, measured in contracts, endpoints and uptime. A person noticing first means a pipeline or a model, measured in whether it can be re-run at all.
- Can anyone re-run last month and get last month’s number back? If nobody has ever tried, that is your answer, and it sets the size of the work more than any feature list will.
- Is there a file that says what it needs installed, and does a fresh machine come out the same? No such file means the environment is part of the system and nobody wrote it down. That gets pinned first.
- Does anything stop a change reaching the thing that matters if it breaks something else? If nothing gates it, every change is a live experiment on the output your business reports.
- If the person who wrote it left tomorrow, what would the next person open first, and does it exist? This is the one that prices the handover. When the answer is a name rather than a document, you pay to write that document either way.
One and two tell you which of the three jobs you have. Three, four and five tell you whether you are buying a build or a takeover.
Start a scope conversationThe first two weeks make it answerable
On code nobody can open, the fastest route to new features is not new features.
- Map what runs
Read it and write down what actually runs. What executes, on what schedule, and who consumes the output. On most systems handed to us that document does not exist, and writing it is where the first surprises turn up.
- Pin the behaviour
Pin the current behaviour with tests. Michael Feathers, in Working Effectively with Legacy Code, 2004, defines legacy code as code without tests. He calls a test that records what the code does today, rather than what it ought to do, a characterization test. Those go in before anything is changed.
- Declare the dependencies
So it installs the same way twice on a machine that has never seen it. Feathers calls a place where you can alter behaviour without editing in that place a seam, and the environment is usually where the first ones are.
- Review and gate
Reviewed by a senior software engineer and gated on tests, so it cannot quietly undo what was already pinned.
- Document as it happens
Write the documentation as the work happens, from Day 1 and kept current, rather than assembled at the end from memory.
Pinning behaviour and declaring dependencies are general practice, with no efficacy study behind either. What there is is a measurement of where the hours go. Across 79 professional developers on seven active commercial projects and 3,244 recorded working hours, Xin Xia and colleagues, in IEEE Transactions on Software Engineering 2018, measured 57.62 percent of working time going to understanding existing code and context, against 5.02 percent editing it. Those projects were Java and C#.
Four things to ask any Python development company for
Ask each in a form where the answer can be checked rather than asserted. Does a senior software engineer review every change? Do unit and integration tests gate the merge? Is there a written architecture record saying why the system is shaped the way it is? Does documentation exist from Day 1, or get written at the end?
Python Developers Survey 2024, run by the Python Software Foundation with JetBrains among more than 25,000 qualified respondents.
The same survey: Python Developers Survey 2024, Python Software Foundation with JetBrains.
An IEEE Access 2023 mining study of its own corpus, about half of them holding fewer than six.
Testing is widely used, and asking is still worth the minute. Written architecture records are rarer, and usually thin.
What happens to a change before it merges
A senior software engineer reviews it
Every change goes through code review by a senior software engineer before it merges. The review history sits on the branch, so you can open it rather than take it on trust.
Tests gate the merge
We run GitFlow with unit and integration tests, and the CI/CD pipeline gates every merge on them, so a change that breaks a test does not reach the branch your system deploys from.
The architecture decisions are written down
Architecture decisions are documented in the Technical Requirements Specification, so anyone reading the system years from now, us included, can see why it is shaped that way.
Documentation starts on Day 1
The documentation starts with the first commit and stays current through delivery, rather than being assembled at handover.
Hold us to those four, and ask whoever else is bidding for theirs in the same form.
What the other route actually adds up to
You probably have a salary number in your head for a first in-house Python hire. That is the wage line, and it is about two thirds of what the first year costs.
Show data table
| Step | Change | Running total |
|---|---|---|
| Median annual wage | 135,980 USD | 135,980 USD |
| Employer benefits | 58,444 USD | 194,424 USD |
| Cost per hire | 5,475 USD | 199,899 USD |
| Year one total | 199,899 USD |
That is 63,919 dollars, or 47 percent, above the figure most people start with. Rebuild it with your own salary number. Outside the United States the shape holds and the size changes. Eurostat, published 31 March 2026, puts non-wage costs at 25.6 percent of total labour cost in the euro area, which is about 34 percent on top of wages.
The commitments worth reading are the ones that apply on the day you decide to stop.
What you keep if this fails
The code is yours from Day 1
What we commit to
Every line of it is your IP. It lives in your repositories and deploys into your cloud accounts. Where you already have Git hosting, cloud accounts and storage, we work inside them; where you do not, we provision them and hand you the keys.
Leaving is a process that is already written
What we commit to
If you offboard us, you keep everything, including the operational runbook. The handoff is a process, not a hostage situation. So far, no client has needed to use it.
The bar is agreed before anyone starts
What we commit to
A pilot period runs at the start of a new developer engagement, with its evaluation criteria written in, so what counts as working is agreed before the first day rather than argued about afterwards.
Nothing in the build moves on a re-scope you have not accepted
What we commit to
Every change request becomes a change note, with the time, the effort and the cost laid out before approval.
These arrangements tend to be long ones
What we commit to
Most engagements continue past launch as ongoing maintenance and growth work. Our longest active partnership has run more than a decade.
Python is three disciplines wearing one name, and nobody is equally deep in all three. We have declined engagements that would have benefited Atyantik but not the project.
When not to hire us
Where we are deep
Python that runs as a service or as a pipeline.
Putting a model somebody else built into production and keeping it working there.
That includes the tool-calling and agentic plumbing around it, and the monitoring that tells you when it stops behaving.
Where to go instead
Training a model, fine-tuning one, or any work where the modelling itself is the engineering. That is a specialist discipline and not where our bench is. What you want is a machine learning house that does the research half; the people who put its output into production can come afterwards.
If you are not sure which you have, describe what you would want the system to do differently in six months. If the answer is about accuracy, that is the modelling, and somebody else's job. If it is about reliability, cost, speed, or that nobody can safely change it, that is ours.
Questions about hiring Python developers
How quickly can a dedicated Python developer start?
- SHRM’s 2017 benchmarking report, across 864 organisations, puts the median time to fill a role at 30 calendar days from the requisition opening to an offer being accepted, across all roles rather than developer roles. That clock stops at offer acceptance and does not count the notice period the person then serves.
- A three year study of new hires at six application development firms, by Sai Anirudh Karre, Neeraj Mathur and Y. Raghu Reddy in 2023, found new software developers took four to six months after joining before they were moved onto production code, in a population that was 80 percent fresh graduates.
Can we interview the person?
If we hire offshore, will they be there in our hours?
What about the Python we already have that nobody understands?
Who owns the code?
How long do these usually run?
Tell us what breaks
Describe what is failing, what it runs on, and who is waiting for the output. If our current bench does not match your requirement, we tell you that directly. If a specialised vendor would serve you better, we say that too. That is a good result, not a failed one.
- the code is yours from Day 1
- you keep everything, including the operational runbook
- if our bench does not match, we tell you that directly