Slow critical paths
Selected requests take seconds while average dashboards still look acceptable.
Services
.NET performance and reliability
Find the production bottleneck before another workaround becomes permanent.
I investigate slow, unstable or expensive .NET systems across application, database and cloud boundaries—then provide evidence-backed corrective actions and a verification plan.
10–20 focused hours*
Typical delivery window: 1–3 weeks
Scope confirmed after discovery
Europe · International remote
* Typical range for a focused investigation. Final effort and delivery window depend on system size, complexity, access and the affected flows, and are agreed before work begins. The fee covers the agreed outputs—not continuous full-time work throughout the delivery window.
Describe the problemWhen this is useful
For production problems that cross layers or resist routine debugging
Load-sensitive failures
Timeouts, retries or concurrency failures appear only under production load.
Uncontrolled cloud cost
Cloud cost is growing faster than traffic or customer value.
Data inconsistency
Data becomes inconsistent across services, queues or scheduled processing.
Recurring incidents
Fixes address symptoms rather than the failure path, so the same class of incident returns.
Scope
What I examine and deliver
The investigation follows a representative failure or slow path end to end, correlating behaviour across code, queries, infrastructure and dependencies.
- Reproducible baseline and evidence collection plan
- Cross-layer root-cause analysis
- Query, cache, concurrency and dependency findings where relevant
- Prioritized corrective actions with risk and expected impact
- Implementation and verification plan
- Optional focused remediation sprint
Process
A focused path from evidence to action
- 01
Define the symptom
Select the affected workflow and establish a representative baseline.
- 02
Instrument the path
Correlate traces, queries, logs, resource use and dependency behaviour.
- 03
Prove the cause
Test the smallest credible hypotheses and reject misleading correlations.
- 04
Correct and verify
Prioritize changes and define the measurements that prove improvement.
Expected outcomes
A verified cause and a controlled route to improvement
A clear explanation of where the failure begins and how it propagates.
Changes ranked by impact, implementation risk and verification cost.
A baseline and production signals the team can use after the engagement.
2–4s → 90–200ms
Selected enterprise queries improved through serverless design, Redis caching, database optimization, concurrency changes and infrastructure right-sizing.
Frequently asked questions
Practical questions before we start
Direct answers about fit, access, scope, delivery and working arrangements.
Can you guarantee a specific performance improvement?
Not before evidence identifies the limiting constraint. I define a measurable baseline first, then rank changes by expected impact and confidence.
Do you only investigate application code?
No. The relevant path may include .NET code, SQL, caches, queues, cloud resources, network calls and external integrations.
Can you implement the fix?
Yes, when the cause and change boundary are clear. That work can continue as a focused implementation sprint with tests and verification.
What access is usually required?
Relevant repositories, representative telemetry, deployment context and a technical contact who understands the affected business flow. Access can be read-only where appropriate.
Is the investigation suitable for an active incident?
It is best for urgent but structured investigation. Live emergency response requires separate availability and access arrangements.
Start with the real constraint
Bring the slow or unstable workflow—not a predetermined solution.
Describe the symptom, business impact and evidence already available. I will assess whether a focused investigation is a good fit.
Describe your engineering problem I usually reply within one business day.