Your backend is slow. I find what is actually slow, and fix that.
Three weeks on the request path that is hurting you: profiling under real traffic, the fixes shipped as reviewable pull requests through your own pipeline, and the same load test run before and after so the improvement is a number instead of a feeling. The Prometheus metrics and Grafana dashboards stay with you.
Fixed price, no hourly surprises. Delivered in 3 weeks. Paid in three milestones, you release each one only when you approve it.
How it works
Measure first. Fix what the numbers point at. Prove it with the same load test.
Three weeks, three milestones, aimed at the request path that is actually failing: one API or service plus the databases, caches and downstream calls behind it. I do the profiling, the fixes and the load tests. What I need from you is read access to the code, a staging environment or another safe way to run representative load, and one engineer who can answer questions about the system.
I profile it under real load
Instrumentation on the hot path: CPU, heap and blocking profiles, request traces, the slow query log and the query plans behind it, plus a baseline load test on a profile we agree up front.
I fix what the numbers point at
Slow and N+1 queries, missing indexes, connection pool sizing, caching the things that actually pay, blocking calls moved off the request path. Each one a pull request through your normal pipeline.
I prove it, then hand it over
The after load test on the same profile as the baseline, Prometheus metrics and Grafana dashboards with alerts on the paths that were failing, documentation, handover.
What you get
One engagement. Measured, fixed, proven.
Not an audit that stops at a document, and not a pile of changes nobody can verify. Both halves, in the same three weeks, on your own infrastructure.
A ranked list, with the cost of each
- Profiling under real traffic, not a synthetic benchmark: CPU, heap and blocking profiles, request traces on the hot path, the slow query log and the query plans behind it
- A baseline load test on a load profile we agree up front, so every number that comes later is compared against the same run
- Findings ranked by measured cost, each one with what it costs on the hot path, not a checklist of best practices
- The infrastructure answer too, because if the sizing of your database or your instances is the real limit, the findings say so
- Written down, not delivered in a call, so your team still has it after I am gone
The fixes, as pull requests
- Slow queries and N+1, found in the profile and the query log rather than guessed at from the ORM
- Indexes, added where the query plan proves one is missing, dropped where one only costs you writes
- Pool sizing, timeouts and limits, so a traffic spike queues and sheds instead of falling over
- Caching where it pays, on what is hot and safe to cache, with the invalidation written down
- Blocking calls off the hot path, moved behind a queue, a background job, or a timeout that fails fast
- Every change reviewable: a pull request through your normal pipeline, carrying the measurement that justifies it
The proof, and the instruments
- The after load test on the same profile and the same data volume as the baseline, so the comparison is honest
- Prometheus metrics on the paths that were failing, in your own code
- Grafana dashboards as JSON in your repository, not in an account I control
- Alerts on those paths, so the next regression is visible before a customer reports it
- The load test scripts, so you can re-run the comparison whenever you want
- Documentation and handover: what changed, why, and what to watch from here
I have done this where the latency budget was the product.
Not a methodology deck. Actual work, on systems where slow meant lost money.
Real-time bidding
At Traffichaus, a real-time bidding advertising network, I built a custom RTB endpoint and kept it fast under heavy unique traffic, through code and infrastructure changes both. RTB has one of the tightest latency budgets in the industry: answer in time or the bid does not count.
Backends and Kubernetes
Backend and microservices work at Cisco on Kubernetes with Prometheus, including moving a Java service to Go. Prometheus has been in my stack across jobs since, and Go and Python are what I write today.
Databases, plural
Polyglot database work at Ebbot across MySQL, PostgreSQL, MSSQL and MongoDB, plus Redis elsewhere. Most backend performance problems turn out to be database problems in an application’s clothing.
This is a rescue, not a rewrite.
One fixed price for all of it: the profiling, the baseline load test, the fixes, the after load test, the dashboards and the handover. No hourly billing, no discovery fee, no subscription afterwards. Scope is the request path that is failing: one API or service and the databases, caches and downstream calls behind it. A second service or a second path is quoted up front as its own engagement, never as surprise scope.
- 1
Profiling and findings $2,500
Instrumentation and profiling under real traffic, the baseline load test, and a written list of what is actually slow, ranked, with the measured cost of each.
- 2
The fixes $4,000
The fixes you approve, implemented as reviewable pull requests through your normal pipeline, each with the measurement that justifies it.
- 3
Load test and handover $1,500
The after load test on the same profile as the baseline, Prometheus metrics and Grafana dashboards with alerts on the paths that were failing, documentation, handover.
Paid in three milestones. Each one is agreed before it starts and paid only when you approve its deliverable, so you never pay up front for work you have not seen.
Why not the obvious fix
Bigger servers buy you months. Measurement buys you the fix.
Throwing hardware at it
It works, right until it does not, and you pay the bigger bill every month in between. A query that scans the whole table scans a bigger table next quarter. Hardware moves the wall, it does not remove it. Sometimes sizing really is the answer, and if that is what the measurements say, you will hear it from me and the bill will be smaller.
Rewriting in a faster language
Months of work, a frozen feature set and a fresh set of bugs, aimed at a bottleneck that is usually not the language. Waiting on a database, a lock or a downstream call takes the same time in any runtime. Measure first and the rewrite often turns out to have been the wrong answer to the right complaint.
Hiring a senior for it
A hiring cycle and then a salary, for something that is three weeks of work. And the dashboards and alerts that come with this engagement are the part a new hire would have had to build before they could even start.
The fixes are yours. So is the proof.
Everything lands in your repositories
The fixes as pull requests, the dashboards as JSON, the load test scripts and the findings document, all of it handed over. Nothing I write for you lives in an account I control. My open-source work is on my GitHub if you want to read how I write before you hire me.
Runs on your infrastructure
Profiling, load tests, metrics and dashboards all run inside your environment, on tools you already have or can run for free. No agent from a vendor, no data leaving your network, no per-host pricing arriving six months later.
Paid in phases, never up front
Three milestones, each agreed before it starts and paid only when you approve its deliverable. Direct B2B, on your own contract and invoicing.
No retainer, no subscription
A one-shot engagement. It ends, you keep the fixes and the instruments, and there is nothing to cancel. More work later is a new engagement at a price agreed then, not a standing bill.
Straight answers
What does the price cover?
The whole engagement: profiling under real traffic, a baseline load test, a written and ranked findings list, the fixes you approve shipped as pull requests, the after load test on the same profile, Prometheus metrics, Grafana dashboards, alerts on the paths that were failing, the load test scripts, documentation and handover. Scope is one request path: an API or service plus the databases, caches and downstream calls behind it. Anything beyond that is quoted up front as its own engagement.
How does payment work?
In three phases: profiling and findings ($2,500), the fixes ($4,000), load test and handover ($1,500). A phase is agreed before it starts and paid when you approve that phase’s deliverable, so you are never paying up front for work you have not seen. If the findings tell you the remaining work is not worth doing, you can stop after the first phase and keep the measurements.
How do we actually engage?
Direct B2B, on your own contract and invoicing, which suits most companies that already have a procurement process. Reach me on LinkedIn and we sort the terms. If your policy wants an NDA signed before we talk specifics, that is fine.
What do you need from my team?
Read access to the repository, read access to whatever metrics and logs you already collect, permission to add instrumentation, and a staging environment or another safe way to run representative load. Plus one engineer who can answer questions about what a table or an endpoint means in your business, and whoever normally reviews and merges pull requests. It starts with one scoping call to agree the path we are fixing and the load profile we measure against.
Is this a rewrite? Will you change our architecture?
No. This is fixing what is there, inside your existing code, framework, database and architecture. No rewrite, no migration to a different stack, no cloud migration. If something in the findings genuinely cannot be fixed without a rewrite, you get it written up with an estimate of what that would cost, and the decision stays yours. I will not start one on my own initiative.
What if we have no staging environment?
There are usually workable options: stand one up from your own infrastructure as code for the duration, use a copy with a representative data volume, or run the load against one instance pulled out of rotation. Profiling itself can often run read-only in production when the overhead is acceptable and you approve it, but the before and after load test needs somewhere safe to push. If none of that is possible for you, I will say so before you pay anything, rather than take the money and deliver half the engagement.
What if the real problem is our infrastructure, not our code?
Then the findings say that, with the measurement that shows it. An undersized database instance, a connection limit, a noisy neighbour, a disk that cannot keep up: those are findings too. It means your fix may cost less than this engagement did, and you will hear it from me in the first phase rather than after three weeks of code changes that were never going to be the answer.
Is my data safe? Can you break production?
Profiling reads, it does not write. I do not deploy: every change is a pull request your team reviews and merges through your own pipeline, on your schedule. Load tests run against staging or a representative copy, never against your customers, and any instrumentation that touches production is agreed with you before it goes near it. Nothing leaves your network, because everything involved runs inside it.
Which languages and databases?
I write Go and Python today, earlier in my career I shipped PHP backends including the RTB endpoint, and I spent a year porting NodeJS microservices to Go. On the database side: PostgreSQL, MySQL, MSSQL, MongoDB and Redis. The measurement half is not language specific, profilers, traces, query plans and load tests work the same everywhere, so if your backend is in something else I will tell you on the scoping call whether I can implement the fixes in your stack or whether it is better scoped as findings plus review alongside your own engineers.
Can you promise it will be X times faster?
No, and nobody honest can before measuring. What is promised is the measurement: a baseline run, a ranked list with the cost of each finding, the fixes you approve, and the same load test afterwards so you can see exactly what moved. If the first phase shows the available headroom is small, you hear that before phase two starts, and you can stop there.
What happens after handover, and do I own all of it?
You own all of it. The fixes are merged in your repositories, the dashboards and alerts are running on your infrastructure, the load test scripts and the findings are yours to keep. There is no retainer, no subscription and nothing to cancel. Re-run the load test after your next big feature and compare it against the same baseline, which is the point of leaving the scripts behind. If you want me again later, that is a new engagement, never an automatic renewal.
Tell me what is slow.
This is for teams whose backend is in production, making money, and buckling at peak. Send me what it runs on, what times out, and what your traffic does in its worst hour. We get on a call, I scope it, and three weeks later you have the measurements, the fixes merged through your own pipeline, and the dashboards to see the next one coming.
Direct B2B, on your own contract and invoicing. Reach me on LinkedIn and we sort the terms. Fixed price, three milestones, no platform in the middle.