Hiring a Python developer for your SaaS backend

Most SaaS companies do not have a Python problem.

They have a backend problem, an integration problem, or a process that has become too expensive to run manually.

Python happens to be one of the tools I use to solve those problems.

I have been building backends for 8+ years: SaaS platforms, integrations, automations, internal tools and products of my own.

These days, I am particularly interested in working with people who already have a real problem and want someone who can take ownership of solving it — not someone who needs another developer to turn tickets into code.

What I actually do

Most of my work falls into a few categories.

SaaS backends

I build and maintain the parts of SaaS products that users don’t see but depend on:

• APIs
• databases
• authentication and permissions
• background jobs
• integrations
• data processing
• reporting
• billing-related logic
• internal tools
• deployment and infrastructure

I mostly work with Python, Django, FastAPI, PostgreSQL, Docker and Linux.

I am comfortable joining an existing codebase as well as starting a backend from scratch.

The technology is important, but it is rarely the difficult part.

The difficult part is understanding what the system actually needs to do.

Integrations and automation

A lot of business software is essentially:

System A
    ↓
some business logic
    ↓
System B

Except there are usually six systems, three spreadsheets, an API that behaves strangely and someone spending two hours every morning copying information between them.

This is the kind of problem I enjoy.

I have worked on integrations with external APIs, data synchronization, browser automation, background processing and workflows that replace repetitive manual work.

Sometimes the answer is a new service.

Sometimes it is a small script.

Sometimes it is a scheduled job.

And sometimes the best solution is to remove the process entirely.

I don’t want to build a €20,000 system to automate a €200 problem.

I prefer solving the process, not just the ticket

One of the most useful things a developer can do is question the requested implementation.

If someone tells me:

“We need an API endpoint that does X.”

I want to understand why.

Maybe the endpoint is the right solution.

Maybe a background job is better.

Maybe the existing process can be simplified.

Maybe the data is already available somewhere else.

Maybe nobody should be doing the task in the first place.

This is especially important when working with businesses rather than purely technical teams.

The goal is not to produce more software. The goal is to make the business work better.

I am comfortable with boring technology

I have no particular interest in introducing a new framework just because it is fashionable.

For many projects, a perfectly reasonable stack is:

Python
Django / FastAPI
PostgreSQL
Docker
Linux

And sometimes even:

Python
SQLite

If SQLite solves the problem, I would rather use SQLite than operate a database server for no reason.

If a simple VPS is enough, I don’t need Kubernetes.

If a cron job solves the problem, I don’t need a distributed task platform.

This is not an anti-technology position.

It is a complexity budget.

Every service you add has to be deployed, monitored, upgraded, understood and eventually debugged.

I would rather spend that complexity on something that creates value for the product.

But I am not dogmatic about simplicity

There is an important difference between simple and under-engineered.

A SaaS with multiple users, background jobs, integrations and significant amounts of data may genuinely need PostgreSQL, Redis, workers and proper infrastructure.

Likewise, a growing application may eventually need to split responsibilities into separate services.

I am happy to do that when the problem justifies it.

I just don’t want to start there.

Architecture should follow the problem, not the other way around.

I can work on an existing product

You don’t need a greenfield project for us to work together.

In fact, a lot of useful work starts with:

“This application works, but…”

Maybe:

• deployments are painful
• a background job occasionally fails
• an integration keeps breaking
• a database query is getting slow
• nobody understands part of the codebase
• customers are doing too much manually
• a process requires someone to copy data between systems
• the team is spending too much time maintaining something that should be simple
• you need a feature but don’t have the backend capacity to build it

These are all problems I am comfortable getting into.

I don’t need the codebase to be perfect before I start.

But I do want to understand what is actually causing the problem before proposing a solution.

What I expect from the people I work with

I work best with people who can explain the business problem, even if they cannot explain the technical solution.

You don’t need to tell me which framework to use.

Tell me:

“Our sales team spends three hours every Friday preparing this report.”

That’s useful.

Or:

“Every time a customer signs up, someone has to enter the same information into three systems.”

Even better.

We can figure out the software.

I also expect honesty about constraints.

If the budget is €5,000, let’s design for €5,000.

If the deadline is real, let’s discuss what can be removed.

If something isn’t worth building, I’d rather say that early than invoice you for discovering it six months later.

What you can expect from me

I am usually the person doing the work.

I don’t sell a project and then disappear behind a project manager.

If we need additional developers or specialists, we can work that out depending on the project.

You get someone who can go from:

business problem
      ↓
technical design
      ↓
implementation
      ↓
deployment
      ↓
maintenance

without requiring five different people to move the project from one stage to another.

I also prefer leaving things in a state where someone else can take over.

That means documentation where it matters, sensible structure, migrations, tests around important behaviour and a setup that another developer can actually run.

The software belongs to you.

When you should contact me

You probably don’t need me because you need “a Python developer.”

Contact me if you have something more specific:

“We have a process that is costing us too much time.”

“Our SaaS backend needs work and our team doesn’t have the capacity.”

“We need to connect these systems.”

“We have an idea for an internal tool and want to know if it is worth building.”

“We have an existing application that has become difficult to maintain.”

“We need someone who can take a backend problem and own it from beginning to end.”

Those are much more interesting problems to me than simply filling another seat on a development team.

How we can work together

I am happy to work on a specific project or as additional engineering capacity for an existing team.

For a well-defined project, we can work on a fixed project basis.

For ongoing development or less predictable work, hourly or day-based work can make more sense.

Either way, I prefer starting with the problem rather than a technology proposal.

Tell me what is currently painful, what it costs you, and what “fixed” would look like.

I’ll help work out what should actually be built.

Email me or book 30 minutes.

And if I think you shouldn’t build it, I’ll tell you that too.