Slow pages or APIs
Trace time spent in Rails, rendering, serialization, external services, and avoidable application work.
ServicesRuby on Rails performance
Ruby on Rails performance consulting
Ruby on Rails performance
optimization service.
I help teams diagnose and fix slow Ruby on Rails applications—from expensive PostgreSQL queries and overloaded Sidekiq jobs to slow requests and memory pressure. Start with production evidence, ship the highest-value safe changes, and measure the result.
“Improve performance” is an easy claim to make. I make my work inspectable. You can review the query profiles and plans, benchmark methodology, regression tests, pull requests, and client outcomes behind it. I clearly separate production client results from benchmarks of open-source contributions.
01 / When to bring me in
Your team knows it is slow.
The cause is less obvious.
This service is for established Rails products with observable production symptoms and a team ready to review and ship focused improvements. If you are still diagnosing the problem yourself, start with my Rails performance optimization guide
Queries that no longer scale
Investigate query plans, missing indexes, N+1 queries, large scans, joins, counts, and Active Record usage.
Queues falling behind
Examine Sidekiq or Active Job throughput, batching, retries, query volume, and worker memory.
Memory or infrastructure pressure
Find allocation-heavy paths, oversized workloads, ineffective caching, and configuration bottlenecks.
02 / Production result
The production symptom
A dashboard taking
over two seconds.
The delay was visible in a real production workflow—not an isolated microbenchmark. The first job was to trace the complete data path before changing code.
Dashboard load time
2s+
<200ms
Baseline90%+ reduction
Before2s+→After<200ms
03 / Work you can inspect
Case Studies
Evidence, implementation, and regression coverage.
These Rails performance case studies show the original bottleneck, the code-level approach, and the measured result.
Browse all case studiesReducing role queries across Forem’s role-heavy paths
An open source Rails performance optimization that made role checks association-aware across Forem’s admin member list, CSV export, async user payload, and reCAPTCHA service.
Read case study↗
Making Forem’s cold analytics backfill 10× faster
An open source Rails performance optimization that replaced per-article analytics recomputation with bulk SQL aggregation, cutting median backfill time by 90.1%.
Read case study↗
Removing per-product queries from Gumroad’s Products API
A co-authored open source Rails performance fix that batch-loaded product serialization data, cutting mean response time by 40.4% and SQL events by 77.7%.
Read case study↗
Complete archive
↗
Rails performance, PostgreSQL, security, and open-source work.
Browse every
case study.
04 / What you receive
Not just a report.
Reviewable, measured progress.
The evidence determines how time is divided between diagnosis and implementation. You can see what changed, why it changed, and whether it worked.
Baseline and diagnosis
Agreed target metrics plus the profiles, traces, logs, or query plans that identify the expensive path.
Implementation
Reviewable Rails code, tests, benchmarks, configuration, and safe database migrations for improvements that fit the engagement.
Results and handoff
Before-and-after measurements, deployment support where applicable, and a prioritized roadmap for useful remaining work.
05 / How the work runs
A focused ten-day path
from symptom to evidence.
Access and targets are prepared before the paid block so the engagement can concentrate on technical work.
- Define
Agree on the workload and baseline
Connect the production symptom to its user or business impact, choose the relevant metric, and capture a comparable starting point.
- Investigate
Profile before changing code
Follow the evidence through Rails, Active Record, PostgreSQL, jobs, caching, and external services.
- Implement
Ship the best-supported fixes
Prioritize by likely impact, confidence, risk, and effort; deliver changes through your normal pull-request workflow.
- Validate
Measure and hand off
Compare completed work with the baseline and document results, trade-offs, deployment considerations, and next steps.
06 / Who you work with
Expert judgment.
Hands-on Rails delivery.
I am Haseeb Annadamban, a software engineer working with production systems since 2016 who works as a Rails performance consultant. Rails and PostgreSQL are my deepest application stack, and I work directly with your team—there is no agency handoff.
Years in production software
Work across established SaaS products where performance, reliability, security, and maintainability have real consequences.
User-scale SaaS experience
Product and infrastructure work on a platform serving more than one million users, alongside focused consulting engagements.
+ PG
Application and database depth
Requests, Active Record, PostgreSQL, Sidekiq, integrations, memory-intensive workloads, testing, and deployment.
07 / Practical details
Clear terms
before we start.
What happens during the service?
We agree on the affected workload and a measurable baseline, profile the bottleneck, implement the highest-value safe changes, and compare completed work with the original metric. The engagement ends with a technical handoff and a prioritized list of remaining opportunities.
Do you fix Rails N+1 queries and slow database queries?
Yes. N+1 queries, missing or misaligned indexes, large scans, and expensive Active Record patterns are among the most common production bottlenecks I fix. I confirm the expensive path from production evidence before changing code, and validate each fix against the original metric.
Can you optimize Rails background jobs and memory usage?
Yes. The work covers Sidekiq and Active Job throughput, queue latency, batching and retries, worker memory, allocation-heavy code paths, and ineffective caching. If the fastest win is in Rails requests or PostgreSQL instead, the evidence determines where time goes.
What does the $6,000 cover?
The initial commitment is 80 paid hours at $75 USD per hour. Those hours cover the agreed investigation, implementation, validation, documentation, and handoff. Additional work happens only by mutual agreement. If the original work finishes early, remaining hours can be used for other agreed performance work; unused hours are not refunded or carried forward.
Is the initial call free?
Yes. The initial discovery call and fit check are free. Paid time begins only after we agree to proceed.
How are improvements measured?
The metric depends on the problem and may include request latency, database execution time, query count, job throughput, queue latency, memory, allocations, or error rates. Completed changes are compared with an agreed baseline wherever reliable measurement is possible.
Can you guarantee a particular improvement?
No responsible consultant can guarantee a percentage before measuring the application. I explain what the evidence supports and provide before-and-after results for completed changes wherever the environment permits.
How is this different from a Rails performance audit?
A broad audit usually surveys the application and emphasizes findings. This engagement starts with observable production problems and reserves time to implement and validate fixes, not only recommend them.
Free fit check · 80 hours · $6,000 USD
Tell me what is slow
and why it matters.
I will help you decide whether this is the right first engagement before you commit.
Discuss your Rails app