Early in my career, I worked in QA at Net Integration Technologies on Nitix. The official job title for QA employees was “Evil Death Ray.” That was funny, but it was also more accurate than most job titles. Our job was to find the strange edge cases, bad assumptions, awkward failures, and painful surprises before customers did.
I found bugs, plenty of them. That was my job, of course.
However, that is not the part that stayed with me. What stayed with me was that I was allowed to do the job properly. I was allowed to try new ideas out. I was allowed to automate in creative ways to allow for complex QA testing suites to be developed that better used the hardware I had. I was allowed to improve the process, look for patterns, and push beyond a simple checklist. That matters more than it might sound like it should.
It seems obvious, but a healthy technology company does not treat quality as the annoying department at the end of the process. It treats quality as part of how the product learns You see, software is not just code. It is also the culture behind the code. It is the set of habits that decide whether problems are noticed early or buried until a customer pays the price. It is the willingness to ask whether a process is actually working, or whether everyone has simply become used to the pain.
That lesson has followed me into the work we do now at Panda Rose.
Most businesses do not wake up in the morning hoping to think more about infrastructure. They do not want to become experts in networking, permissions, remote access, backups, cloud accounts, legacy systems, device management, software integrations, DNS records, or whatever else has quietly become business-critical.
They want the business to work; staff to reach the systems they need; customers served; files where they belong; orders processed, quotes sent, invoices paid, and reports they can trust.
And with managed IT done properly, it sounds simple until you look underneath.
A small business today may have Microsoft 365 or Google Workspace, accounting software like QBO or Sage, a CRM (WordPress) for their website, remote staff with need for secure outside access, potential outside contractors, cloud applications, 0legacy line-of-business systems, shared drives, laptops, phones, printers, scanners, and a few spreadsheets that somehow became part of the operating system of the company.
In short, the old server-in-the-closet problem did not disappear. it simply spread out. Which is why I have come to appreciate boring infrastructure.
Not neglected infrastructure. Not cheap infrastructure. Not “set it and forget it” in the careless sense.
I am referring to infrastructure that has been thought through well enough that it stops demanding constant heroics. In other words, systems that make access clearer, with tools that reduce fragile exceptions and processes that catch problems before the client feels them.
Which is why Tailscale got my attention.
I don’t feel that any one tool deserves blind trust. In fact, I’m pretty strict with trust should never replace evaluation. A tool still has to prove itself in real client work. However, trust does shape what I am willing to take seriously.
Many years ago, I saw an engineering culture where quality was allowed to surface problems honestly. I saw that QA could be more than a last-minute gate. It could be a way of improving the system itself and that experience stayed with me. So when I later saw some of those same instincts show up again in a modern tool, I paid attention.
At Panda Rose, we use Tailscale because many small business IT problems are really access problems. For example, a developer needs to reach one server, not the whole office network or a remote worker needs access to one internal system, not a permanent hole punched through the firewall (Which I’ve seen far too many times when I’ve taken over IT for SMBs). In another case, a legacy application still needs to be accessible to remote personnel. In a third case, a support person needs to help without turning every maintenance task into a security exception.
For all of these, the old answers were often messy; Open a port, set up a brittle (or potentially insecure) VPN, share too much access because narrowing it properly was too much work to maintain in the long run, or depend on one undocumented machine or one person’s memory. In short, get it working and hope nothing changes.
Hope is not good infrastructure.
Good infrastructure gives the right people access to the right things in a way that can be understood, maintained, and explained. It does not make every business owner carry the entire technical model in their head, which is the whole point.
The best IT work is often not flashy. It is quiet, ie. the removed workaround, the cleaned-up access path. The system that stops relying on someone remembering the magic steps. The old process that finally becomes visible enough to improve.
This is true in managed IT. It is true in custom software. It is true in business analysis. It is true when connecting legacy systems to modern tools. It is even true when deciding whether a new technology should be adopted at all.
The question is not, “Is this new?”
The real question should be, “Does this reduce the amount of unnecessary pain the business has to carry?”
That was one of the lessons I took from my Nitix QA days. “Evil Death Ray” was a funny title, but the role was serious. It was not about breaking things for the sake of breaking them. It was about finding weakness while there was still time to do something about it.
That is still how we try to think at Panda Rose. Find the fragile point before it becomes an emergency, then automate the repeated pain before it becomes accepted as normal.
Make access intentional before convenience turns into risk.
Help the business become calmer, not merely more technical.
The tools have changed.
The dream has not.
