How I work

If the problem is still ambiguous, open-ended, or not yet clearly framed, that usually points to Phase 0: Definition & Scoping. That is the right mode where the real value lies in clarifying the problem, defining the constraints, reducing ambiguity, and working out what the sensible next step actually is.

If the task is already well-defined, with a clear finish line, clear outputs, and a reasonably predictable route to completion, that usually points to a Defined-scope sprint. That works best where the scope can be bounded clearly and the deliverables are defined well enough to be estimated and priced with confidence.

If the need is for smaller, recurring, but less predictable pieces of support, that usually points to Ongoing Support Retainer. That is generally the best fit where the individual tasks are too small or too frequent to justify a full proposal and approval cycle each time, but still need timely, senior-level input. It works best where those requests are clear enough to be picked up as small defined tasks as they arise.

In practice, ongoing support is not usually the starting point for working together. It tends to work best once some earlier Phase 0 or Sprint work has already established context, direction, and a good working rhythm.

So the engagement mode mainly follows the shape of the work: ambiguity points to Phase 0, a clear bounded task points to a Sprint, and a recurring flow of smaller defined requests points to Ongoing Support.

Most defined pieces of work tend to start from around £1,250 + VAT, with larger or more technically involved packages increasing from there.

For Phase 0 and Defined-scope sprints, I would usually propose a fixed price based on the scope, deliverables, and level of technical work involved. That generally gives a clearer commercial basis than simply tracking hours.

Retainers work differently, with a pre-agreed monthly time allocation for small standalone tasks and ongoing support.

As a practical guide, very small pieces of work are often not economical once the time needed to frame, deliver, and review them is taken into account. If you are unsure what fits, email a short summary and I will let you know what seems most sensible.

Yes — if the brief is already clear enough, you can go straight into a Defined-scope sprint.

The key question is whether the work is already defined well enough to deliver without major unknowns, hidden assumptions, or unresolved questions likely to cause delays or abortive work later.

If the brief is mostly there, it is often possible to bottom out the remaining points through the initial discussions and proposal process. Where I would usually suggest Phase 0 is when the brief is still too open-ended, disputed, or under-defined to scope delivery cleanly.

A quote prices delivery against a sufficiently clear brief. Phase 0 is paid work to help define that brief when too much still needs working out first.

The difference matters because early scoping is real engineering work. When that work is rushed or given away for free at quote stage, it often leads to inaccurate or vague briefs, hidden assumptions, and delivery risk sitting in the wrong place.

Phase 0 is there to do that part properly: clarify the real question, make constraints and unknowns explicit, identify and compare possible next steps, and provide you with a better brief that I — or any other engineering consultant — can quote properly.

If the brief is already clear enough — I will of course quote directly.

If I don’t consider it clear enough to quote and deliver cleanly — I would rather say so and suggest Phase 0 than price delivery against a poorly defined scope.

That depends on the engagement mode and on how material the change is. For Phase 0 and Defined-scope sprints, I prefer to agree the basis of the work up front and then deliver against that.

Minor additions or clarifications may sometimes be absorbed without fuss, where I do not consider them to materially affect the agreed basis or require rework.

If the brief changes materially, important new information appears, or the work turns out to be larger or more complex than expected, I would usually say so and suggest either an agreed adjustment to the scope and fee or a new follow-on stage.

For Retainers, that flexibility is more built in, but larger self-contained tasks may still be better handled separately as Phase 0 or a defined-scope sprint.

Usually, the first step is a short email summary from you, together with any drawings, reports, photos, specifications, or other material that may help me understand the job.

I would then review that, decide whether it looks like Phase 0, a defined-scope sprint, or something else, and come back with either clarifying questions, a suggested next step, or a proposal if the work is already clear enough to scope commercially.

In practice, that initial exchange with a new lead usually takes at least a few days. Even where the brief is quite good, there is often some back-and-forth before a firm proposal is issued.

I would not usually expect new work to commence immediately. I am nearly always carrying current work, so around 10 business days from first contact to contract commencement would be a more typical minimum. Existing clients can sometimes move a little faster because the relationship and admin are already in place, but I would not normally expect next-day starts even then.

Usually, no.

I would not normally take responsibility for overall compliance or sign-off unless my proposal specifically states that my scope includes assessing compliance against particular regulations, standards, or acceptance criteria.

