What I help with

Get clarity on the real problem, the next decisions, and what good looks like

When the real issue has not yet been clearly defined, engineering work can drift, loop, or head in the wrong direction. I help make the problem clearer, separate symptoms from root issues, and set out a more defensible basis for deciding what to do next.

Typical Outputs:

• A clear problem statement, with key assumptions, constraints and interfaces made explicit.
• A shared definition of success, including the main decision criteria.
• A focused set of realistic ways forward, with the main risks and unknowns called out.

Approach:

This typically starts by reviewing what already exists — like emails, sketches, CAD, notes, test results — and identifying where the real uncertainty sits.

From there, I tighten the brief, surface the constraints that actually matter, and reduce the position to a small number of defensible routes forward. Where needed, that also includes clarifying interfaces, system boundaries, and other early decisions before they become costly to unwind.

Typical Inputs:

• Any existing artefacts — like emails, notes, sketches, CAD, mark-ups, photos, test results
• A short conversation with the key decision-maker(s) and sometimes others involved
• Any known constraints — budget, interfaces, standards, deadlines

This is often the point where a loosely defined situation becomes something that can be assessed properly. Once the brief is clearer, the next step often leads naturally into concept generation and comparison, trade-off work, or early cost and manufacturability reality-checking.

See a case study

Identify and compare routes against the brief, and make the trade-offs visible before committing

Once the brief is clear, the next risk is choosing a concept too early, too instinctively, or on the basis of partial information. I help turn candidate routes into something that can be compared on a clearer footing: illustrated, quantified where needed, and judged against the requirements that actually matter.

Typical Outputs:

• Concept options pack — bringing together client-provided and/or Frugal-generated concepts, with the key features, assumptions and differences made explicit
• Annotated sketches & illustrations — showing likely materials, provisional specifications, expected performance, and the main pros, cons, risks, and unknowns for each route
• Recommended next steps — supported by visible trade-offs around manufacturability, cost, complexity, lead-time, and delivery risk, so the client can decide on a clearer basis

Approach:

This may start from client-provided concepts, rough layouts, or partial ideas already on the table. It may also involve generating additional concepts in response to the brief, especially where the current options are narrow, premature, or not yet well tied to the real requirements.

From there, I develop the concepts far enough to make them comparable in a meaningful way: illustrating them clearly, surfacing the assumptions behind them, and annotating the likely implications of each route. The aim is not false certainty. It is to show what each option is really asking for, where the compromises sit, and which direction best answers the brief.

This level of presentation also makes the assessment easier to communicate internally, particularly where decisions might otherwise be driven by habit, opinion, or organisational or functional bias

Typical Inputs:

• A reasonably clear brief, with the key requirements, constraints, and success criteria understood
• Any existing artefacts — sketches, concepts, rough layouts, or existing design proposals
• Any known priorities — cost, space, weight, lead-time, fabrication method, standards

This stage often loops as concepts are refined, embodied, or narrowed down. Done well, it leaves the client with a more explicit basis for decision-making. Often it also leaves a preferred route developed far enough to move naturally into a defined-scope delivery Sprint.

See a case study

Understand what’s wrong with an existing design before deciding what to change

When an existing design is not working as it should, the obvious explanation is not always the right one. I help narrow down what is most likely going on, separate symptoms from root causes, and set out a more defensible basis for deciding what to do next.

Typical Outputs:

• A clear problem statement, including where the issue most likely sits and the most likely causes or mechanisms, with key assumptions, constraints, and interfaces made explicit
• A shared definition of success, including what “fixed” needs to mean in practice and what evidence or measurements will be used to judge improvement or justify change
• A practical set of realistic ways forward, with the main risks, unknowns, and continuity constraints called out, and the most credible next step made clear

Approach:

This usually starts with the symptoms already visible — poor performance, inconsistency, unexpected behaviour, damage, test results that do not make sense, or legacy documentation that no longer gives a reliable basis for action. I review the available information, test the assumptions already in play, look for the most credible explanations, and reduce the situation to a smaller number of likely causes or decision paths.

