Blocking calls in async code
A synchronous library called inside an async endpoint, which quietly serializes every request on the worker.
[ Development / Python & FastAPI ]
Python APIs that are fast and hard to misuse.
FastAPI gives you type validation, async handling and generated documentation almost for free. Most of the value is in using those properly rather than reproducing older Python habits inside a newer framework.
Typed and tested · Docs generated · Fixed scope
Typedend to end
Autogenerated API docs
Asyncwhere it actually helps
Testsincluded
[ What I fix ]
Where Python services struggle.
Python is not slow. Blocking calls inside async handlers are slow, and they look identical in the code.
No validation
Dictionaries passed around untyped, so malformed input surfaces deep in the call stack as a confusing error.
Slow database access
Queries in loops and missing indexes, unnoticed until data volume grows past a few thousand rows.
Dependency chaos
No lock file, so the environment differs between machines and a rebuild changes behavior.
Heavy work in the request
Report generation and model inference handled inline, so requests time out under load.
No observability
Print statements instead of structured logs, so production issues are diagnosed by guesswork.
[ How it works ]
Scope, build, ship.
01 — Week 1
Scope
Endpoints, data model, expected load and integrations agreed in writing, with a fixed price and delivery date before development starts.
02 — Week 2+
Build
Typed models, async where it genuinely helps, tests alongside the code, and generated API documentation from day one.
03 — Launch
Deploy
Containerized and deployed through a pipeline with health checks, metrics and structured logs already in place.
[ What actually changes ]
What gets built.
Typed at the boundary and observable in production. Everything else is application detail specific to your problem.
The service
- Typed request and response models — validated at the edge, with clear errors for bad input.
- Async done correctly — genuinely non-blocking, with synchronous libraries kept off the event loop.
- Generated API documentation — interactive and always current, because it comes from the code.
- Database layer — migrations, connection pooling, indexes and no queries hiding inside loops.
- Background processing — long-running work moved to workers with retries and visibility.
Production readiness
- Authentication and rate limiting — sensible defaults rather than an afterthought before launch.
- Structured logging and tracing — correlated per request so incidents can actually be investigated.
- Reproducible environments — locked dependencies and a container image that builds identically every time.
- Test suite — covering the endpoints and edge cases that would cost you money if they broke.
- Load testing — run before launch at expected peak, with the results written down.
[ Example engagement ]
An async API that was accidentally synchronous.
A service handling a fraction of its expected traffic. Every endpoint was async, but a blocking client library serialized all of them onto one worker thread.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
8xthroughput increase
1library swapped
2 daysto find and fix
0endpoints rewritten
[ Free · no obligation ]
Get a scope for your API.
Describe what the service needs to do and the load you expect. You get a written scope, a fixed price and a delivery date.
[ Pricing ]
Pricing that fits your budget.
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Fixed project price
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
Monthly retainer
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
Hourly for small jobs
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Common questions.
FastAPI, Django or Flask?
FastAPI for APIs and services, where typing and async are worth real money. Django when you want an admin interface and a full framework out of the box. Flask mainly when a codebase already uses it.
Can you work with our data science team?
Yes, and it is a common arrangement — they own the models, I build the service around them so inference runs reliably in production with sane latency and failure handling.
Do you handle deployment?
Yes, including containerization, pipeline and infrastructure. Since I do the AWS side too, the service and its environment are designed together.
Is Python fast enough?
For the overwhelming majority of APIs, yes — the bottleneck is almost always the database or an external call, not the language. If you genuinely need raw throughput, I will say so rather than pretend otherwise.
Can you take over an existing codebase?
Yes. I start with a review and an honest assessment of whether to improve or replace it, with the cost of each option laid out.
[ Related services ]
Related development work.
AI RAG ChatbotAssistants that answer from your documents, with citations.Node.js DevelopmentAPIs, services and background workers that stay up.LLM & AI IntegrationAdd AI features to an existing product, safely and affordably.Docker & ContainersContainerise an existing app so environments finally match.AWS Server SetupProduction-ready VPC, compute, database and CI/CD from scratch.CI/CD & GitHub ActionsAutomated build, test and deploy pipelines with real rollbacks.
[ Let's talk ]
Tell me what you're building.
Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.