Experience

A. I’m usually busy with projects and context-switching is a real cost. I prefer initial enquiries via email, with basic information provided there. If you really need to speak to me first, email me a few brief details and your contact number and I’ll call you back at a time that suits you.

A. Most of my work is commercially sensitive to some degree — the pool of projects I’m free to show publicly is limited. Getting a representative spread of problem types and delivery styles meant drawing on a wider time range than I’d ideally prefer.

If you have a specific problem in mind, email me — I can usually share relevant anonymised examples, or talk through similar patterns without disclosing client details.

A. Yes — I design machines, mechanisms and mechanical equipment, where that’s the right answer to the brief.

What you may notice in the work shown here is a bias toward simple, robust, well-resolved solutions rather than part-heavy or visually busy machinery. That is deliberate. I generally prefer clear mechanical architectures, fewer unnecessary parts and interfaces, and designs that are easier to substantiate, manufacture, install and maintain.

Some types of equipment genuinely require significant controls, handling logic, change parts, and tightly coupled mechanisms. Where that is the core of the requirement, a specialist automation house may be the better fit. I’m usually a better fit where the value lies in problem definition, concept direction, mechanical judgement, and developing a robust, buildable solution.

Where I tend to add most value is in clarifying and rationalising the brief, resolving the mechanical side properly, and preventing unnecessary complication from becoming locked in too early.

A. Because simplicity is often a sign that the engineering has been properly thought through and resolved.

What you are mostly seeing here is the resolved outcome, not the uncertainty, false starts, avoided dead ends, unnecessary complexity removed, risks reduced, and judgement that produced it. The simplicity being seen is often the result of difficult engineering work, not the absence of it.

Many projects become more expensive, fragile, and burdensome than they need to be because unnecessary complications often accumulate as designs develop. My bias is to simplify where possible, without compromising the required function, robustness, or acceptance basis of the design.

A. Possibly — and it’s worth checking before assuming I can’t.

First, I may have worked in your sector but not be able to show it publicly for confidentiality reasons. Second, even in unfamiliar sectors, the underlying engineering pattern of a problem is often familiar — if it reduces to structural analysis, mechanism design, concept development, or manufacturing detail, I’ve likely dealt with similar problems in a different context. An outside perspective can also be genuinely useful: specialists embedded in a sector can become habituated to how problems are “always” solved, and miss approaches that other industries take for granted.

It’s also worth noting that my Phase 0 work — problem definition, requirements clarification, options framing — is often useful regardless of whether I go on to deliver the engineering directly. Helping a client get clarity on what they actually need, and what questions to ask, has value even if the detailed work ultimately goes to a sector specialist.

There are some areas I’d exclude myself from regardless of sector — CFD, non-linear FEA, domestic structural works, and heavily regulated domains where sector-specific knowledge is a prerequisite rather than a nice-to-have. If any of those apply I’ll tell you quickly.

The easiest thing is to get in touch with a brief description of your sector and the problem. I’ll give you an honest assessment of whether I think I can add value.

A. Generalist — deliberately so.

My value is usually strongest where a project needs broad mechanical engineering judgement rather than narrow sector-specific knowledge: defining the real problem, developing workable concepts, resolving geometry and interfaces, thinking through manufacture and assembly, and producing design information that can actually be used.

That is why I work across a range of sectors. In many cases, the industry changes, but the underlying engineering challenge does not.

Where deep specialist domain knowledge is the dominant requirement, a narrower specialist may be the better fit, and I will say so. But where the core challenge is mechanical, the experience tends to be more transferable than the sector label might suggest.

A. Formal references aren’t something I arrange as a matter of course. My clients tend to be busy, and putting them on the spot to field calls from prospective clients isn’t something I’m comfortable asking of them.

In practice, the case studies here, any anonymised examples I can share relevant to your problem, and the quality of our initial conversation are usually what people use to judge fit. If you want to do your own research into companies I’ve worked with, I have no objection to that.

The lowest-risk way to find out what working with me is like is simply to try it. A Phase 0 engagement is deliberately scoped and limited in cost — it’s a natural first step that lets you judge my process, communication and output directly, without committing to anything larger before trust is established.

A. Not in any identifying way unless that is agreed.

First, and most importantly, anything you share at enquiry stage is treated as confidential by default. I will not disclose the fact that we are in discussion, or any detail of those discussions, to anyone.

For contracted work — my standard terms reserve limited rights to reference the fact I have worked with a client, and to produce limited marketing content based on the work.

In practice, that does not mean I publish identifying or commercially sensitive information freely. I would not publish anything that links your identity and the nature of the work together without your consent, and where a separate NDA is in place I will of course honour whatever constraints that creates.

What I may sometimes show is a sufficiently anonymised and high-level view of a process, engineering approach, or non-identifying output, stripped of anything that could reveal you, your product, your application, or identifiable specifications / values relating to such.

Beyond the contractual position, I apply common sense. If something is obviously commercially sensitive, I will not go near it even if the paperwork might technically allow that.

If complete non-reference is a hard requirement — meaning you need me to commit to not referring to the client or the engagement at all — that can be agreed up front. As that removes rights which would otherwise have value to me, it may affect the commercial terms in any proposal. If this matters to you, it is best raised before we start.

A. My responsibility is usually to deliver the agreed scope well, not to guarantee an unlimited search for a solution.

Most engineering work is done under constraints: time, budget, geometry, existing interfaces, performance targets, manufacturing limits, and commercial realities. Most of the time those constraints can be worked through. Occasionally they cannot, or at least, not without revisiting the brief.

If it becomes clear that the stated brief is preventing a satisfactory outcome, I will say so plainly. I do not usually continue into open-ended iteration outside the agreed scope in the hope that something eventually works. Instead, I would normally complete the agreed work, set out what appears to be blocking a viable solution, and identify the most sensible next steps from there.

That is also why I describe this kind of delivery as a Defined-scope Sprint. It is intended for work where the problem is already sufficiently understood, and the route to “done” is clear enough, that a bounded package of work can be agreed with confidence. Where significant unknowns or possible roadblocks still exist, the right next step is often further definition work first.

This is one reason Phase 0 matters. Good outcomes depend heavily on getting the brief right: defining the real problem clearly, constraining it sensibly, and allowing enough runway to reach an answer that is actually useful.

A. Mostly alone. Frugal is a one-person consultancy, and in most cases I deliver the work myself.

That is deliberate. I have built a broad enough capability to take work from early problem definition and concept development through to detail design, substantiation and released engineering information, so most projects do not need a larger internal team around them.

One advantage of that model is continuity: the original intent tends to stay intact from early thinking through to released information, without the handover friction that can come when work passes through multiple people.

From time to time I may bring in trusted external help, usually for specialist input, independent checking, or occasional capacity reasons. But that is the exception rather than the rule, and if it is relevant to your project I would be clear about it up front and manage that input directly.

Capacity is therefore deliberately limited, but if you engage Frugal, you work directly with me throughout.