Single Point of Failure – One Man Band dependencies

The is the second in a series of “Single Point of Failure” discussions I’ll be posting.

We’ve all seen the “One Man Band” show in operation. The person who perhaps has a website or maybe even a Hamvention booth but that seems to have no actual company behind their product.

They may be brilliant or just confident enough to offer a product. They may be  undercapitalized all but sleeping in their car, or well heeled. They may be truly alone, or maybe have some family members involved.

But in the end they fail to convince you that there is any assurance of support if they personally were suddenly out of the picture.

They may leave you questioning whether they will make it home from Dayton if they don’t have enough sales.

The products they offer may be sound, maybe even noteworthy, but you’re likely going to have to reverse engineer that product if they fail.

Some of these folks are dreamers, unrepentantly returning Hamvention after Hamvention claiming that their killer product is just around the corner.

I’d been interested in two automatic antenna tuner projects that their respective One Man Band developers have promised for 8 years or more.

One that “won his product prevailing in litigation” coming out on top of legal squabbles started almost a decade ago now appears to have dropped “new production soon” claims for the well established tuner design that he originally said was going to update and relaunch.

The other project never made it past a few bench built prototypes created by the original project owner.

Both projects have ended up One Man Band projects, making the product, product support both in warranty and long term, and potential upgrades all risky question marks – pontential Single Point of Failure level question marks.

One might wonder why I’m viewing vapor ware as a Single Point of Failure type issue?  Mostly because I’d included the potential product  in my shack design, perhaps underestimating the One Man band risks.


Sometimes the product availability basically depends on whether or not the sole developer’s attention can be gotten, and hopefully he hasn’t become bored or just moved on.

I have several kit built radios I evaluated in the run up to using the kits are part of a hobby class, only to find out the kit I bought was among the last available because the developer stopped offering th3 kits. Lots of reasons given – design required a part that the developer can’t find more stock, the production volume didn’t make them enough money, or simply they wanted to do something else.

Looking at a great idea for station monitoring at a friend’s shack I ended up unable to bring the product to my shack as the developer basically didn’t like enough of being a storekeeper that he effectively discontinued his product moving to his next challenge.


In the end how can you incorporate One Man Band products into your station without creating a Single Point of Failure issue?

So what happens to your shack if he loses it, or if he isn’t able to do his job, or when he wants to retire (provided he hasn’t declared it “too much” along the way)?

How long can you expect the package to be usable in a world of every updating operating systems, drivers and radios?

Should you have an alternative program ready to implement?

Do you have your Plan-B option ready at all times, or something to deal with only if you have to?


I will argue a bit against myself here, as I do purchase ham items from folks I know are One Man Bands.  Whether it is their attitude, their brilliance, their innovation, or their apparent durability, something they have offsets my concerns.

Or perhaps a reality that it is the only way to get the product, and I’d like to use the product rather than do without.

I’ve just bought another kit from an Austrian ham as an example.  My reasons include I want to experience building and using his kit, he comes over as bubbling in capability, enthusiasm and polish, his key looks like something that fits my ideas of helping others, and the investment wasn’t expensive.  If he drops support for any reason, or the product doesn’t work well for me, I’m only out the money, as the product is neither mission-critical nor something I need to operate.  I’m all into the offer of fun, education and experience the product offers, and within reason the One Man band issues fade away.

I’m also a realist that some of the products sold to us by hobby catalog type vendors are One Man band products either offered or rebranded by these catalog vendors.  That often seems to work well and is a good thing, as the catalog vendor may add some support, warranty, continuity, and stability to the product.


My approach to using products from One Man Band developers that are important to my operations is to buy small, test & evaluate, and if the risks are manageable then buy in depth.

What this means is I’ll buy an initial unit, test it out for a while, and if I want to implement it across my stations the I’ll buy enough along with strategic spares/redundancy backup.  This may mean buying an extra unit or two.

It may mean working out a backup or workaround, and having those components on hand.

Sometimes that may include providing the infrastructure to support an alternative – like I pulled enough extra wire between the operating position and my tower at the station I’m now pulling down, that I was able to switch rotator brands and remote antenna switch brands without pulling more wire.   Actually I pulled more and larger conductors, plus a second duplicate cable as a backup.  It all worked to my advantage when I did major upgrading or repaired issues from a nearby lightening strike.


In the end using Products from a One Man Band isn’t the end of the earth if you understand and plan around the issues.



4 thoughts on “Single Point of Failure – One Man Band dependencies

  1. John Mcgrath KF6EFG says:

    I find your discussion interesting.

    Are you looking at the problem of ‘single point of failure’ from the lens of scarcity, or the lack of confidence in the One Man Band concept?

    I agree that it is discomfiting when a small shop or vendor discontinues/abandons an electronic component without leaving any type of support for it.

    Personally, I find it a challenge to either,
    1) Correct the issue, or
    2) Find a work around that will eliminate the need for that failed component to cause break in the chain.

    There are many links in our communications chain that can (and do!) break, but being resourceful, we can work around them and try to eliminate them in the future.

    I do not and will not shrink away from a small (1+ person) vendor because of their size. There are plenty of One Man Band shops that provide superior products and services, and communities that grow around them.

    • k9zw says:

      Hi John

      I really wasn’t thinking of using scarcity as an evaluation axis.

      Rather I had envisioned all the aspects of continuity – including some which I am considering exploring later concerning the risks of closed code firmware/software with predictable & unpredictable nature of developers.

      Appreciate your readership and taking the time to comment. I agree with the strategic use of “good” One Man Band shops but it might take a separate post to explain what that “good” is and how much of it you need to have to embrace a One Man Band shop. Perhaps you want to take a stab at expanding that as a comment or a guess post?

      Thank you again and 73


      • John Mcgrath says:

        Thanks, Steve.

        I would appreciate the opportunity to expand this discussion, and look forward to explorations.

        If you would, I would be willing to also explore the topic myself, as time allows in the next few weeks.


        John McGrath

      • k9zw says:

        Hi John – look forward to your contribution(s) – I’m good at and we will figure out a good way to get your ideas presented.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: