L2/L3 staff augmentation for a B2B SaaS company: p95 latency down from 3.8 seconds to 640 milliseconds
A US B2B SaaS company engaged TechSupport Team for a one-engineer L2/L3 performance pilot on its Node.js and PostgreSQL customer API. The pilot followed the standard onboarding and drill, confirmed the causes with evidence and grew into a three-engineer staff augmentation engagement.
Summary
TechSupport Team supplied one L2/L3 support engineer to a US B2B SaaS company for its slow Node.js and PostgreSQL customer API, under the client's support team lead. Over the 12-week pilot, p95 latency fell from 3.8 seconds to 640 milliseconds, according to the client's own monitoring. The client kept release approval and production change control, then added two engineers after the pilot.
Engagement facts
| Fact | Value |
|---|---|
| Industry | B2B SaaS, workflow software |
| Client location | United States, anonymized region |
| Application type | Customer-facing API with background workers and a Vue front end |
| Stack | Node.js, Vue, PostgreSQL, Google Cloud, Kubernetes |
| Roles supplied | One L2/L3 support engineer for the pilot, then two additional L2 (second-level) engineers |
| Seniority | Senior engineer for the pilot; mid-level and senior for the expansion |
| Engineer count | 1 during the pilot, 3 after expansion |
| Engagement duration | Pilot of 12 weeks, ongoing after expansion |
| Coverage hours | Business hours of the client's team, eight hours a day, five days a week |
| Time zones | One US time zone, aligned to the client team |
| Reporting line | The client's support team lead assigned tickets and set priorities |
| Model | Staff augmentation: dedicated engineers under the client's direction |
Why the client needed engineers
The client's customer-facing API slowed every afternoon until background jobs and interactive requests competed for the same PostgreSQL connections. The same performance complaints returned after each restart, and product engineers were being pulled off roadmap work to investigate. The baseline at assessment was 23 performance-class incidents per month and a p95 latency of 3.8 seconds at the afternoon peak.
The client chose staff augmentation over a managed service to keep ticket assignment, release approval and production change control in-house. It also wanted to judge an external engineer on real work before committing to a team. A one-engineer pilot on one application and one incident class made the effect measurable.
Team composition and responsibilities
One senior engineer carried both L2 diagnosis and L3 (third-level) code changes because the incident class was agreed in advance. The client's support team lead assigned tickets and set priorities in the client's tracker. The client's engineering lead reviewed every pull request, approved the maintenance windows and owned all production changes. The client owned customer communication throughout.
Selection and onboarding
Role brief and interviews
The client interviewed two proposed engineers and selected one. Time from signed agreement to first shift was ten business days.
Access and runbook review
Named accounts, least-privilege access and a runbook review were completed in the first week; gaps went into the assessment record.
Shadowing and drill
The engineer shadowed two real incidents, then passed an incident drill covering triage, evidence collection and escalation before working independently.
Independent work
The client approved independent incident work after the drill, about two weeks after the first shift. Productive contribution on the incident class was visible from week three.
Technical work performed
- Reproduced the afternoon slowdown in staging and captured PostgreSQL query plans and connection-pool metrics.
- Confirmed three causes: sequential scans on the largest tenant table, lock contention between workers and a connection pool sized below peak demand.
- Prepared an index migration for the largest table with rollback steps, reviewed through the client's normal code review.
- Resized the connection pool with load evidence and added an alert on pool exhaustion.
- Wrote a daily incident record and updated the runbook for the performance class after each confirmed cause.
One representative incident
- Intake
Monitoring flagged p95 latency above the agreed threshold for over an hour, with background jobs and interactive traffic competing for database connections.
- Investigation
The engineer captured query plans during the slowdown and found a sequential scan on the largest tenant table, plus a connection pool that emptied under peak load.
- Action
The pool resize was prepared as a configuration change with rollback steps. The index migration waited for the client's review and a low-traffic window.
- Approval
The client's engineering lead approved the pool change for the same day and scheduled the index migration for week 6.
- Restoration and permanent fix
Latency recovered to its pre-peak range after the pool change. The reviewed index migration in week 6 cut p95 latency at the afternoon peak from 3.8 seconds to 640 milliseconds.
Service recovered with the pool resize as a controlled change, and the index migration in week 6 removed the dominant cause. Performance incidents in this class fell from 23 per month at baseline to 4 per month over the pilot window.
Measured results
| Metric | Baseline | Result | Window | Sample | Source |
|---|---|---|---|---|---|
| p95 API latency at afternoon peak | 3.8 seconds | 640 milliseconds | 12-week pilot | All API requests except the endpoint changed in week 6; client application performance monitoring (APM) | Client monitoring export |
| Performance-class incidents | 23 per month | 4 per month | 12-week pilot | All tickets in the class | Client tracker export |
| Median time to confirmed cause | About two days | Under four hours | 12-week pilot | Tickets with confirmed cause | Incident records |
| Engineers on the account | 1 (pilot scope) | 3 (expanded scope) | Week 8 decision | Engagement record | Engagement record |
Evidence and limitations
The metrics come from the client's own application performance monitoring export and tracker records for the pilot window. A product release in week 6 changed one endpoint, so that endpoint is excluded from the before-and-after comparison. Ticket volume stayed within the assessment range, so the incident drop is not explained by a quieter queue. The client's head of support reviewed this case study before publication. Industry, size and identifying details are anonymized with client approval. The client retained release approval and production change control throughout.
Questions buyers ask
How long did onboarding take?
Ten business days from signed agreement to the first shift, including the client interview. The engineer worked independently after about two weeks, once the drill was passed.
Who managed the dedicated support engineer?
The client's support team lead assigned tickets and set priorities in the client's tracker. TechSupport Team handled employment, replacement and engagement logistics.
What access did the engineer receive?
Named accounts with least privilege: read access to logs and metrics, staging access and no standing production deployment rights. Production changes ran under client approval.
How did the expansion decision work?
The pilot agreement named the measures to review at week 8. The client compared the results against its own baseline and chose to add a second and then a third engineer.
Can these latency results be promised for another system?
No. The numbers belong to this system and window. Another engagement starts with its own assessment, baseline and pilot targets.
Contact us
Tell us which engineers you need, or ask a question. For a detailed request, use the engineer request form.
- We reply by email.
- We agree a call about the roles, your stack and the hours.
- If there is a fit, we propose engineers after an assessment.