Technical assessment
A second view before a consequential change.
A technical assessment gives you a written view of the system, the risks, and your options before you commit to implementation. I work with the decision you need to make and the evidence available.
Work directly with Hasan Burak Taşyürek at HB Global.
Scope, fee, timing, and payment terms are agreed before paid work.
What the work gives you.
The agreed scope determines the depth of each output.
- A description of the current behavior
- The important flows, dependencies, and constraints within the agreed scope, with gaps in the available evidence made explicit.
- Options and their trade-offs
- What each direction changes, what it preserves, and which questions need answering before work starts.
- A written recommendation
- A direction and ordered next steps your team can use to decide, plan, and discuss the work.
How I approach it.
I start by clarifying the decision with you and the people who operate the system. We agree which code, workflows, or records need examining. I then compare what the system is intended to do with the evidence of its actual behavior. The recommendation distinguishes confirmed findings from assumptions and open questions.
Where the scope ends.
The assessment covers an agreed question and scope. It is not a blanket certification of the product. Implementation and ongoing ownership are separate decisions; your existing team can use the findings without retaining me for the build.
The work behind the approach.
Each case describes its own context, decisions, and limits.
Understanding a payment plugin before refactoring
The discovery pass documented payment behavior and surfaced 28 production bugs before modernization. The case describes an audit outcome, not a completed rewrite.
Read the caseChoosing a contained product compromise
A booking workflow used an existing payment path and controlled configuration to meet one enterprise requirement. The case explains why that compromise fit those circumstances.
Read the caseBefore we start.
What do you need for the first conversation?
A description of the system, the decision, the options you have considered, and what is at stake. Code access and confidentiality arrangements come after we agree what needs examining.
Can my team carry out the recommendation?
Yes. The written recommendation is intended to support a decision and a handoff. If your team wants implementation support, we can agree that responsibility separately.
How are cost and timing agreed?
They depend on the scope and evidence that need reviewing. Before paid work starts, you receive the proposed output, fee, timing, and payment terms in writing.
Start with the decision.
Describe the system, the constraint, and what a useful outcome would look like.
Discuss your situation