Where changes affect existing equipment, production systems, legacy product families, or ongoing spare-parts support, the work also has to account for the wider dependencies. In those cases, the aim is not just to identify what may be wrong, but to do so in a way that supports safe, practical, and low-disruption next steps.

The aim is not full forensic certainty. It is to understand enough about what is really happening to avoid chasing the wrong fix, and to move forward on a more grounded basis.

Typical Inputs:

• A clear summary of what is going wrong, including when it happens and how it shows up
• Any available evidence — photos, videos, test results, drawings, CAD, mark-ups, user feedback
• Any known constraints on testing, redesign, downtime, cost, access, continuity, or stock

Once the situation is clearer, the next step often leads naturally into concept generation and comparison work, followed by a defined-scope Sprint only when confidence is high enough to move into delivery.

See a case study

Turn a chosen concept into a coherent, buildable release package

Once the direction is clear, the next step is to resolve the engineering properly. I develop the design to a defined release point by closing down interfaces, detailing the parts that matter, and turning the concept into something that can be built, reviewed, and released with confidence.

Typical Outputs:

• A buildable design state — developed to the level needed for the intended next step (prototype, manufacture, testing, or production preparation)
• A defined release package — usually a PDF drawing pack with whatever drawing structure is needed to fully define the design for the intended release point
• Any required supporting outputs — such as 3D CAD models, 2D profiling files, design risk assessments, or technical substantiation where included within scope

Approach:

This usually starts with a chosen concept, a frozen brief, and an agreed definition of what “release-ready” means for the job in question. I then work through the engineering needed to turn that direction into delivery — sizing and defining the design as required, resolving interfaces, manufacturability, assembly logic, tolerances, supplier realities, and the decisions needed to make the package usable in the real world.

The aim is not just to produce files. It is to reach a release point that is coherent, buildable, and properly matched to the intended use of the design.

Typical Inputs:

• A frozen brief and chosen concept direction — with the main requirements, constraints, and intended release point already understood
• Any existing design information — layouts, sketches, CAD, interface details, prior decisions, or partial release material
• A clear definition of release intent — for example prototype, manufacturing-ready, or production-intent

This is usually the core delivery Sprint once the earlier definition and trade-off work has been done. From here, the next step often moves into prototype build support, structural substantiation or verification work (if that has not already been completed as part of the Sprint), or a follow-on Sprint to iterate or refine the design if the brief needs to change as a result of the detail design work.

See a case study

Establish whether a design meets the structural requirements arising from its brief

When a design needs structural evidence or verification, the value is not in running analysis for its own sake, but in producing evidence that demonstrates whether the design meets the requirements set out in the brief. I produce the manual calculations and practical FEA needed to do that, in a form that can support clients’ engineering decisions and, where relevant, their wider compliance process.

Typical Outputs:

• A defined analysis scope — including the agreed design scenarios, load cases, boundary conditions, assumptions, and acceptance basis
• A clear engineering view of margins, sensitivities, residual risks, or shortfalls
• A concise substantiation or analysis report — with conclusions tied back to the requirements and acceptance basis set out in the brief

Approach:

This usually starts by defining and agreeing the analysis scope, if that has not already been captured in the brief — what needs proving, under which design scenarios and load cases, against what assumptions, boundary conditions, and acceptance basis. Client approval of that basis is usually sought before calculations or analysis begin.

From there, I set up the calculations or FEA needed to answer the questions raised by the agreed scope and brief — whether that is checking adequacy of a concept or detailed design, supporting a release decision, or understanding where the structural limits really sit.

The aim is to produce evidence that is scoped clearly enough, and explained plainly enough, to provide structural confidence and support the subsequent engineering decisions.

Typical Inputs:

• A design or geometry set to analyse — CAD, drawings, layouts, or key dimensions, with enough definition to support the agreed scope
• An agreed design/analysis brief — setting out the relevant design scenarios, load cases, boundary conditions, assumptions, standards, and acceptance basis
• Any supporting background evidence — such as previous calculations, test results, or other existing technical information

