Contracting & technical consulting
I help teams turn difficult software, simulation, and integration problems into working capabilities with clear evidence and a practical handoff.
Discuss your projectYou need more than an isolated feature: an integration that holds up, a prototype ready for its next stage, or a difficult failure made understandable.
Translate stakeholder conversations into requirements, interfaces, priorities, and acceptance criteria. Make assumptions and tradeoffs visible before they become expensive.
What this producesProblem brief · interface map · acceptance plan
Connect software, telemetry, simulators, and operator tools. Trace a failure across the full system, then make the integration understandable to the people who maintain it.
What this producesIntegration plan · diagnostic tools · recovery behavior
Design repeatable checks, representative scenarios, and useful failure cases. Connect requirements to evidence and keep development results separate from operational acceptance.
What this producesTest strategy · automated checks · evidence walkthrough
Pair hands-on delivery with architecture reviews, mentoring, and technical documentation. Explain the decisions so your team can continue the work with confidence.
What this producesDecision records · runbooks · knowledge transfer
Tools follow the problem. My working background spans Rust, C/C++, Python, TypeScript, Linux, CI/CD, hardware-in-the-loop testing, and human-reviewed AI workflows. See the full technical background.
How we get there
I start by agreeing what success means and how we will demonstrate it. Regular reviews connect implementation to your users, your constraints, and the outcome you need.
Customer checkpoint
Feedback throughout; revisit a stage whenever evidence calls for it.
Understand the people, the current workflow, and the problem worth solving. Surface constraints and assumptions before choosing a solution.
Typical outputsWorkflow observations · Stakeholder map
Together: agree on the problem.
Turn the need into a bounded scope, measurable requirements, and acceptance criteria. Agree early on how to verify the specification and validate the intended use.
Typical outputsAcceptance criteria · Verification & validation plan
Together: agree on what good means.
Map interfaces, dependencies, and failure modes. Test the riskiest assumptions with focused experiments before committing to the full implementation.
Typical outputsArchitecture & tradeoffs · Targeted risk experiments
Deliver small, reviewable increments. Integrate with the actual environment and demonstrate progress while changes are still inexpensive to make.
Typical outputsWorking increments · Reviewed changes
Check that the implementation meets its specification. Use tests, inspection, analysis, or demonstration as appropriate; include failure paths and record unresolved limits.
Typical outputsRequirement-linked evidence · Defects & regression checks
Evaluate the result with the customer and intended users, in representative conditions. Confirm that it solves the intended problem; feed gaps back into the work.
Typical outputsRepresentative user scenarios · Acceptance findings
Together: confirm it works for your use.
Agree on readiness, ownership, and remaining risks before release. Hand over the working system, operating guidance, and a practical recovery path.
Typical outputsRelease & recovery plan · Runbook & knowledge transfer
Together: agree on release readiness.
Compare real use with the agreed outcomes. Bring customer feedback, operational evidence, and changed needs into the next conversation and the next iteration.
Typical outputsOperational observations · Prioritized improvements
Does the implementation meet the agreed requirements? Tests, inspection, analysis, and demonstrations provide the evidence.
Does it solve the intended user’s problem in the intended environment? We review representative use with the people who will depend on it.
Activities overlap and repeat. We plan verification and validation from the start, scale the documentation to the risk, and revisit scope when feedback changes the requirements.
A focused assessment can clarify an uncertain project. A well-defined problem can move straight into scoped delivery.
The outcome matters, but the path is unclear.
A current-system review, options and risks, and a bounded implementation proposal with success measures.
You have a specific capability to deliver.
Working software or integration, agreed checks, an acceptance review, and the documentation needed to operate it.
Your team needs experienced hands on a difficult problem.
Development, diagnosis, architecture review, and mentoring alongside your team, with clear ownership of the work.
Before work begins, we agree scope, deliverables, acceptance criteria, responsibilities, schedule, and commercial terms. Remote collaboration and on-site needs can be discussed together.
These portfolio projects show the technical reasoning and evidence you can examine before we talk.
See a shared Rust runtime, operator interfaces, repeatable scenarios, and explicitly scoped performance evidence.
See external flight-state data drive real X-Plane views, with a bridge console and observable system behavior.
The agreed deliverable should include what your team needs to run, understand, and maintain it. We choose the appropriate artifacts at scoping, rather than leave the handoff to the end.
Start a conversation
A short project brief is enough to start. We can establish fit, availability, and the next useful step from there.
Email a project briefjosephpoznanski@gmail.com
Connect on LinkedInKeep the first note high-level. We can agree confidentiality and an appropriate way to share project material before exchanging sensitive details.