The working log behind the concepts.

It is tempting, especially as a student, to start a project with a silhouette. A shape you already think looks right, then back-fill a reason for it. I used to work that way and I noticed that those projects always stalled at the same moment: the moment somebody asked what they were actually for.

Now every concept here opens with a one-page problem brief. Who is exposed, where, doing what, and what is failing for them today. The brief has to be true before any geometry happens. If I cannot write the brief in plain language, the concept is not ready.

The effect is uncomfortable at first and then very freeing. Half of the ideas I get excited about do not survive the brief, and that is the point. The ones that do tend to lead somewhere genuinely new, because the design space is being shaped by the problem rather than by what I already know how to draw.

For a long time I treated each concept as a one-off. A vehicle for a specific role, rendered and then parked. The problem is that real procurement does not work that way. Nobody buys one bespoke thing; they buy a platform that can evolve.

I have started forcing a second step into every project: after the core concept is stable, what are the four most likely specialised variants? Not cosmetic changes, real reconfigurations that test whether the chassis, powertrain and interfaces are actually robust.

This has already changed MUGSV, the River Logistics Craft and even the submersible. Each one now carries a set of variant cards that prove the same core can serve different missions. It is more work up front, but it is the difference between a sketch and a system.

When I started MUGSV I had a list of roles I wanted it to fill. Cargo, casevac, power, shelter. The early sketches gave each of those its own bespoke body. That is not modularity, that is a family.

Real modularity meant going back to the chassis and committing to a single payload interface (physical, electrical, data) that every future module has to obey. It was a slow week of decisions that did not produce a single nice render, but it is the reason the platform now scales.

The lesson I keep relearning: if a constraint is easy to add later, it probably is not load-bearing. The constraints that matter are the ones you can only set at the beginning.

The River Logistics Craft went through a hard pivot recently. The original sketch had a small cabin and a scale that crept upward until it was basically a miniature barge. It looked sensible on paper, but it was not the concept I had set out to solve.

The revision is fully unmanned, much smaller, and built around a shallow-draft catamaran hull with an electric water-jet. The cargo deck is sized for a handful of pallets and standard relief loads, nothing more. The whole thing is designed to slip up rivers that are too small or too remote for conventional barges, without needing a crew at risk.

The lesson was that removing the human operator is not just a deletion. It reshapes the proportions, the power budget, the navigation logic and the failure modes. You have to design unmanned from the start, not adapt a manned design.

SMOKEWASP is the clearest example. The instinctive framing is convoy protection in a conflict. But the underlying capability (buying time and breaking observation for people who are exposed) is exactly what a civilian extraction from a collapsed building, or a medical team working under fire from looters, also needs.

Designing for the humanitarian case first changes the priorities. Cost matters more. Logistics footprint matters more. Failure modes have to be much less aggressive. The defence variant becomes a hardened subset of a kinder baseline, instead of the other way around.

I think this is the more honest way for an independent designer to work in this space. The goal is to reduce harm, and to do that the first user in mind has to be the person who is already most vulnerable.

I have been working on two very different vehicles that share one property: they are not supposed to come back. The long-range strike drone is a small flying wing built around a munition bay, and the submersible is essentially a torpedo-shaped surface drone that becomes a one-way underwater threat.

Designing something you intend to lose forces clarity. There is no maintenance access to over-engineer, no graceful degradation to plan for, no crew comfort to subsidise. Every gram and every watt has to justify itself against the single mission.

The danger is making them too cheap to be reliable, or too reliable to be cheap. The sweet spot seems to be a modular front section that carries the effect, plus a common propulsion and guidance rear section that can be manufactured in volume. I think this is where the next iteration will go.