This often runs alongside design development or just before a release decision, depending on when the substantiation needs to be done and how tightly it is tied to the evolving design. Running it in parallel can reduce coordination overhead and surface structural issues earlier, though analysis scheduled later may increase the risk of corrective iteration if shortfalls are found.

From here, the next step may be a corrective design Sprint, further iteration, or a more formal checking / substantiation path if the project requires it.

See a case study

Get accurate, information-rich, but lightweight 3D models that stay usable downstream

When the design already exists but is not yet adequately captured in 3D, that can create real risk and friction. Reviews become less effective, downstream engineering becomes harder to trust, and the model cannot be reused confidently for the work that depends on it. The geometry may be complex or awkward, the references may be tangled or messy, or the existing CAD may simply be too heavy or unreliable to use properly.

In those cases, ordinary CAD capacity often produces models that may be usable in isolation, but do little to reduce friction for the rest of the business.

I build accurate, reality-faithful, fully referenced 3D models that are lightweight, robust, and usable in practice — so they can fulfil their intended purpose in review, downstream engineering, and wider business use with minimal friction.

Typical Outputs:

• Accurate 3D CAD models and assemblies suitable for their intended purpose(s)
• Robust model structure & design intent — with geometry, interfaces, model inputs, and relevant assembly and part data properly captured
• Any agreed supporting outputs — such as mechanism motion studies, illustrated assembly sequences, accurate quantity/mass/COG data, or models prepared for analysis

Approach:

This usually starts with a review of whatever reference material already exists. From there, I step back, think the problem through properly, and work out a plan for how the model needs to be built to suit its intended purpose. In practice, that model plan works much like a brief: setting the basis, structure, and acceptance criteria for the model before detailed CAD work begins.

I then build the model in line with that plan. Where difficult geometry needs to be represented accurately, I do not let modelling difficulty dictate a poorer approximation; I work out how to model it properly before implementing it. When needed, I also produce a model-structure spreadsheet — effectively a BOM for the CAD files — to track progress, level of development, model inputs (references), manufacturing route, make/buy status, specifications, and other key data.

The aim is not just to create a visual 3D shape. It is to produce a model that is information-rich, auditable, accurate enough, lightweight enough, structured enough, and robust enough to support the work that follows.

Typical Inputs:

• Reference information — including things like drawings, sketches, measurements, photos, component datasheets, partial CAD or scans
• A clear model purpose — the reason the model is needed, such as development, review, layout, analysis, communication, or archive/record use
• Any known constraints — such as interfaces, tolerances, configurations, or required output formats

Done well, this kind of model becomes a genuinely useful business asset — improving review quality, reducing ambiguity, supporting better decisions, and making downstream work easier across engineering, manufacturing, quality, and commercial teams.

See a case study

Get an independent review of an in-progress design package before release or further commitment

When a design package is already in development, an independent review can catch oversights that may have slipped through the net, help restore direction where it has been lost, and provide an external perspective before release, manufacture, client issue, or further investment.

Typical Outputs:

• A structured independent review of the current design package, identifying key issues, inconsistencies, omissions, risks, or weak assumptions
• Redline mark-ups and comments on the relevant package documents — such as drawings, calculations, substantiation work, CAD or supporting documents
• A design review summary report, showing what needs attention, what can wait, where further work may be needed, and where engineering effort may currently be going to waste

Approach:

This usually starts with the existing package already on the table — typically the 3D model, drawing pack, calculations, substantiation, designer’s risk assesment, and any supporting notes or previous review comments. I review the material against the effective design brief — the stated purpose of the package, the intended release point, and any agreed standards, assumptions, or acceptance criteria.

The aim is not to generate a long snag list for its own sake. It is to assess the package as an engineering design deliverable: where it is coherent, where it is weak, where the main risks sit, and what corrective action, if any, would most improve confidence.

Where needed, that also includes separating genuine issues from noise, identifying missing information, and distinguishing between items that block progress and items that are merely untidy.

Typical Inputs:

