Question 1

How does a Delivery Risk Audit start, and how long does it take?

Accepted Answer

A Delivery Risk Audit starts with a kickoff call to understand your context, followed by a needs audit and process mapping. The final deliverable takes the form of a risk / timeline / budget matrix along with a 90-day roadmap. Depending on the complexity of your organization, the whole engagement typically takes 1 to 2 weeks.

Question 2

Who buys this, and who benefits from it?

Accepted Answer

The buyer is the founder, agency owner or engineering manager. The beneficiaries are the developers. That is deliberate: pitching a process audit to the team whose work is being examined produces compliance, not change.

Question 3

How much access do you need to our system?

Accepted Answer

Read access to the repository, a view of the deployment setup, and an hour with whoever knows the project best. No production access, no write permissions. If code access is impossible, the audit covers process only and I tell you up front what that removes from the result.

Question 4

How long does a technical specification document take?

Accepted Answer

Seven to ten working days for a typical mobile or web application, including the scoping interview and two review rounds. A very broad scope can take longer, and I say so at scoping, before you commit.

Question 5

How much access do you need to prepare the hour?

Accepted Answer

Whatever you can share easily: the quote or estimate, an architecture diagram even a rough one, and read access to the repository if the question is about existing code. If you can share nothing, the hour still works but becomes a conversation rather than a review.

Question 6

How is this different from hiring a project manager?

Accepted Answer

A project manager runs the work. I grade it. I do not plan the vendor's sprints, manage their team, or take on any delivery commitment for them: I tell you, in writing and monthly, whether what you are paying for is what is being delivered.

Question 7

What's the difference between the Delivery Risk Audit and Build Oversight?

Accepted Answer

The Delivery Risk Audit is a one-off, fixed-scope audit: it gives you a clear picture of your needs, risks and priorities. Build Oversight is an ongoing monthly engagement — project management, scoping, AMOA — that picks up once the diagnostic is done, or can start directly if your needs are already clear.

Question 8

Do you touch our codebase?

Accepted Answer

No. I install a workflow, templates and prompts version-controlled alongside the code. Your developers remain the only people writing and approving code.

Question 9

What if we have no documentation?

Accepted Answer

That is itself a finding, and it is the common case. The audit reads the code, the commit history and the real process — missing documentation becomes a line in the risk matrix rather than a blocker.

Question 10

What do we need to prepare before we start?

Accepted Answer

Nothing formal. Whatever you have: notes, screenshots, a quote you received, a feature list. The scoping interview exists to turn that into requirements — that is my job, not yours.

Question 11

What if we have no documentation?

Accepted Answer

That is the normal case and it is not a blocker. A prepared hour on an undocumented codebase gives a less precise answer, not a useless one. I will state explicitly what I could not verify.

Question 12

Will our vendor accept this?

Accepted Answer

In practice yes, on one condition: the grading is against written criteria everyone sees in advance, not against an impression. A serious vendor prefers an explicit referee to a surprise acceptance test. One who objects has told you something.

Question 13

Do you work with clients outside Morocco, remotely?

Accepted Answer

Yes. I regularly work remotely, including with international clients — one based in North America as part of my freelance activity — as well as fully remote engagements, such as the one carried out for Werin Group. Remote project management and communication tools are a core part of how I work.

Question 14

Where does the 40% figure come from?

Accepted Answer

From measuring spec-writing time across 7+ products. It measures one specific activity and is not a claim about overall delivery speed: a team that writes specs faster still has to build the thing.

Question 15

What if you find something critical during the audit?

Accepted Answer

I call you the same day rather than waiting for the deliverable. A critical risk found on day 4 and disclosed on day 10 is malpractice.

Question 16

Can we put several vendors against this document?

Accepted Answer

That is precisely what it is for. The document is written to be sent as-is to several vendors, so the difference between their quotes becomes information rather than noise.

Question 17

Who actually does the review?

Accepted Answer

I do, personally. There is no team and no junior the work gets passed to, which is also why I cap ongoing oversight work at two clients at a time.

Question 18

What is the minimum commitment?

Accepted Answer

None. It is monthly and rolling, cancellable at any time. Setup is billed once, in the first month only.

Question 19

Do you write code yourself, or only manage?

Accepted Answer

Both. My dual Project Manager / Tech Lead positioning lets me go as deep as a project needs: standard scoping and project management on one side, but also architecture design, code reviews and security audits on the other, when a project needs real technical depth and not just vendor coordination.

Question 20

What if our team is hostile to AI?

Accepted Answer

Say so before, not after. The workshop works with a sceptical team — that is arguably the most useful audience — but not with a team the engagement is imposed on without explanation. In that case I decline the work rather than sell it.

Question 21

Can you implement the remediation?

Accepted Answer

No, and that is explicit. I am not a candidate for the work I recommend. I can help you choose who does it, with no financial interest on my side.

Question 22

Do you then build it?

Accepted Answer

No. I write the specification and I do not bid on the build. Same rule as the audit: whoever writes the scope should not be a candidate for the work.

Question 23

What if my question turns out to be several questions?

Accepted Answer

