Technical second opinion

Before you putmore money into it.

Your app runs. Your developer says it is nearly ready. Or you have an AI-built product and a launch decision to make. I examine the agreed evidence, explain where you stand and give you a prioritised recommendation you can use.

Let’s discuss what you need reviewed

Free first conversation · 30 minutes · Directly with me

Taieb Bendai smiling outdoors in front of green foliage.
Taieb Bendai. In your corner.Between Germany and Spain.
Working across borders.

What do you need to know?

01 · Launch readiness

Can customers use this yet?

A polished interface does not tell you how the whole product behaves. We agree the intended launch, critical user journeys and implementation evidence to examine. That can include the working product, architecture, deployment, data handling, access and recovery essentials within the scope.

The useful result is a clear account of blockers, risks, what can be supported by the evidence and what was not examined. The next decision might be to fix something, run a limited release or investigate a question further.

02 · Confidence in outsourced delivery

What do we have—and what do we control?

We compare the agreed scope, working demonstrations, delivery records and available implementation. I map the relevant repositories, cloud, deployment and administrative access, identify what can be corroborated and make the unanswered questions visible.

Commit counts do not establish the value of the work or prove supplier misconduct. Technical access and contractual ownership are different questions. The recommendation may be to continue with the current supplier, improve the arrangements or change course.

A useful next decision. In writing.

  • Agreed review question and evidence boundary. What we are deciding, which product or delivery material is included, and what is outside the review.
  • Written findings. What I observed, the evidence behind it, relevant uncertainty and the areas not examined.
  • Prioritised recommendations. What needs attention first, why it matters and the next action I recommend.
  • An access and control map where relevant. The technical accounts, repositories and permissions we can establish from the supplied evidence.
  • A review conversation and decision brief. Something you can use with your current team, a new partner or me.

Remediation is a separate scope unless we explicitly include it. The review should be useful on its own; continuing with me is your decision.

Illustrative decision-brief format

This shows the structure of an output. It is not a report from a client or a finding about your product.

Question
What decision are we trying to make, and for which release or investment?
Evidence
Which demonstration, implementation material or access record supports the finding?
Finding and limit
What was established, why it matters, and what remains unknown or unexamined?
Priority and next step
What should happen before the decision, who needs to act, and what evidence would resolve the question?

Agree the question. Examine the evidence.

  1. Use the free conversation to frame it.

    Tell me what you have built or commissioned, the decision you face and the access you have. I share an initial perspective and help work out a useful next step.

  2. Agree the paid review.

    We define the question, preparation, evidence, required access, deliverables, fee and timing before work starts. If the available material cannot answer the question, I make that limitation clear.

  3. Review and explain.

    I examine the agreed product and delivery evidence, discuss relevant questions and prepare the findings. We walk through the recommendation and what the next decision depends on.

A functional QA exercise tests agreed journeys. An implementation review considers the agreed technical evidence. Specialist security testing answers a different set of questions. This review is not a penetration-test certificate or a guarantee that a product has no vulnerabilities.

The judgment behind the review.

Before you ask.

How is this different from the free call?

The free 30-minute conversation gives you an initial perspective and a useful next step. The paid review includes agreed preparation, examination of evidence and written findings with a prioritised recommendation. We agree its scope and fee first.

Will you tell me to replace my developer?

Only if the examined evidence supports that recommendation. The useful outcome may be to continue with the current team, clarify the arrangement or change the plan. I do not infer wrongdoing from commit counts or incomplete context.

Can you fix what you find?

Yes, where the work fits my capabilities and availability. We agree a separate remediation scope unless it was included from the start. You can use the findings with another team.

What do you need access to?

It depends on the question. We agree the relevant working product, demonstrations, repositories, deployment or technical account information and delivery records. You should only provide material and access you are authorised to share.

Can you review an app built with AI?

Yes. An AI-built or vibe-coded app can be the starting point. We agree what to examine in the working product, code and deployment, then identify supported findings, unanswered questions and priorities for the launch decision. The review is scoped to that decision; any specialist security assessment needed is agreed separately.

Let’s take 30 minutes.

Bring me the question.

Tell me what you’re dealing with. I’ll share how I’d approach it and help work out a useful next step. You’re welcome to use that advice whether or not we work together.

Let’s discuss what you need reviewed

The conversation is free. Any paid work is scoped and priced before we start.

Prefer a message? Use the message form or email hello@taiebbendai.com.