Application Performance Optimization Services Contract engineers who profile, tune and fix the slow path
You already know the date. A rate move, a month-end close, open enrollment. Bring the engineers in while there is still time to change the code.
Application performance optimization services find where a slow request spends its time and fix it, through profiling, query and index tuning, cache and connection pool work, and load tests that prove the fix. KORE1 places contract performance engineers before a known spike.
Last updated: October 11, 2026
- This page
- Contract engineers who profile and tune the system you already run, timed against a date you can already see.
- Covered elsewhere
- The architecture for absorbing a surge is Kris Drouet’s four patterns that survive volume spikes. A permanent reliability seat is site reliability engineer staffing. A platform that is down right now is project rescue staffing.
Most slow systems are slow on a schedule. Lenders get it when rates move, finance platforms on the last three business days of the month, benefits platforms all through open enrollment and retailers from the week of Thanksgiving until well into December. None of it is a surprise. Almost all of it gets treated like one.
Here is how fast the schedule can move. In the week ending January 9, 2026, the Mortgage Bankers Association’s weekly applications survey had the refinance index up 40 percent in seven days, after an announcement about agency mortgage-backed securities purchases pulled the 30-year rate down to 6.18 percent. Nobody’s engineering team picked that week. Nobody ever does.
The work comes in bursts, and that is a budget problem before it is an engineering one. Our author Kris Drouet, a 25-year mortgage tech and fintech engineering executive, put it plainly. “A permanent headcount request for a two-month bulkhead project is a hard sell to a CFO who just watched rates move against the plan.” So the work goes to contract engineers on our W-2, placed by the contract staffing desk inside KORE1’s IT staffing services, for the weeks the run-up takes.
What Application Performance Optimization Actually Covers
Slowness is rarely spread evenly. Almost never. One request, one query or one lock usually carries most of it. The job is finding that one under realistic load, and then proving the fix holds when the load is three times worse.
- Profiling under traffic that looks like productionDistributed traces from your APM, whether that is Datadog, New Relic, Dynatrace or OpenTelemetry, then a CPU and wall-clock profiler on the hot endpoints. Async-profiler on the JVM, pprof in Go, py-spy in Python, dotnet-trace on .NET. The output is a flame graph, which Brendan Gregg built to show the most frequent code paths at a glance. Wide frames are where the time goes.
- Queries, indexes and the plans behind themMost of what we find lives here. An N+1 pattern the ORM hid, a missing composite index, a plan that flipped once a table crossed a few million rows. The tool is unglamorous. Read the plan with EXPLAIN, or its SQL Server and Oracle equivalents, and change one thing at a time.
- Connection pools, threads and the queue in front of the databaseA pool sized for a quiet Tuesday becomes a waiting room at three times the traffic. Requests stop being slow and start standing in line. It looks like a database problem. Usually it isn’t. Count the waiting, not the work.
- Caches, and what happens when they go coldHit rates, key design and invalidation. Then the stampede, when a popular key expires under load and two hundred requests rebuild it at once. Ugly.
- A load model, then a capacity test against itReal traffic mix, real data volumes, scripted in k6, Gatling, Apache JMeter or Locust, run until something breaks. Something always does. The breaking point is the number you bought.
When the profile says the problem is the shape of the system rather than a query, that is an architecture conversation, and Kris has already written the playbook for it. Most of the time it isn’t. It’s one frame. Find it.
Where 2,400 Milliseconds Go
One request, profiled at three times normal peak. Kris says the heaviest query in a lending system is always the pipeline dashboard, so that’s the one drawn here. Each bar is a function, and its width is the time it took. Read it from the bottom up.
BeforeGET /pipeline, p95, three times peak
AfterSame request, same load, same scale
- The slow path, root to the frame that carries it
- Everything else the request did
- The slowest frame left after tuning
- SELECT conditions ×212 1,390 → 85 ms One query per loan became one join for the whole page.
- db.pool.acquire 310 → 15 ms Pool sized to what the database can really serve, and the slow query stopped holding connections.
- calendar.lookup 160 → 10 ms The business-day calendar is cached now. It changes once a year.
- 2,400 ms
- p95 for the pipeline view at three times normal peak
- 58%
- of that request spent in a single frame
- 650 ms
- the same request after three fixes, same load
- 212 to 1
- queries per page view, before and after
Fifty-eight percent. One frame.
That is the usual shape. It’s also why buying more hardware so rarely works. The 212 queries in that red tower each took six or seven milliseconds, and none of them was slow. Not one.
A bigger database instance would have shaved a little off each query and left the page more or less where it was, at roughly twice the monthly bill, which is how a cloud bill quietly becomes an architecture problem. What fixed it was noticing that the ORM asked the same question once per loan on a page that shows two hundred loans. Boring. Effective.
Now look at the after graph. Something is always the slowest frame, and here it’s the rules engine at 250 milliseconds, outlined. It stays.
Why? The page sits well under its 800 millisecond budget, and a good engagement stops when the budget is met rather than when the profile is flat. Profiles are never flat. Ever.
Hired Before the Spike, or the Morning After the Outage
Same engineers. Same skills. Same rate card. What changes is what they are allowed to touch.
Six to eight weeks before
The morning after
What you can still change
BeforeQueries, indexes, pool sizes, cache design, even a schema change with time to test it.
AfterConfig, a rollback, and bigger instances. Nobody ships a migration mid-incident.
Who you can get
BeforeEngineers you interview, who start on a Monday you choose.
AfterWhoever is free this week, because everyone else’s spike is the same week as yours.
What gets tested
BeforeA capacity test at the planned peak, then past it, on purpose.
AfterProduction, by your customers.
What it costs
BeforeHourly engineers on a scope you can end early.
AfterThe same hours, plus the lost week, plus the instance upgrade nobody turns back down.
What you keep
BeforeA load model, a known breaking point and a written list of every change.
AfterA postmortem.
The right-hand column isn’t a failure of effort, and it usually shows up in what the on-call pager says about the architecture long before the outage. Not at all. Teams in it work brutally hard. They are just working inside the narrowest set of options they will ever have, and on a platform where a slow afternoon is measured in locked loans that didn’t lock, the bigger instance gets bought at 2 p.m. and stays on the invoice for a year because nobody wants to be the person who turned it back down.
The left-hand column only needs one thing. Somebody writes the date down. Early.
40%
week-over-week jump in mortgage refinance applications, week ending January 9, 2026
8.4%
more retail conversions from a 0.1 second faster mobile site
17 days
average days for KORE1 to fill an IT seat
92%
of KORE1 placements are still there a year on
Refinance figure from the MBA Weekly Applications Survey released January 14, 2026, which put the index 128 percent above the same week a year earlier. Conversion figure from Deloitte’s study for Google, summarized in the Milliseconds Make Millions case study, which tracked 37 brand sites and more than 30 million sessions and found 10.1 percent for travel sites. Hiring figures from Why KORE1.
Who We Put on the Slow Path
Two seats carry most engagements. The other two depend on what the first profile says. Sometimes neither.
- A performance engineer who reads profiles for a livingOwns the instrumentation, the profiling and the load model. The skill is narrowing. Fast. Anyone can find a slow endpoint on a dashboard. Finding the frame inside it, and knowing whether it’s CPU or waiting, is the seat.
- A database engineerPlans, indexes, lock waits. Vendor quirks too. On Postgres, SQL Server and Oracle this is close to half the hours, which is why we fill it from the same bench as database administrator staffing.
- A backend engineer in your runtimeGarbage collection pauses on the JVM, a blocked event loop in Node, thread pool starvation in .NET. Fixing a frame means changing code in your language, reviewed by your team, so this seat comes from backend developer staffing rather than from a generalist.
- A load test engineer, when the model is hardWorth adding when traffic is unusual. Rarely needed otherwise. Batch-heavy month-end jobs, partner APIs with their own limits, a mix that changes by the hour. For steady test automation after the date, see QA staff augmentation.
The interview tell is simple. We ask for the time a profile fooled them. Engineers who have done this for real always have one, usually a frame that looked like CPU and turned out to be lock contention, or a fix that made the benchmark faster and production slower. People who have only watched dashboards talk about tools instead.
Kris puts it more bluntly for lending platforms. “That knowledge is not in a book. It is scar tissue, and it takes roughly one refinance cycle to grow.” We agree.
On rates, our 2026 contractor rate guide puts a senior software engineer at a typical agency bill rate of $108 to $160 an hour, which is where performance work sits. A load test engineer usually bills nearer the $65 to $100 QA band.
How an Application Performance Optimization Engagement Runs Against a Date
Six to eight weeks for one platform, counted back from the day the volume arrives. The order matters, because step four is guessing if you skip step three.
- Write down the date and the peakThe rate meeting, the close, the enrollment window, and the multiple of normal traffic you expect. Kris plans lending platforms at three times normal peak sustained for a week. Pick your own number. Pick it in writing, because every later step is measured against it.
- Instrument the paths that carry the moneyTracing on the ten or so endpoints a customer is waiting on, plus the batch jobs that run at month-end. Two weeks of real traffic beats any synthetic guess about what users do. Every time.
- Profile the endpoints that cost the most in totalRank them by latency times volume, not latency alone. A 900 millisecond report run twice a day matters less than a 300 millisecond status call made forty thousand times an hour, because the status call is quietly holding the connections that everything else on the platform is waiting for.
- Fix the widest frame, one change at a timeChange one thing. Measure. Keep it or back it out. Batching three fixes into one deploy saves a day and costs you the knowledge of which one worked.
- Load test at the planned peak, then past itRun the model at the number from step one, then keep raising it until something fails. Google’s SRE book makes the point in its chapter on testing for reliability that components past a certain point often fail catastrophically rather than slowing down gracefully. Stress tests find that point on a calm day. Better then.
- Hold through the date, then hand it backThe engineers stay through the spike week watching the same traces they tuned against. Afterwards your team gets the load model, the breaking point and a written list of every change. Then the contract ends.
If the date is close and the list is long, step four is where a second engineer pays for itself. If the profile turns up a structural problem rather than a slow frame, the conversation moves to a statement of work with its own scope. And if the platform hasn’t been read by an outsider in years, a code audit first is usually cheaper than profiling blind.
Four Ways to Put Performance Engineers on It
Choose by how close the date is and how well you already know where the time goes. The paperwork differs. The bench is the same one.
One seat
A performance engineer
One engineer, six to eight weeks, one platform, profiled and load tested.
Contract staffingSmall pod
Performance plus database
Two or three engineers when the date is close or the database carries most of the time.
Project staffingFixed scope
A capacity test on a SOW
A load model, a breaking point and a report, priced as deliverables rather than hours.
SOW staffingConvert
Hire the one who tuned it
The engineer who tuned your platform knows it better than anyone you could recruit next quarter.
Contract-to-hire
Common Questions
What do application performance optimization services include?
Profiling, tuning and proof, in that order. Engineers trace the requests customers wait on, find the frames where the time goes, fix those frames in queries, pools, caches or code, and then load test the result against the traffic you expect. The proof is the part people skip.
How far ahead of a busy period should we start?
Six to eight weeks before the date is the comfortable window for one platform. That leaves two weeks to instrument and profile, two to three to tune, and time for a capacity test with room to fix what it finds. Three weeks still works. Only just, and only for config and query fixes.
Why not just move to a bigger database instance?
Sometimes that is the right call, and a profile tells you when. More often the time is going to a query pattern rather than a busy server, and a page that makes 212 small queries stays slow on a bigger instance because each of those queries was already fast. You pay roughly twice as much. It stays slow.
How much do contract performance engineers cost?
$108 to $160 an hour is the typical agency bill rate for a senior software engineer in our 2026 rate guide, and performance work sits in that band. A load test engineer usually bills nearer the QA range. Two engineers for six weeks is the common shape. Sometimes one.
Do the engineers need access to production?
Read access to your monitoring, yes, but write access to production almost never. Profiling runs against real traces from your APM, and the load tests run in a staging environment sized and seeded like production, which is often the longest lead item in the whole engagement because somebody has to copy and mask the data. Start it first.
Is this different from hiring an SRE?
Yes, because an SRE is a permanent seat that owns reliability every week of the year, including alerting, on-call and error budgets. A performance engagement is a time-boxed push on speed and capacity against one date. Plenty of teams need both. The engagement shows the SRE what to own next.
What do we have when the engineers leave?
A load model you can rerun, the breaking point it found, and a written list of every change with its before and after timings. That list matters most. Really. Without it, the next team to touch the slow path quietly undoes half the work within a year.
Tell Us the Date and the Number
Send us the date the volume arrives, the multiple of normal traffic you expect, and the stack it runs on. Within a couple of days you have performance engineers to interview, what each of them bills, and a start date that still leaves room before yours.
Staff a Performance Engagement →Or call 949-706-6990
