Work with me

Bring a technical decision that matters to your product, team or company. We can work on making the problem clearer, gathering the evidence it needs, and choosing a practical next step.

The starting point might be an application that slows down under load, an architecture that has become difficult to change, a data pipeline whose outputs are hard to trust, or an AI proposal that looks convincing but leaves important questions unanswered.

I am interested in work where engineering detail and business consequences need to be considered together. The areas below describe possible engagements. We would agree the scope, access, responsibilities and deliverables before work begins.

Architecture and AI application design

For engineering leaders and teams deciding how an application should evolve, an architecture engagement can examine the requirements, boundaries and operating assumptions behind the current design.

The focus can include .NET and Azure applications, service boundaries, integration patterns, failure handling, and the introduction of AI capabilities into an existing product. For agent-based workflows, the important questions include what the agent may do, how its work is evaluated, and which decisions require human authority.

A useful starting scope could produce a map of the relevant system, a small set of documented decisions, and a prioritized proposal for the next change or experiment. If a reference implementation would resolve a specific uncertainty, we can include it with explicit acceptance criteria.

The work should help the team understand why a design fits its situation and what would justify revisiting it.

Performance and telemetry

For a team facing slow responses, uneven throughput or unexplained resource use, a performance investigation starts by defining the behavior that matters to users and the conditions under which it occurs.

Possible areas include application code, database access, concurrency, allocation behavior, dependency calls and the overhead of instrumentation itself. Telemetry work can examine whether traces, metrics and logs expose the relevant boundary clearly enough to support a diagnosis.

An initial engagement could establish a reproducible workload, a measurement plan, and a ranked set of hypotheses. Where the evidence supports a change, the scope can include a bounded implementation and a comparison against the original conditions.

The deliverable should explain what was measured, which explanation the evidence supports, and what remains uncertain. We would agree the target and the acceptance conditions before making claims about improvement.

Data systems and dependable information

For applications handling substantial data volumes, the challenge often extends beyond moving records quickly. The team needs to understand lineage, definitions, freshness, failure recovery and the behavior of the system when work is repeated or interrupted.

We can examine an ingestion path, database workload, processing pipeline or reporting boundary. For AI systems using organizational documents, the scope can include how source versions, permissions and missing context affect the answers the application is allowed to provide.

A possible outcome is a documented path from input to decision, with the important contracts, failure modes and observations made explicit. A reference build or focused experiment can help resolve a question that documentation alone cannot answer.

The aim is to make the system's behavior understandable enough that the team can operate it and decide what to change next.

Technical diligence for founders and investors

Technical diligence can help connect a company's product claims with the evidence in its architecture, software, operating practices and team responsibilities.

The work might examine a specific investment question, a proposed acquisition, a major technology commitment, or a founder's plan for the next stage of the product. The emphasis is on the uncertainties that could change the decision: dependency concentration, operating obligations, maintainability, data assumptions, and the gap between a demonstration and a dependable service.

A scoped review can produce an evidence-based assessment, questions for the relevant owners, and a prioritized set of follow-up investigations. Conclusions should distinguish observed facts, management representations and unresolved assumptions.

This is a technical advisory conversation. Its value lies in making the decision better informed and the remaining uncertainty easier to understand.

Workshops built around real decisions

Workshops can give a team shared language and a practical method for a topic it needs to use. Possible themes include AI-assisted engineering, agent acceptance criteria, .NET performance investigation, telemetry design, and architecture decisions for Azure applications.

The format should follow the audience. Engineers may benefit from a bounded laboratory exercise. Technical leaders may need a decision workshop around competing options. Founders may need to connect a product promise with the engineering and operating work it creates.

Before designing a session, we would identify what participants should be able to decide or do afterward. The materials can include a worked example, an exercise and a concise set of follow-up actions. Any laboratory result would remain clearly separate from a claim about a production system.

How a conversation becomes a scope

Start with the situation, the decision and the constraints. Explain what is happening, why it matters now, what has already been tried, and what a useful outcome would allow you to do.

From there, we can identify the evidence available and the smallest meaningful engagement. That might be a focused review, a workshop, an investigation or a bounded implementation. Access to systems and data should follow the agreed work, with clear ownership of decisions and changes.

The handoff should leave something the team can use: findings with supporting evidence, a decision record, a reproducible experiment, or a prioritized next step. The exact deliverables belong in the scope rather than in a generic promise.

Contact me on LinkedIn with a short description of the problem, the people involved and the decision you need to make. That is enough to begin a useful conversation.