I tell you before you pay. We pick the one that unblocks the others, or I point you at the Delivery Risk Audit if what you actually need is an audit.

Question 24

How much time does this actually take you each month?

Accepted Answer

Enough to read every sprint, run the acceptance gate and write the verdict — which is exactly why I cap this offer at two clients at a time.

Question 25

What's a typical Build Oversight engagement length?

Accepted Answer

It's an ongoing, renewable monthly engagement, generally aligned with a project's full lifecycle. In practice, most engagements run 3 to 9 months, depending on the size and complexity of the project being managed.

Question 26

Do you supply the tool licences?

Accepted Answer

No, and I take no commission on any tool recommended. The playbook states what is useful, where, and what is not.

Question 27

Who actually does the audit?

Accepted Answer

I do, personally, from first access to the readout. That is the difference between an independent audit and a report produced by a team you never meet.

Question 28

How many revision rounds are included?

Accepted Answer

Two, stated up front. Beyond that it is billable — an uncapped revision loop is exactly how a fixed price stops being fixed.

Question 29

Can I show the decision record to my vendor?

Accepted Answer

Yes — it is written for that: one page, no unnecessary jargon, reasoning visible. You can forward it as-is.

Question 30

You run delivery at an agency. Is that not a conflict of interest?

Accepted Answer

It would be if it were undisclosed. The Digi4 relationship is disclosed in writing before any introduction, and I decline any engagement overseeing a Moroccan agency. Oversight with an undisclosed conflict is worth less than no oversight at all.

Question 31

Do you offer AI integration services (fine-tuning, APIs, automation)?

Accepted Answer

Yes — AI is part of my day-to-day work, well beyond internal tooling: fine-tuning classification models on real data, multi-provider API integration (Gemini, Groq, OpenAI, Anthropic), AI assistants grounded in product data, and running several AI projects in parallel. See the AI Integration & Automation offer for details. The same tools (Claude Code, Gemini) also speed up my own delivery process — roughly 40% less time spent writing specs.

Question 32

What does the team keep after you leave?

Accepted Answer

The workflow installed in your own tools, the written playbook, and a baseline measurement taken at the start. Without that "before" number, nobody can tell six months later whether any of it worked.

Question 33

Is this a penetration test?

Accepted Answer

No. This is a delivery and code risk audit: obvious security exposures are reported, but penetration testing is a different discipline and I will point you at a specialist if that is what you need.

Question 34

Is the build estimate contractual?

Accepted Answer

No. It is a range with its assumptions written down, meant to help you judge a quote — not to replace a vendor's own commitment. A number without its assumptions is worthless.

Question 35

What if you disagree with my own technical team?

Accepted Answer

I write the disagreement down with the reasoning, and state what would change my mind. An independent opinion that always agrees with the internal one is worthless; so is one that disagrees without an argument.

Question 36

What if the verdict is bad several months running?

Accepted Answer

Then the question stops being oversight and becomes a decision: renegotiate, change vendor, or stop. I give you the written evidence to make it; the decision stays yours.

Question 37

Do you maintain what you install?

Accepted Answer

No, and that is stated up front: around 40% of rule-based automations break within twelve months, silently. That is exactly why the deliverable is a playbook the team owns rather than a dependency on me.

Question 38

Will our vendor see the report?

Accepted Answer

You decide. The document is written so it can be forwarded without editing, but it is yours and nothing goes to a third party without your written agreement.

Question 39

What if development has already started?

Accepted Answer

Possible, but the deliverable changes: it becomes a reconciliation of the real scope against the existing code. If the build is already under way and the doubt is about its health, the Delivery Risk Audit is the better fit.

Question 40

Do you sign an NDA?

Accepted Answer

Yes if you want one, and most clients do. Send yours, or I provide a standard one.

Question 41

Do you write code on the project?

Accepted Answer

Never. I review, grade and run the acceptance gate. Writing code on a project you also grade destroys the exact thing you are paid for.

Question 42

Is there a check-in after the engagement?

Accepted Answer

Yes — optional, at three months, billed separately. It exists to compare the baseline against reality, not to reinstall what was delivered.

Question 43

What if the audit concludes everything is fine?

Accepted Answer

It is delivered as such, at the same price. An audit whose conclusion depends on what it could sell next is worthless — and it does happen: sometimes the real risk turns out to be contractual or human rather than technical.

Question 44

What language is the document written in?

Accepted Answer

French or English, your choice, including for a project run in the other language. Acceptance criteria are written in whichever language the acceptance testing will actually be run in.

Question 45

What if we do not take it further after the hour?

Accepted Answer

That is the most common outcome and it is by design. The hour is prepaid, nothing follows automatically, and I do not chase.

Question 46

Can you step in if the project is already in trouble?

Accepted Answer

Yes, but start with the Delivery Risk Audit: two weeks to establish where you actually stand costs less than six months of overseeing a project whose scope is already wrong.

Frequently asked questions

Offres

AI-Augmented Delivery Enablement

Delivery Risk Audit

Technical Specification & PRD

Architecture Power Hour

Build Oversight

International

Méthode

Didn't find your answer?