In most projects, I do not have full oversight or control of the wider product, system, or route to market — I am typically engaged to work on a defined part of a much larger picture. Where formal compliance, certification, or declaration of conformity is required, that responsibility would normally sit with the party placing the product on the market — typically the manufacturer — because they alone have control over the full design, build, documentation, testing, intended use, warnings, instructions, and overall technical file.

My obligation is to apply professional skill and care in accordance with the relevant codes and standards. That is different from certifying that outputs are error-free or that they satisfy your wider regulatory obligations.

Independent checking of my work outputs is normally the client’s responsibility, whether via appropriate third-party checking or in-house review by an appropriate subject matter expert. Where the application warrants it, that checking can also be commissioned through me as a separately scoped and priced service.

Similarly, I would not normally guarantee that a design or analysis will achieve approval by a particular date. I will always apply best efforts to meet client programmes where possible, but I cannot guarantee timescales where the outcome depends on factors outside my control. If a project takes longer than anticipated — due to additional review iterations, changes in inputs, or constraints imposed by others — the programme will need to move accordingly.

There is also a small but real risk that, having explored a design route thoroughly, it becomes apparent that no viable solution exists within the current brief constraints — whether due to geometry, loading, cost, or applicable standard requirements. In that situation, my obligation is to tell the client clearly and promptly, so that the brief can be reconsidered. That outcome, while unwelcome, is itself a valid and necessary engineering output.

The specific factors that most commonly affect approval timescales and outcomes include: the quality and completeness of the brief and inputs, the number of review iterations required, decisions and constraints imposed by others, and the specific standard or approval route involved.

My normal approach is therefore to scope my services as the designing engineer — responsible for the engineering work itself — with independent checking and wider approval responsibility sitting outside my scope by default. If a project requires me to take on or coordinate that checking role, then that needs to be explicitly scoped, priced, and agreed in advance.

Phase 0 — involves more thinking

Sprint — involves more doing

In Phase 0, I often work intermittently over a few weeks. That is deliberate. It gives me time to think the problem through properly, step away from it, let the implications sink in, and allow ideas or concerns to surface naturally, rather than expecting everything to surface in one compressed session. That usually leads to better judgement and a stronger output than trying to rush definition work into an artificially tight block. It also leaves room for the kind of delayed insight that often only appears once the problem has had time to settle in the background.

With a Sprint, the brief is already well-defined, so the work is more about very focussed delivery rather than open-ended thinking. That leads me to pre-schedule a more continuous block of time where I can stay in a focussed delivery mindset for that specific project. In practice, that is often more productive: there is less context-switching, less chance of unrelated work polluting the thinking, and more chance of getting properly into flow and pushing through the agreed outputs efficiently and to a high standard.

So the distinction is really this: Phase 0 is definition-heavy and benefits from space and reflection, whereas a Sprint is delivery-heavy and benefits from sustained concentration and momentum.

Retained time does not roll over because the arrangement is not intended to work like a bank of stored engineering capacity.

The value in a retainer is reserved access, continuity, and responsiveness across the month. I am keeping some of my capacity available for that client’s small separate tasks, questions, and decisions as they arise. If that time were not being reserved in advance, I would otherwise allocate it to new work or other clients — and then may not have capacity available when that client needs me.

If the monthly hours are not fully used, that shortfall should generally be understood as part of the cost of keeping that access and responsiveness available for the period. Some months will naturally be lighter than others.

I would normally expect the arrangement to be viewed sensibly in the round rather than hour by hour. Where there has been under-use in one period and slight over-use in another, I will often try to offset that where I reasonably can, but that would be discretionary rather than a guaranteed rollover mechanism.

If there is a regular pattern of material under-use or over-use, that would usually be a sign that the monthly allowance should be reviewed and adjusted.

The aim is not to find work to consume every last retained hour, but to keep timely engineering input available when it is useful.

Yes — the retainer can run for just one month if that is all that is needed. There is no minimum term.

It is paid in advance because the arrangement is based on reserving access, response time, and monthly capacity. Once that space has been set aside for a client, I am committing part of my availability on the basis that it is theirs to use during that period.

Paying in advance keeps that arrangement clear and workable for both sides. It avoids the retainer drifting into a retrospective argument about what was or was not “used”, when the real value of the retainer is the access, continuity, and responsiveness being held available across the month.

If the arrangement is active for that month, the capacity is reserved and the support is there. If it is not paid for, that month is simply not being held open.

If a client wants to continue, the retainer can roll on month by month. If they only need one month of focused support, that is also fine.