• The current design package — typically CAD, drawings, calculations, substantiation reports, and supporting notes or comments
• A clear review purpose or concern — for example release readiness, buildability, coordination, structural adequacy, internal consistency, or overall design confidence
• The original design basis / brief — including the known constraints, standards, and acceptance basis the package is expected to satisfy

This is typically used when the design work exists, but the team wants an independent view before release, manufacture, client issue, or further investment. It may remain a standalone review Sprint, with your team acting on the feedback, or it may lead into a follow-on Sprint if you decide that external corrective work, substantiation, or package revision is needed.

Get experienced engineering judgement on live questions, technical issues and decisions

When engineering questions arise frequently but do not each justify a standalone Sprint, it can be useful to have experienced judgement available on demand. I provide ongoing engineering input by email and call, helping you answer technical queries, assess options, challenge assumptions, sense-check proposals, and make smaller decisions with a clearer view of risk, consequence, and practical next steps.

Typical Outputs:

• Clear written or verbal answers on ad-hoc engineering questions, options, risks, and next steps
• Senior review and sense-checking of evolving designs, supplier proposals, calculations, or technical decisions
• Ongoing continuity of technical direction and judgement where small decisions are frequent, interconnected, or time-sensitive

Approach:

Work is typically driven by short requests as issues arise — by email, call, or occasional mark-up review. These are usually judgement-led questions rather than bounded delivery tasks — I can provide input on design choices, supplier proposals, technical trade-offs, unexpected issues, or requests for a second engineering view.

I respond with focused input that helps the team make progress without unnecessary delay or process, while catching potential wrong turns early before they absorb more time, cost, or effort. Where useful, I will also set out what I would do, or what approach I would take, given the immediate context.

Typical Inputs:

• Short questions, decision points, or technical concerns raised by your team
• Whatever working material is needed to answer the question — CAD, drawings, reports, supplier input, mark-ups, photos, or notes
• Context around priorities, constraints, timelines, and who needs the answer

This works best where there is a steady flow of smaller engineering decisions, but not enough defined scope to justify a standalone Sprint. It is most useful for judgement, sense-checking, and technical direction rather than routine CAD or project-engineering delivery. As clearer packages emerge, the work can then move into targeted Sprints for design development, analysis, or release deliverables.

See a case study

Senior-level checking and targeted technical support to reduce risk and keep work moving

When design work is already underway but specific items need a more concrete answer than a quick call or email can provide, I provide structured checking, redline mark-ups, short technical notes, and targeted CAD or FEA support to help resolve the point in hand. The aim is to reduce risk, improve confidence, and keep work moving without needing to spin up a full Sprint each time.

Typical Outputs:

• Clear redline mark-ups and review comments on CAD, drawings, calculations, or analysis outputs
• Short technical notes summarising the outcome of focused checks or quick investigations where the answer is not immediate
• Small targeted CAD, calculations or FEA snippets to resolve specific questions, with the resulting files passed back as reference material for your engineers’ use

Approach:

Work is typically driven by specific items that need a more documented response than quick verbal decision support — for example a calculation to check, a drawing to mark up, a detail to sense-check, or a small CAD / FEA question to investigate. I review the material against the agreed criteria or intended use, identify what actually matters, and provide feedback in a form that can be acted on directly.

Where needed, I also carry out small bounded CAD or FEA tasks to answer the point in hand. These are usually short, targeted pieces of work intended to unblock progress, not standalone delivery packages.

Typical Inputs:

• A clear review question — for example buildability, structural behaviour, or release readiness
• Whatever working material is needed to answer the question — CAD, drawings, calculations, analysis outputs, or other material needing review or clarification
• Task context — of the priorities, constraints, standards, and acceptance criteria that the work should be judged against

This works best where the team needs documented checking, mark-ups, or small technical investigations rather than general judgement calls alone. It is a useful layer of senior review and targeted support alongside an internal team.

As the work becomes larger, more open-ended, or more delivery-focused, it is usually better handled through a defined-scope Sprint.

See a case study